Every modern application you build today, or that your business depends on, is essentially a collection of APIs connected by a thin layer of user interface. A mobile app talks to a backend over REST, a web frontend pulls data from GraphQL, vendor integrations run through webhooks, and internal microservices exchange information over gRPC. Attackers see this — and they direct most of their effort there.
The OWASP API Security Top 10 in its 2023 edition is to APIs today what the OWASP Top 10 for web applications was a decade ago — a shared language for development teams, pentesters and compliance functions. Except that an API is a different attack surface than a classic web application. There is no browser to enforce a Content Security Policy, no rendered HTML in which XSS in its classic form could fire. Instead there are crowds of endpoints, each with its own contract, its own authorization logic and its own potential for abuse.
This guide walks through all ten categories of the 2023 list, shows a typical abuse scenario, suggests an approach to testing, and ends with a practical twelve-step API pentest checklist and a mapping to regulations in force in Poland — including PCI DSS 4.0, NIS2 and DORA.
Why the OWASP Web Top 10 is not enough for APIs
It is worth starting with why a separate list even exists. The OWASP Top 10 for web applications (2021 edition, still the current standard) describes a world in which a browser stands between the attacker and the application server — and most classic safeguards (CSP, SameSite cookies, HTML escaping, client-side input validation) rest on that assumption. APIs have no browser. An API client is often a script, a mobile app or another microservice that will execute any request it is told to execute.
In practice this means a shift in the centre of gravity of the problems. In web applications, injection and XSS dominated for a long time. In APIs, authorization problems dominate — who has the right to see this object, change this field, invoke this function. The OWASP API Security Top 10 (2023) explicitly places three different variants of broken authorization (BOLA, BOPLA, BFLA) plus broken authentication and abuse of sensitive business flows in the first five positions. That is no accident — it is a consequence of the fact that APIs give the attacker direct access to domain logic without the UI layer that traditionally masked the shortcomings of backend authorization.
Key difference: In a web application the UI hides the existence of certain endpoints and data. In an API every endpoint is exposed plainly and described in an OpenAPI or Swagger specification. Whatever the backend does not protect, the attacker will find in five minutes.
API1:2023 Broken Object Level Authorization (BOLA)
BOLA — historically known as IDOR (Insecure Direct Object Reference) — remains the most frequent and most serious API problem. It occurs when an endpoint accepts an object identifier in the request and returns data without verifying whether the logged-in user is entitled to that specific object.
Classic PoC: an e-commerce application has the endpoint GET /api/v1/orders/12345. The logged-in user sees their own order. The attacker changes the ID to 12346 and sees someone else’s order together with personal data and delivery address. The backend checked that the user is logged in (authentication) but did not check that object 12346 belongs to that user (authorization).
The test consists of incrementing and decrementing the ID, swapping a UUID for someone else’s (captured from another test session) and checking the response for IDs that do not exist in the control database. Burp Suite with the Autorize extension automates the comparison of responses for two users with different roles. Defence requires a central authorization layer that, on every access to an object, checks the owner or permission relation — rather than relying on the frontend not showing a button.
API2:2023 Broken Authentication
The second category covers everything that breaks the authentication process: weak login mechanisms, no rate limiting on the login endpoint, ability to brute-force, errors in handling JWT tokens, weak password recovery processes and session tokens that do not expire in any sensible way.
A typical PoC involves JWTs. The attacker captures a token, changes the algorithm in the header from RS256 to none (if the server library hastily accepts the algorithm indicated by the client) or swaps the algorithm to HS256 and signs the token with the public RSA key treated as an HMAC secret. In both variants the effect is the forgery of an arbitrary token, including an administrator’s.
The test covers checking whether the server accepts the none algorithm, whether it verifies the signature, whether it rotates keys, whether the login endpoint has rate limiting, whether the “forgot password” flow does not reveal which email addresses exist in the database, and whether the reset process does not allow account takeover via a predictable token. JWT.io and Burp Suite with the JWT Editor extension are standard tools.
API3:2023 Broken Object Property Level Authorization (BOPLA)
BOPLA is a category that combines two historical problems: mass assignment (flooding an object with fields that the attacker should not be able to set) and excessive data exposure (returning fields in the response that the attacker should not see).
PoC for mass assignment: the endpoint PATCH /api/v1/users/me accepts the JSON {"email": "..."}. The attacker adds the field {"role": "admin"} to the JSON, and the backend, using weak deserialisation to a database entity, promotes them to administrator.
PoC for excessive data exposure: the endpoint GET /api/v1/users/me returns the full user object, including the password hash, the API key, internal fields such as is_internal_employee. The frontend selects only the name and avatar from the response, but everything is available to anyone who opens DevTools.
The test consists of fuzzing the fields in the request (which fields the backend will “swallow” and persist) and inspecting the response and comparing it with what is actually displayed in the UI. The defence is an explicit whitelist of fields allowed for writing and a separate DTO for each response, rather than serialising raw entities.
API4:2023 Unrestricted Resource Consumption
The fourth category concerns the lack of limits on resource consumption — CPU, memory, network traffic, database connections, costs of external APIs (SMS, email, OCR, LLM models). Without rate limiting and quotas the attacker can mount a denial-of-wallet attack — the cost to the service is not downtime but a bill from the SMS or OpenAI provider.
PoC: the application exposes an endpoint that generates a PDF report on demand. A single invocation costs 200 ms of CPU. The attacker invokes the endpoint in a loop from ten threads for an hour. Another scenario: the login endpoint sends an SMS code on every request, with no limit on attempts per number.
The test covers checking limits per IP, per user, per API key, limits on request size (Content-Length), limits on GraphQL query depth and limits on the number of items in a single batch request. A reasonable defence is multi-layered rate limiting — in the API Gateway (coarse-grained) and in the application (precise, aware of business context).
API5:2023 Broken Function Level Authorization (BFLA)
BFLA is BOLA at the function level instead of the object level. An administrator endpoint (e.g. DELETE /api/v1/admin/users/123) is accessible to an ordinary user because the backend does not check the role — it assumes that since the UI does not show a “delete user” button, no one will invoke the endpoint.
PoC: the application has a /admin/* section in its OpenAPI documentation. A logged-in user with the role customer sends a request DELETE /api/v1/admin/users/123 and the operation succeeds. The backend authorised based on a pattern in the endpoint name but did not check the role from the token.
The test covers attempting to invoke every administrative endpoint with an unprivileged user’s token. Burp Suite with Autorize or a custom script based on the OpenAPI spec automates the comparison of 200 vs 403 responses. The defence is declarative authorization (e.g. @RolesAllowed decorators in the application layer) and deny-by-default in the API Gateway.
API6:2023 Unrestricted Access to Sensitive Business Flows
The sixth category is a relatively new entry on the list, addressing abuse of business logic. It is not about a single technical bug, but about the fact that critical business flows have no safeguards against automation — bots mass-buy tickets, mass-register accounts, mass-redeem promo codes.
PoC: a scalper bot buys up all the tickets for a concert in the first ten seconds of sale, because the endpoint POST /api/v1/tickets/purchase has no CAPTCHA, no client fingerprinting, no queue and requires no authentication stronger than a session token.
The test requires application-specific threat modelling — the pentester must understand which business flows are attractive to the attacker (coupon, referral, mass sending, catalogue scraping) and judge the proportion of protection to risk. The defence is a multi-layered combination of CAPTCHA for anonymous users, device fingerprinting, queues with limited throughput and monitoring of behavioural anomalies.
API7:2023 Server Side Request Forgery (SSRF)
SSRF in APIs is today one of the most dangerous technical attacks, particularly in cloud and microservices architectures. It occurs when an API accepts a URL from the user (to fetch a webhook, to import a file, for an external integration) and makes a request to that URL without validation.
PoC: the endpoint POST /api/v1/webhooks accepts the field target_url. The attacker sets target_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/. The backend makes a request to the EC2 instance metadata and returns IAM credentials to the attacker, allowing lateral movement in the AWS infrastructure.
The test covers checking whether the API blocks requests to private IP ranges (10.0.0.0/8, 192.168.0.0/16, 169.254.0.0/16), whether it validates the URL scheme (whether file://, gopher://, dict:// are blocked) and whether it has timeouts that prevent blind SSRF. The defence requires a domain allowlist rather than a denylist, validation after DNS resolution (so that the attacker cannot bypass the filter via their own domain pointing to 127.0.0.1) and network segmentation cutting the API server off from instance metadata where possible.
API8:2023 Security Misconfiguration
The eighth category is a bag for all configuration errors — default passwords, unlocked admin ports, enabled debug modes, missing security headers, open CORS, unlocked HTTP methods (TRACE, OPTIONS with verbose response), information about the technology stack leaking in error responses.
PoC: a production API has DEBUG=true modes enabled. Every error returns a full stack trace with file paths, library versions and a fragment of source code. The attacker sees that the backend uses a library in a version vulnerable to a known CVE and attacks under that specific vulnerability.
The test covers scanning security headers (X-Content-Type-Options, Strict-Transport-Security, X-Frame-Options), attempting to elicit verbose errors, checking the CORS configuration (whether Access-Control-Allow-Origin: * coexists with Allow-Credentials: true) and fingerprinting the server and library versions. The defence is stack-specific hardening guides (e.g. CIS Benchmarks) and a CI/CD pipeline that blocks deploys with debug enabled.
API9:2023 Improper Inventory Management
The ninth category is organisational, not purely technical. It concerns the lack of awareness of which APIs even exist in the organisation. Old versions (/api/v1/), test environments (/api/staging/), shadow IT (a microservice created a year ago and forgotten) are often exposed on the internet with weaker protections than the production /api/v3/.
PoC: the current API is /api/v3/, well protected. The old version /api/v1/ from 2019 still responds, because no one switched it off. v1 did not yet have the 2021 BOLA fix and the attacker exfiltrates the entire user database.
The test covers searching for unofficial endpoints (Wayback Machine, Google dorks, GitHub leaks, fuzzing typical patterns), comparing the list of known APIs with the list of production endpoints in the API Gateway, and verifying that the OpenAPI/Swagger documentation is up to date and does not expose endpoints not meant to exist in production. The defence is a central API registry (API catalog/inventory), a deprecate-and-remove policy rather than deprecate-and-forget, and external attack surface management scans.
API10:2023 Unsafe Consumption of APIs
The last category flips the perspective — you are not protecting your API against the attacker, you are protecting yourself against the unpredictable behaviour of third-party APIs you consume. The attacker does not attack you directly, they attack an upstream provider and through their API reach you.
PoC: your backend trusts responses from an external geolocation API and writes them to the database without sanitisation. The attacker compromises the provider (or MITMs the connection, if you do not verify TLS) and injects a payload that on your side causes injection in the reporting layer.
The test covers analysing dependencies on third-party APIs, verifying that responses are validated as rigorously as user input, checking TLS pinning for critical integrations and verifying that your API does not automatically follow redirects to unknown domains. The defence is to treat external APIs as untrusted input — exactly like a form from a user.
API testing tools
API pentesting in 2026 relies on a combination of several tools, each with a different profile. Burp Suite Professional remains the basic workshop — with extensions Autorize (authorization testing), JWT Editor (JWT manipulation), ParamMiner (discovering hidden parameters) and native support for OpenAPI import in 2024+ versions it covers most manual pentest scenarios.
Postman serves for exploration and repeatable test scenarios, especially when the client delivers a ready-made collection. OWASP ZAP is a free alternative to Burp, very strong in automatic scan mode and well integrated with CI/CD. Schemathesis is a property-based fuzzing tool based on the OpenAPI or GraphQL contract — it generates hundreds of thousands of requests checking that the API implementation behaves according to specification (among other things, that it does not return 500 errors on valid input, that it validates types). mitmproxy helps in mobile application testing — it intercepts traffic from a device, allows requests to be swapped in flight and is scriptable in Python.
For GraphQL a separate tool worth attention is InQL (a Burp extension) and GraphQL Voyager for schema visualisation. For gRPC — grpcurl plus custom scripts based on the .proto file. No single tool will replace the pentester, but a well-chosen combination of tools lets you cover routine tests and free up time for manual hunting of business logic abuses.
12-step API pentest checklist
In practice, at nFlo and in many other teams an API pentest proceeds according to a repeatable checklist that ensures repeatability and completeness. The twelve steps below are an abridged version of the process — a full pentest report covers everything from the list below plus what is specific to the given application.
- Gather the specification — obtain the OpenAPI/Swagger contract, the Postman collection, the architecture description, the list of roles and permissions. If a specification does not exist, the pentester reconstructs it based on traffic observation.
- Reconnaissance of the surface — enumeration of all endpoints (production, deprecated, test), identification of API versions and authentication methods. The step addresses risk from API9.
- Authentication testing — verification of login, refresh tokens, JWT, password reset, MFA. The step addresses API2.
- BOLA testing — for every endpoint returning an object, attempt access to an object belonging to another user. The step addresses API1.
- BFLA testing — for every administrative endpoint, attempt invocation with the token of an ordinary user. The step addresses API5.
- BOPLA testing — fuzzing of fields in requests (mass assignment) and inspection of responses (excessive data exposure). The step addresses API3.
- Rate limiting testing — checking limits per IP, user, API key, on the login endpoint, on expensive endpoints. The step addresses API4.
- SSRF testing — for every endpoint accepting a URL, attempt access to the private network and cloud metadata. The step addresses API7.
- Business abuse testing — modelling scenarios specific to the domain (scalping, account takeover, mass onboarding). The step addresses API6.
- Configuration testing — headers, CORS, verbose errors, accessibility of administrative consoles. The step addresses API8.
- External integration testing — analysis of trust in upstream APIs. The step addresses API10.
- Report with prioritisation — description of every finding with CVSS, PoC, remediation recommendation and remediation time estimate, with mapping to the OWASP API Top 10 and the client’s industry regulations.
The duration of a full pentest depends on the number of endpoints and the complexity of the logic — typically between five and fifteen working days for a medium-sized API.
Mapping to PCI DSS 4.0, NIS2 and DORA
The OWASP API Top 10 is not in itself a regulatory requirement, but it is a natural scope framework for the requirements regulations do impose. PCI DSS 4.0 (in force since March 2025), in requirement 6.4.3, explicitly demands protection of web applications against known threats publicly documented — which in practice means OWASP Top 10 and OWASP API Top 10. Requirement 11.4 demands penetration tests at least once a year and after significant changes, and the guidance explicitly recommends that API pentesting be a separate scope.
NIS2 (Directive EU 2022/2555) and the Polish transposition in the amendment to the National Cybersecurity System Act impose on essential and important entities an obligation to manage ICT supply chain risk (Article 21). APIs are today the primary vector of dependency between providers — from cloud service providers to SaaS accounting and CRM systems. An API pentest with mapping to the OWASP API Top 10 is a natural way to demonstrate due diligence with respect to API risks in the supply chain and to fulfil the obligation of periodic resilience testing.
DORA (Regulation 2022/2554) for the financial sector goes further and, in Articles 24-27, introduces an obligation of digital resilience testing, including Threat-Led Penetration Testing (TLPT) for the largest entities. TLPT, like any advanced pentest, covers API testing as one of the main attack vectors — and here mapping to the OWASP API Top 10 is industry standard.
In practice an API pentest report for a client subject to any of the three regulations should have a separate “mapping” column for every finding, indicating both the OWASP category and the specific regulatory requirement. This simplifies the auditor’s work and shows that the pentest is not a one-off event but part of a systematic risk management programme.
Summary
The OWASP API Security Top 10 (2023) is the best technology-neutral and free framework available today for prioritising API security testing. The list is not an exhaustive catalogue of threats, but it well reflects the actual distribution of problems observed across hundreds of pentests. Three of the ten categories concern authorization (BOLA, BFLA, BOPLA), another two — authentication and abuse of business flows. Together they show that the greatest risk to APIs today is not classic injection but fundamental flaws in access control logic.
For development teams the list is a roadmap — where to start, what not to miss in code review, which tests to add to CI. For pentesters it is a baseline scope to be extended with the specifics of the application. For compliance functions it is a bridge between technology and regulation — it lets you demonstrate that the pentest covered risk categories the industry recognises as critical, in a way that PCI DSS, NIS2 and DORA auditors recognise.
Need an API pentest aligned with the OWASP API Top 10 and the requirements of PCI DSS, NIS2 or DORA? Check our penetration testing service — the nFlo team delivers REST, GraphQL and gRPC pentests with full mapping to the OWASP API Security Top 10 and the client’s industry regulations. If you are interested in a comprehensive approach to compliance, our NIS2 compliance audit covers API testing as one of the elements of ICT supply chain risk assessment.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- API — Application Programming Interface — a contract defining how software components communicate with each other.
- SQL Injection — An attack consisting of injecting a fragment of an SQL query into an application’s input data.
- Server — A machine or process handling requests from clients in a client-server architecture.
- SCA — Software Composition Analysis — analysis of software composition for known vulnerabilities in dependencies.
- Encryption — The process of transforming data into a form unreadable without knowledge of the key.
Explore Our Services
Need cybersecurity support? Check out:
- Penetration Testing — identify vulnerabilities in your infrastructure, applications and APIs
- NIS2 Compliance Audit — complete path to alignment with the NIS2 directive and Polish transposition
- SOC as a Service — 24/7 security monitoring
