All Articles

Why "Same OWASP Top 10, Different Attack Surface" Undersells the Problem

It is common to hear that API testing is just web application testing applied to a different transport. This framing misses three technical realities. A web application has a user interface that constrains business logic: a form field limits input length, a dropdown limits valid values, and client-side JavaScript hides options a user is not meant to reach. An API has none of that. Every parameter and state transition the UI quietly enforces is directly reachable by anyone who can read the request format, with no client-side guardrail between an attacker and the raw endpoint.

The second difference is trust assumption. Web testing largely assumes a human using a browser, where session cookies and CSRF tokens carry much of the security weight. APIs are built for machine-to-machine calls: mobile apps, backend services, partner integrations, and other APIs calling APIs with no human in the loop. That changes what "authentication testing" means, from "can I steal a session cookie" to "can I forge or replay a signed JWT, use a token issued for one audience against a different service, or abuse a service-to-service API key that was never meant to be rate-limited against a single user."

The third difference is discoverability of business logic. In a web app, a tester exploring checkout watches the UI to infer state transitions: cart, address, payment, confirmation. In an API described by an OpenAPI/Swagger definition or a GraphQL schema, the entire object graph, every field, mutation, and resource relationship is often handed to the tester, or an attacker, in one document. This is why schema-driven fuzzing is a distinct practice: a tool can walk the OpenAPI spec or introspect a GraphQL endpoint and generate test cases for every parameter automatically, at a scale manual UI-driven testing cannot match. A pentest that treats an API as just "the web app's back end" and skips schema discovery will miss the relationships that define the attack surface.

Technical Methodology: What a Competent Test Actually Does

Reconnaissance and Attack Surface Mapping

Every serious engagement starts with mapping what exists before touching anything. For web applications this means subdomain enumeration (certificate transparency logs, DNS brute forcing, search engine dorking) to find staging environments, forgotten marketing microsites, and internal admin panels that were never meant to be public. Technology stack fingerprinting follows: identifying the web server, framework, CMS, and JavaScript libraries in use, since known versions map directly to known CVEs and misconfiguration patterns.

For APIs, reconnaissance has an extra layer: schema discovery. A tester looks for exposed Swagger/OpenAPI documents (commonly at /swagger.json, /openapi.yaml, or /api-docs), and for GraphQL endpoints, checks whether introspection is enabled. If introspection is on in production, the tester can pull the entire schema, handing over a map of the data model. Postman collections, mobile app binaries (which frequently hardcode endpoints and sometimes API keys), and JavaScript bundles are mined for endpoint paths absent from public documentation. This is also where testers build an inventory of API versions in production, since old, undocumented versions (v1 endpoints left running after a v2 launch) are a frequent finding tied to a named OWASP API risk covered below.

Authentication and Session Testing

Authentication testing goes beyond checking whether a login form is present. Testers look for broken authentication flows: password reset tokens that do not expire or are predictable, account lockout bypassed by rotating IPs or user agents, and multi-factor authentication skipped by directly calling a downstream API endpoint that the MFA-protected UI flow was supposed to gate. For token-based APIs, JWT testing is a specific discipline: testers check whether the signature is verified server-side, whether the alg header can be changed to none to bypass signature checks, whether a token signed with an RS256 key can be resubmitted as HS256 using the public key as the HMAC secret (a known JWT algorithm confusion attack), and whether expired or revoked tokens are still accepted because the server never checks a revocation list.

Session testing on the web side covers session fixation (setting a victim's session ID before login to hijack it post-authentication), tokens that do not rotate after privilege changes, and tokens that remain valid after logout. On the API side, since there is often no traditional cookie-based session, testers examine token lifetime, whether refresh tokens can be replayed indefinitely, and whether a token issued for a low-privilege scope can be used against endpoints that require a higher scope.

Authorization Testing

This is usually where the most damaging findings live, and it is the category OWASP ranks as the top API risk. Broken Object Level Authorization (BOLA), the API-world term for what web testers call IDOR (Insecure Direct Object Reference), happens when an endpoint takes an object ID from the request and returns or modifies that object without checking whether the requesting user actually owns it. A tester finds this by authenticating as User A, capturing a request for User A's own resource (an invoice, a profile, an order), then changing the ID to User B's ID while still using User A's token. If the response returns User B's data, the authorization check exists only at the "are you logged in" level, not the object level.

Function-level authorization testing checks whether role boundaries are enforced server-side rather than hidden in the UI. A classic test: log in as a standard user, capture the API calls a UI makes for an admin-only feature (via client-side code, mobile app strings, or API documentation), and replay those calls directly as the standard user. If the server executes an admin action for a non-admin token, function-level access control is broken regardless of what the UI shows. Testers also look for horizontal privilege escalation (another user's data at the same privilege level), vertical privilege escalation (a standard user reaching admin functionality), and object property level issues, where an endpoint checks resource ownership correctly but still lets a user modify fields they should not control, such as sending an isAdmin field in an update request the backend blindly accepts.

Input-Based Testing

Injection testing covers the classes practitioners expect: SQL injection, NoSQL injection (relevant where MongoDB-style query operators can be injected through JSON bodies), OS command injection, and server-side template injection. It also covers XXE injection where APIs still accept XML, and insecure deserialization, where an application deserializes attacker-controlled data (a serialized Java, PHP, or Python pickle object) into live objects, potentially leading to remote code execution if the process instantiates dangerous classes. File upload testing checks whether uploads are validated by content and not just extension or declared MIME type, whether files can land in a web-accessible directory and be executed, and whether the pipeline is vulnerable to path traversal writing outside the intended directory.

Business Logic Testing

Business logic flaws are the hardest category to automate and the easiest for a scanner to miss, because nothing is technically "broken" in the code, the application just does the wrong thing correctly. Examples: a discount code applied repeatedly because the API does not track redemption state, a multi-step checkout where a later step is called directly to skip payment verification, a password reset with no limit on repetition, or a race condition where two simultaneous requests redeem a one-time voucher twice before the first state update commits. This maps closely to what OWASP names unrestricted access to sensitive business flows, since the endpoint is not "vulnerable" in a code sense, it was simply not designed to resist abuse at scale or in unexpected sequence.

API-Specific Concerns: Rate Limiting, Mass Assignment, and Data Exposure

Rate limiting testing checks whether an API enforces limits per user, key, or IP, and whether those limits reduce cost or risk. A login endpoint without rate limiting enables credential stuffing at machine speed. A resource-intensive endpoint (a report generator, a heavy search query, an SMS endpoint billed per call) without limits can be abused for denial of service or to inflate a target's third-party billing.

Mass assignment testing checks whether an endpoint accepting a JSON object for update blindly binds every field to the underlying data model. If a profile update endpoint expects {"name": "...", "email": "..."} but the backend auto-binds any field present, a tester can add {"role": "admin"} and see if it is accepted despite never appearing in documentation. Excessive data exposure testing checks whether a response returns more fields than the client needs, relying on the front end to filter display. A mobile app might show only a display name, but if the response includes full internal records (password hashes, other users' partial PII) because the backend serializes the entire database object, that is a finding regardless of the UI, since anyone can intercept the raw response with a proxy.

The Official OWASP API Security Top 10 (2023)

The current OWASP API Security Top 10 is the 2023 edition, published by the OWASP API Security Project. It replaced the 2019 edition and restructured several categories based on updated data from real-world incidents. Any pentest report or RFP referencing API Top 10 categories should use these exact 2023 names, since two 2019 categories were merged and one category is newly framed.

API1:2023, Broken Object Level Authorization

This remains the top-ranked API risk. It occurs whenever an endpoint uses a client-supplied object ID to fetch or modify data without verifying the requesting party is authorized to access that specific object. It is the most commonly exploited API flaw because it requires no special tooling, only a valid account and the willingness to change an ID in a request and observe the response.

API2:2023, Broken Authentication

This covers weaknesses in how an API establishes and verifies identity: weak or missing rate limiting on credential-based endpoints, tokens that never expire, JWTs with misconfigured signature verification, and API keys that function as permanent, unrevoked credentials. Because APIs are frequently consumed by non-browser clients, authentication flaws here are often more severe than equivalent web findings, since there is no secondary browser-level control that happens to catch the abuse incidentally.

API3:2023, Broken Object Property Level Authorization

New in the 2023 edition, this merges two 2019 categories, excessive data exposure and mass assignment, on the reasoning that both share the same root cause: missing authorization checks at the level of individual object properties rather than the object as a whole. A response can correctly authorize a user to view their own order while still exposing internal fields that should have been filtered. Testing this category requires comparing the full raw API response against the documented contract, not just checking whether the endpoint returns the right object.

API5:2023, Broken Function Level Authorization

This covers access control failures at the level of entire functions rather than individual objects, most commonly admin functionality reachable by non-admin accounts due to unclear separation between hierarchies. It is distinct from BOLA in that the issue is not "which record can I see" but "which capability can I invoke at all."

API6:2023, Unrestricted Access to Sensitive Business Flows

This covers business flows (ticket purchasing, comment posting, coupon redemption) exposed without any control for automated or excessive use, even absent a code-level bug. A scalping bot buying up concert tickets, or a script mass-creating fake accounts to farm a referral bonus, exploits this category even though every individual API call is technically valid.

A CISO Platform member perk. FireCompass is offering CISO Platform members a free AI pen test on their own attack surface. Run yours and get exploit-validated findings in hours, not a scanner report.

What a CISO Must Define Before a Test Starts

Vague scoping is the single most common reason a pentest produces weak results. If a statement of work says "test our website and API" without further detail, the testing team is forced to guess at boundaries, and guesses tend to be conservative, meaning the parts of the environment carrying the most risk (admin panels, internal APIs, newly launched features) are often exactly the parts left untested because nobody explicitly said they were in scope.

Before any test begins, a CISO should be able to answer each of the following with specifics, not generalities.

• Exact in-scope hosts, domains, subdomains, and API base URLs, including whether internal-only or partner-only APIs are included.
• Whether testing covers authenticated functionality, unauthenticated functionality, or both, and which specific roles need testing (a test covering only an admin account will never find a horizontal privilege escalation bug between two standard users).
• Whether dedicated test accounts will be provisioned for each role, with enough test data populated that authorization testing between accounts is possible (IDOR testing requires at least two accounts with distinct, non-overlapping data).
• Whether testing happens against production, staging, or a dedicated test environment, and if not production, what configuration differences could hide or introduce findings not applicable to the real system.
• The methodology: black-box (no internal knowledge or credentials), grey-box (authenticated access and some architecture knowledge), or white-box (source code and full architecture documentation). Grey-box is most common for web/API engagements because black-box spends disproportionate time on reconnaissance internal teams could shortcut, while white-box alone misses runtime issues only visible when the app is running.
• Explicit exclusions, particularly whether denial-of-service testing, load testing, or availability-degrading techniques are permitted, and whether social engineering or physical testing is in scope.
• Whether third-party integrated services (payment processors, SSO providers, vendor widgets) are in scope, since testing a payment gateway you do not own without the vendor's consent creates legal exposure regardless of your own authorization.

None of this is bureaucratic overhead. Each item determines what the testing team is technically able to attempt, and a report from a badly scoped engagement will read as clean and reassuring while simply reflecting the areas nobody looked at.

Rules of Engagement: The Operational Checklist

Separate from legal authorization paperwork, a rules of engagement document should answer operational questions testers and defenders both need before day one. These items most often get skipped and then cause confusion mid-engagement.

1. Exact testing windows: dates and times, including time zone, and whether testing is restricted to off-peak hours for production systems.
2. Named escalation contacts on both sides, with a phone number or messaging channel actually monitored during the testing window, not an email alias checked once a day.
3. A defined "stop testing" trigger: specific conditions (unexpected service degradation, an alert firing in the client's SOC, discovery of an unrelated active compromise) under which testing pauses immediately until both sides confirm it is safe to resume.
4. A pre-agreed process for a critical finding discovered mid-test, especially anything resembling a zero-day or a flaw actively exploitable by outside parties: who gets notified immediately rather than waiting for the final report.
5. Data handling rules for anything sensitive the testing team touches during testing (customer PII pulled via a BOLA proof-of-concept, database contents surfaced by injection): where that data is stored during the engagement, encryption requirements at rest, and a firm deletion deadline after report delivery.
6. An explicit list of techniques requiring prior sign-off even if broadly in scope, such as tests that could trigger account lockouts at scale, mass password reset attempts, or high request volume against production.
7. Confirmation of the source IP addresses testing traffic will originate from, so the client's monitoring team can distinguish test traffic from a genuine concurrent attack.

What a Genuinely Useful Report Contains

A pentest report that lists findings with a CVSS score and a one-line description is not an actionable deliverable, it is a compliance artifact. A report a development team can act on has a different shape.

Every finding needs a reproducible proof-of-concept: the exact request (method, URL, headers, body) or exact UI steps required to trigger the issue, detailed enough that a developer with no security background can replicate it without guessing. A CVSS score alone tells a developer nothing about what actually happens; a captured request and response pair showing User A's token retrieving User B's invoice tells them everything needed to reproduce, fix, and verify the fix.

Findings that chain together should be presented as an attack narrative, not separate flat entries in a table. If a low-severity information disclosure bug (an API leaking internal user IDs) is what made a separate BOLA finding exploitable at scale, the report should walk through that chain: how the tester found the leak, how they used the leaked IDs to enumerate victims, and the combined impact. A flat list of "12 findings, 2 critical, 5 high" obscures that two medium findings together produced a critical outcome, which is often how real attackers operate.

Remediation guidance needs to be specific to the actual code pattern involved, not generic advice like "implement proper access controls." A useful note names the exact missing check (verify the authenticated user's ID matches the owner field before returning the resource), points to where that check lives in the framework in use, and references the specific pattern (an authorization decorator, a policy object, a centralized access-control layer) that prevents the entire class of bug rather than patching one instance.

Finally, the deliverable is incomplete without a retest. Once fixes are deployed, the testing team should re-attempt the exact proof-of-concept steps and confirm, in writing, whether each finding is resolved, still present, or partially mitigated. A report without a retest cycle leaves the organization trusting a fix worked based on a developer's word rather than independent verification, which defeats the purpose of testing in the first place.

OWASP API Security Top 10 (2023): Impact and Remediation Patterns

As a CISO Platform member, you get free access. Ready to see what this looks like against your real environment? Start your free AI pen test.

About Priyanka Aash
Priyanka Aash is Co-Founder of CISO Platform, the world's first online community for information security executives, and Co-Founder of FireCompass. She has been nominated for the Cybersecurity Excellence Award for leadership and AI innovation in cybersecurity, honored with the NetApp Excellerate HER award, and featured in SC Media's Women in IT Security series. She is the author of The AI Divide. Security technologist Bruce Schneier advises FireCompass.