A02: No Valid Authorization

The consequences are not abstract either. Broken authentication is one of the most direct paths an attacker can take to full account compromise, data exposure, or privilege escalation. When authentication mechanisms are weak, missing, or inconsistently applied, an API does not just have a bug - it has an open door. Where that door is and how to close it is what this post is about.

What follows is a helpful overview of what API2:2023 Broken Authentication actually covers, how these weaknesses show up in actual API designs, and what you can do to address them. Whether you are a developer trying to fix a finding or a security engineer trying to explain the danger to your team, the goal here is to give you something concrete to work with.

What “No Valid Authorization” Actually Means in API Security

Authorization is the step that happens after login. Once an API knows who you are, it has to decide what you’re allowed to do. That’s where A02 comes in. A02: No Valid Authorization covers the cases where that second step fails.

It’s worth separating this from authentication, because the two get mixed up quite a bit. Authentication checks your identity. Authorization checks your permissions. An API can confirm who you are and still hand over data you were never supposed to see.

In practice, APIs manage authorization through tokens - small pieces of data passed with each request to prove identity and context. The API reads that token and decides whether to fulfill the request. But a lot of APIs trust the token without checking what the token holder should have access to.

That’s where BOLA comes in. BOLA stands for Broken Object Level Authorization and it shows up in roughly 40% of all API attacks. It happens when an API lets a user request any object - a record, a file, an account - by changing an ID in the request, without checking if that user has the right to see it.

Consider what that means in an actual system. A user calls an endpoint like /api/orders/1042 and gets their order back. Then they try /api/orders/1041 and get someone else’s order. The API authenticated the user just fine - it just never asked if that user had permission to view that particular order.

A02 in the OWASP API Security Top 10 is wider than just BOLA, though. It covers any situation where the authorization check is missing, incomplete, or based on data the user could manipulate. That includes role-based access checks that don’t actually run server-side and endpoints that use hiding a URL instead of enforcing permissions.

What makes API authorization different from general web app auth is the volume and number of endpoints involved. A single application can expose dozens of API routes, each with its own access logic. A gap in one location doesn’t stay contained - it opens access to actual data at scale.

The Most Common Ways Authorization Goes Wrong in APIs

Authorization failures don’t all look the same. They fall into a handful of repeating patterns that security researchers see across industries and places.

The most widespread problem is missing or incomplete token validation. An API might accept a token without checking if it’s still active, if it was signed correctly, or if it belongs to the user making the request. The server just sees a token and waves it through.

Expired session reuse is closely related. A user logs out or a token reaches its expiration time, but the backend never invalidates it. That token can work long after it should have stopped, which gives anyone who holds it an open door with no time limit. In payment contexts, this maps directly to the problem of an expired authorization being used after it should have been void.

Weak or predictable API keys are another pattern worth taking seriously. If keys follow a guessable format or aren’t rotated after a breach, an attacker doesn’t need much to get in. This is especially common in older internal APIs that weren’t built with external exposure in mind.

Scope enforcement is where things get especially interesting. A token could be issued with limited permissions, but if the API doesn’t actually check the scope on every request, those limits mean nothing in practice. The permissions are on paper and nowhere else. This parallels how invalid data in authorization requests can slip through systems that don’t validate every field on every transaction.

Failure Type	What Goes Wrong	Likely Impact
Missing token validation	Server accepts tokens without verifying signature or status	Unauthorized access to any protected endpoint
Expired session reuse	Tokens remain valid after logout or expiry	Persistent access using stolen or old credentials
Weak API keys	Keys are guessable, static, or never rotated	Account takeover or data exposure
Improper scope enforcement	Permissions are granted but never checked per request	Users can perform actions outside their intended role

These failures don’t happen in isolation. A system with weak key management tends to have gaps in scope enforcement too, because both point to the same underlying habit of treating authorization as a one-time setup instead of an active check on every request.

Why APIs Are Especially Vulnerable Compared to Traditional Web Apps

A developer who can lock down a web form might still leave an API endpoint exposed; it’s not a skills gap - it’s a structural one. APIs work differently, and those differences create authorization blind spots that standard web security habits don’t cover.

Traditional web apps manage session state on the server. The server knows who you are and what you’re allowed to do at every step. APIs are stateless by design, which means each request has to carry its own proof of identity - usually a token. That token can become the whole picture, and if something is wrong with how the server checks it, the request gets through anyway.

Token-based authentication also opens the door to credential stuffing. The RockYou2021 data leak exposed 8.4 billion plaintext passwords, and attackers use lists like that to hammer API endpoints with actual login attempts at scale. A web app may have rate limiting or a CAPTCHA to slow that down. An API endpoint without those controls is a simple target.

Microservices make this harder to manage. In a modern architecture, one user request might travel through five or six services before it completes, and each service needs to verify what the caller is allowed to do - not just if they’re authenticated; it’s a lot of places for a check to go missing. Understanding frameworks like the Digital Authentication Framework can help clarify how identity verification should flow across these layers.

Third-party integrations add more difficulty. When an external service calls your API, its permissions need to be scoped tightly. In practice, integrations get broad access because it’s faster to set up, and those permissions don’t get reviewed after the first connection is made.

There’s also a visibility gap. Web apps render in a browser, so a developer can walk through the user experience and see what’s accessible. API endpoints don’t have that visible surface. If you don’t have documentation or active testing, it’s easy to have endpoints that no one is actively watching. This kind of hidden exposure is one reason digital goods businesses are often categorized as high risk - the attack surface is harder to see and harder to defend.

Web App	API
Server manages session state	Each request carries its own token
UI makes the surface visible	Endpoints can be invisible without docs
Single app enforces auth rules	Multiple services each need their own checks
Third-party access is less common	Integrations with broad permissions are routine

How to Check If Your API Has Authorization Gaps

The best place to start is with your token logic. Check if tokens expire at a reasonable time, if they can be reused after logout, and if revoked tokens are actually rejected by the server. An interesting number of APIs still accept tokens that should have been invalidated hours ago.

Next, test your unauthenticated endpoint access. Take a list of your API endpoints and try to reach them without any credentials at all. Some endpoints legitimately need to be public, but others get left open by accident during development and never get locked down before deployment.

Scope enforcement is worth testing too. If a user token has read-only permissions, try it to write or delete data. If an account has access to one resource, try swapping the ID in the request to access a different user’s resource. This is one of the most common places where authorization breaks down in practice - and when it does, it can trigger a non-fraud chargeback if it affects a payment transaction.

Tools That Make Testing Easier

You don’t need a full security team to run these checks. OWASP ZAP is a free tool that can scan your API for common vulnerabilities like authorization weaknesses. Postman is great for manual testing since you can modify headers, tokens, and request parameters without writing any code.

Pair those tools with a structured checklist to get the most out of your testing session. If your API handles payments, also make sure your card validation logic is solid - an invalid card number error is a common sign of gaps in that layer.

What to Test	What to Look For
Token expiration	Expired or revoked tokens that still grant access
Unauthenticated access	Endpoints that respond without any credentials
Scope enforcement	Tokens that exceed their assigned permission level
Object-level access	IDs that can be swapped to access other users’ data
Role separation	Non-admin users who can reach admin-only endpoints

Run through this list on a staging environment first so you can test freely without affecting live data. Many teams find gaps they didn’t know were there once they start looking with this level of detail. If your platform processes payments, unresolved authorization issues may also surface as declined authorization disputes down the line.

Locking Down Your APIs Before Someone Else Does It for You

The most important change is treating authorization as a living part of your security posture - not a configuration you set once and forget. As APIs grow, endpoints get added, roles change, and business logic gets more complex, and each of those moments is an opportunity for a gap to open. Regular reviews, automated testing, and a least-privilege mindset applied across every endpoint are what close those gaps before someone else finds them. Keeping your chargeback ratio in check is one signal that your authorization controls are working end to end.

For a deeper look at the full context of this vulnerability - like complete danger ratings, attack scenarios, and prevention guidance - OWASP’s official API Security Top 10 documentation is the authoritative starting point - it’s worth reading not just once, but revisiting as your API surface changes.

Most breaches are not the work of elite adversaries dismantling your defenses layer by layer. They find a door that was left unlocked. Authorization is how you lock it. When authorization breaks down, the downstream effects can include most breaches that are entirely preventable with the right controls in place. When authorization breaks down, the downstream effects can include declined authorization disputes that are entirely preventable with the right controls in place.