Behind every app, integration and AI agent there is now an API. And exactly where the business logic is exposed, the attackers have moved in. As more systems talk machine-to-machine, the API layer becomes the most attacked surface in modern architectures – while also often being the least protected. This guide goes through what actually matters in 2026: authentication, rate limiting, validation, OWASP's risk profile, managing secrets and logging. Finally, you will receive a concrete checklist.
Authentication and authorization – the foundation everything rests on
The vast majority of serious API incidents are not about exotic crypto vulnerabilities, but about something far more boring: lack of access control. That's worth internalizing before we move on.
OAuth 2.1 is the new standard
For user login and delegated access, OAuth 2.0 is still the backbone, but the direction is clear.OAuth 2.1is in June 2026 still an IETF draft (draft-ietf-oauth-v2-1) rather than a finished RFC, but its recommendations are already treated as de facto standards by all major identity providers. The most important strictures to comply with:
PKCE is required for all authorization code flows– also for confidential clients, not just public ones. It turns off interception of authorization codes.
Implicit grant and Resource Owner Password Credentials are removed.If you are still using these flows, it is time to migrate.
Tokens must never be in query strings.Access tokens belong in the Authorization header or in the request body - never in the URL, where they end up in logs and referrers.
Exact string matching of redirect URIsinstead of wildcard comparisons.
For single page apps, the authorization code flow applies with PKCE, access tokens in memory (not in localStorage) and refresh tokens in HttpOnly cookies. For machine-to-machine integrations, the client credentials flow is used, preferably supplemented with sender-constrained tokens viaDPoP or mTLSso that a stolen token is worthless on another client.
API keys have their place – but cannot carry authentication alone
API keys are great for identifying which client or integration a call is coming from, and for tying quotas and billing to a consumer. But an API key is a static secret: it doesn't prove who the user is and can't restrict what can be done. Use keys for identification and routing, but put the actual authorization on OAuth scopes, short-lived tokens, and object-level controls.
Object-level authorization – the most common hole
The single biggest class of risk in the API world is that a call may access objects it shouldn't. It is not enough to checktothe user is logged in - you must check that that particular user has rights to that particular object, on every call. A classic mistake is to trust an id in the URL (/api/orders/12345) without verifying ownership. Always validate authorization against the authenticated identity in the backend, never against anything the client sends.
OWASP API Security Top 10 - the 2026 risk picture
The authoritative map of API risks isOWASP API Security Top 10, whose 2023 release is still the current stable version as of June 2026. It's worth reading in its entirety, but the main message is crystal clear:three of the top five risks involve a lack of authorization.
Broken Object Level Authorization (BOLA)– access to other people's objects, the heaviest item on the list.
Broken Authentication– weak or poorly implemented login flows.
Broken Object Property Level Authorization– exposure or manipulation of individual fields the user should not see or change.
Unrestricted Resource Consumption- lack of quotas and limits, what rate limiting addresses.
Broken Function Level Authorization– that ordinary users reach administrative endpoints.
New in the 2023 edition compared to 2019 is, among other thingsServer Side Request Forgery (SSRF)andUnrestricted Access to Sensitive Business Flows– the latter catches abuses such as scalping of inventory and mass registration of fake accounts, i.e. attacks against business logic rather than against code.
Rate limiting – your first line of defense
Without quotas, an attacker can flood your API with calls until it becomes inaccessible to real users. Rate limiting is a basic protection against DDoS, credential stuffing and brute force – and at the same time a way to keep costs and performance under control.
There are several algorithms and the choice depends on the traffic pattern:
Token bucketallows short peaks while maintaining a cut over time. Popular with paid APIs and public developer platforms where burst is normal.
Sliding window counteris a good default choice for most production APIs - fair and accurate limiting with low memory usage.
Fixed windowandleaky buckethave their niches but entail either edge effects or less flexibility at peaks.
In practice: put the restriction in your API gateway or in middleware, use a shared oneRadish- instance to hold counter state in a distributed environment, and always return standardized headers (RateLimit-Limit, RateLimit-Remaining, Retry-After) so that benign clients can govern themselves. Feel free to differentiate the limits per identity and per endpoint – login and other sensitive flows must have stricter limits than read calls.
Validation – never trust input
Everything that comes from the outside is unreliable until proven otherwise. Robust input validation closes a wide range of vulnerabilities, from injections to logic errors.
Validate against schedule.Define your APIs with OpenAPI and validate each request against the contract – types, formats, required fields, lengths and allowed values.
Positive validation (allowlist)instead of trying to filter out the bad. Allow what you recognize, reject everything else.
Don't blindly bind inputs to your objects.Mass assignment, where a client sends with fields such as
isAdminorrole, is a recurring way in. Specify explicitly which fields may be set.Limit size and depthon payloads and nested structures to avoid resource exhaustion.
Also validate what you call externally.At SSRF risk: only allow calls to known, listed destinations.
Secrets – out of the code, into a vault
Leaked API keys, database passwords and tokens are among the most common causes of breaches. OWASP's guidance on secrets management is clear and should be your guiding light:
Never secrets in source codeor in the version history. Scan repos and CI pipelines for leaked keys.
Centralize in a dedicated secret manager– HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager or Azure Key Vault. They provide access control, audit logs and rotation in one place.
Treat secrets as volatile.Short lifetimes and automatic rotation without code rollout. For example, Vault's dynamic secrets can generate database login with a TTL and revoke it automatically when the time has expired.
Fine-grained access.Each service should only access the secrets it actually needs—secret-level permissions over broad vault or project policies.
Rotate without stoppingwith a dual key pattern where both old and new credential are valid during a short overlap.
Logging and monitoring – see the attack in progress
Inadequate logging extends the time before a breach is discovered from minutes to months. Even if logging no longer stands as its own item in the OWASP API Top 10, it is crucial to being able to discover and investigate the other risks.
Log security-relevant events– failed logins, authorization errors, calls exceeding quotas, unexpected status codes.
Mask sensitive data.Tokens, passwords and personal data should never end up in clear text in the logs – this only creates a new target, and in the case of personal data, a GDPR risk.
Centralize and alert.Collect logs in a SIEM or equivalent and raise alarms on anomalies such as sudden spikes in 401/403 or suspicious object ID enumeration.
Correlate across the chainwith tracking ID so that a call can be followed through all services.
Checklist for companies with integrations
Inventory all APIs, including internal and forgotten (shadow- andzombie-APIs).
Authenticate using OAuth 2.1 principles: PKCE, no implicit flows, short-lived tokens.
Check object-level permissions ateachcalls - never just that the user is logged in.
Set rate limiting per identity and endpoint in your gateway, with standardized headers.
Validate all input against OpenAPI schema and use allowlist and explicit field binding.
Move all secrets to a vault with automatic rotation and fine-grained access.
Log security events, mask sensitive fields and alert on anomalies.
Test continuously – automated API security testing in CI and regular penetration testing.
Vote for the OWASP API Security Top 10 as a recurring review.
Build safely from the ground up
API security is not something you build on after the fact, but a quality that is woven into architecture, code base and operation. The cheapest time to do it right is before the integration is built – the most expensive is after a breach. At ZORC, we build integrations and APIs with these principles built in from day one, and are happy to help review an existing solution. If you want to know what a security-reviewed API or integration project would mean for you, it costs nothing to ask - tell us about your need inthe quote calculatoror get in touch viacontact.
