Blog

API Security: Stop Costly Authorization Flaws

APIs sit at the center of modern applications, and that centrality creates a serious security challenge. Every exposed business function, every object identifier, and every serializer decision becomes part of the attack surface. Unlike older monolithic applications where business logic stayed hidden behind server-side rendering, APIs intentionally expose structure, objects, actions, and states. Understanding API security authorization flaws is essential for anyone building or defending modern systems.

Why API Authorization Flaws Are the Weakest Link

The core issue is rarely authentication failure. In most API security incidents, the attacker is already authenticated. The problem is that the API does not verify whether that identity should access a specific object, function, property set, or business flow. This is why OWASP still ranks broken object-level authorization as the number one API risk, and why broken access control leads the OWASP Top 10 for 2025.

The most dangerous API flaws often look small in code: a missing ownership check, an over-trusting serializer, a role check only on the UI side, or an internal endpoint that was never supposed to be public. Those small flaws become real-world incidents because APIs scale business access across mobile apps, web clients, partner integrations, and internal services simultaneously.

Six Core API Security Vulnerability Categories

This article covers the six most critical API vulnerability categories from OWASP’s 2023 API Security Top 10 that every security assessment should address: BOLA (broken object-level authorization), BFLA (broken function-level authorization), property-level exposure, business-flow abuse, shadow APIs, and unrestricted resource consumption.

1. Broken Object-Level Authorization (BOLA) — OWASP API1

This is the classic and still the most common API authorization flaw.
See also: OWASP API Security Top 10. A user can access another user’s record by manipulating an identifier in the path, query, header, or body because the server checks only that the caller is authenticated, not that the caller owns or is permitted to access the target object.

Example: A banking API exposes GET /api/v2/accounts/{id}/transactions. User A (account 1001) changes the ID to 1002 in the request and receives User B’s transaction history. The server validated the JWT token but never checked whether the authenticated user owns account 1002.

Testing approach:

• Replace object IDs in requests with IDs belonging to other users or tenants
• Test read, write, and delete operations on the same endpoint
• Check if ownership validation happens after the database lookup, not before
• Verify consistency across API versions and related endpoints

2. Broken Function-Level Authorization (BFLA) — OWASP API5

This occurs when a user can invoke a privileged function because the endpoint exists and is reachable, even though the role or business purpose should not permit that operation. Many APIs protect the UI but forget to protect the backend function itself.

Example: A standard user calls POST /api/admin/users/{id}/delete directly via curl or Burp Suite. The frontend hides this button, but the backend accepts any valid JWT without checking the admin role claim.

Testing approach:

• Call admin-only endpoints with regular user tokens
• Test HTTP method confusion (POST where only GET is expected, or vice versa)
• Check old API versions and internal namespaces for unprotected routes
• Verify role enforcement at the function level, not just the controller level

3. Excessive Data Exposure / Mass Assignment — OWASP API3

Even when access to the object itself is correct, the API may expose sensitive fields or allow unauthorized updates to internal properties. This is where serialization, field filtering, and mass assignment become dangerous.

Example: A profile update endpoint accepts a JSON body and binds it directly to the user model. An attacker adds "role": "admin" to the request body, and the serializer writes it to the database because no field whitelist exists.

Testing approach:

• Compare response fields between admin and regular user roles
• Inject unexpected properties in PUT/PATCH requests
• Check if internal state, debug metadata, or configuration flags leak in responses
• Review serializer defaults — does it include or exclude fields by default?

4. Broken Business Logic / Sensitive Business Flows — OWASP API6

Some APIs are technically authenticated and authorized at the endpoint level but still vulnerable because the workflow itself is not enforced. That allows sequencing abuse, replay, skipped steps, state confusion, or use of high-value flows outside intended limits.

Example: A checkout API lets users call POST /api/checkout/apply-discount repeatedly on the same order because the server does not track whether a discount was already applied. A user stacks multiple discounts to reduce the total to near zero.

Testing approach:

• Replay one-time actions (password reset, email verification, discount codes)
• Reorder workflow steps (approve before submit, ship before pay)
• Bypass friction steps by calling convenience endpoints directly
• Test rate and quota enforcement on high-value flows

5. Improper Inventory Management / Shadow APIs — OWASP API9

Teams cannot secure what they cannot see. Old versions, test APIs, abandoned partner interfaces, and undocumented internal endpoints often become the easiest path around newer controls.

Example: A v1 API at /api/v1/users was deprecated but never decommissioned. It lacks the authorization checks added in v2. An attacker discovers it through endpoint fuzzing and exploits it to dump user records.

Testing approach:

• Compare API specification (OpenAPI/Swagger) against actual traffic
• Run endpoint discovery tools against the target domain and subdomains
• Check authentication consistency across API versions and environments
• Review whether deprecated endpoints have actual retirement timelines

6. Unrestricted Resource Consumption — OWASP API4

Many APIs break not because data can be stolen, but because cost, rate, and workload boundaries are too loose. Abuse of pagination, expensive searches, large exports, or recursive queries can turn an API into its own denial-of-service channel.

Example: A search endpoint accepts any page size. An attacker requests ?page_size=100000 and the server processes a massive database query, consuming Resources and slowing the service for all users.

Testing approach:

• Test pagination limits — what happens with extreme page sizes?
• Send expensive filter combinations to search and reporting endpoints
• Check rate limiting on both authenticated and unauthenticated endpoints
• Verify whether one noisy client can affect others on shared infrastructure

Real-World Impact

API security failures are not theoretical. Recent incidents demonstrate that authorization flaws at the API level can expose millions of customer records and trigger direct legal consequences.

T-Mobile API Breach (2023)

A 2024 FCC order documented a T-Mobile API incident in which a misconfigured API allowed a threat actor to query customer account data through a poorly authorized endpoint. The root cause was not a sophisticated exploit — it was a missing authorization check on an API that handled sensitive customer information. The attacker accessed records for approximately 37 million customers through the exposed API, including names, billing addresses, emails, and phone numbers.

Optus Breach (2022)

Australia’s privacy regulator filed penalty proceedings in 2025 following the Optus breach, in which an exposed API endpoint was used to access personal information of approximately 9.8 million customers. The investigation focused on whether Optus had reasonable security measures in place for the API pathways that handled customer data. The breach demonstrated that a single unprotected API endpoint can expose an organization to regulatory action, reputational damage, and class-action litigation.

Key Takeaway

Both incidents share a pattern: the attackers did not need to bypass encryption or exploit zero-day vulnerabilities. They accessed APIs that were already public but lacked proper authorization enforcement. This pattern — authenticated access without adequate object-level or function-level checks — is the defining characteristic of API authorization flaws.

Severity Matrix

Recommended Tools for API Security Testing

Defensive Hardening Checklist

Authorization enforcement:

• Validate object ownership on every read, write, and delete operation
• Enforce tenant isolation at the data-access layer, not just the API gateway
• Apply role-based function authorization on the backend, not the frontend
• Use explicit response models (field whitelists) instead of returning full objects
• Implement field-level authorization for multi-role APIs

API lifecycle management:

• Maintain a living inventory of all APIs, versions, and partner routes
• Decommission deprecated endpoints with concrete timelines
• Automate discovery of shadow APIs through traffic analysis
• Review authentication consistency across all environments (staging, prod, partner)

Business logic protection:

• Enforce state machines for multi-step workflows
• Make one-time actions genuinely one-time (tokens, flags, expiration)
• Apply rate limiting and quota enforcement per-user, not per-IP
• Log and monitor for workflow anomalies (replayed steps, skipped states)

Response safety:

• Never return internal IDs, configuration flags, or debug information in production
• Filter response fields based on the caller’s role and context
• Validate that serializers do not include relationships or nested objects unintentionally
• Sanitize error messages — do not expose stack traces or internal paths

Common Implementation Mistakes

• Checking auth once at the gateway and assuming downstream endpoints are safe — each endpoint must independently verify authorization for the specific object and action.
• Trusting the client to enforce rules — hiding a button in the UI does not prevent a direct API call.
• Using sequential or predictable object IDs — this makes BOLA testing trivial (UUIDs help but are not a complete defense on their own).
• Returning full database models in API responses — always use explicit field selection or DTOs.
• Applying rate limits only by IP address — authenticated users behind NAT share an IP, and attackers use botnets. Per-user or per-account limits are more effective.
• Leaving debug endpoints in production — health checks, diagnostics, and admin endpoints should be removed or restricted before deployment.
• Not versioning API authorization — when a new API version is released, the old version often retains weaker checks. Audit all live versions.

The priority for both defenders and pentesters is clear: compare what the API allows with what the business actually intends. That difference is where the real breaches begin. Authorization is not a one-time check at login — it is a repeated decision at every object, every property, every function, and every step of every workflow.

Reference: OAuth 2.0 Framework