One small open-source ERP. One security assessment. Nine CVEs, and most of them returned a clean HTTP 200 the whole way through the attack.
That is the uncomfortable truth about API security. The requests that break an API rarely look broken. They are well-formed, authenticated, and answered politely, and the damage is that they succeeded when the application should have said no.
This guide is about finding those requests before someone else does. It covers what API security testing is, how it differs from the functional testing your team already runs, the risks that actually cause API breaches, and a methodology you can apply to your own endpoints. The nine findings above come from research by CodeAnt AI, and they run through this piece as worked examples rather than a highlight reel.
What You'll Learn
What API security testing is, and how it differs from functional API testing and full penetration testing.
The OWASP API Security Top 10, current edition, mapped to real CVEs from a single assessment.
A step-by-step methodology, from endpoint inventory to confirming impact.
Why automated scanners miss the worst API bugs, and what closes the gap.
What Is API Security Testing?
API security testing is the practice of probing an API to find requests that succeed when they should be refused. It checks authorization, authentication, input handling, and business logic, rather than whether the API returns the right data to a well-behaved caller.
The goal is abuse, not correctness. A functional test confirms that GET /users/1 returns user 1. A security test asks whether a caller who is allowed to read user 1 can also read user 2, write user 2's salary, or approve their own expense claim through the same route.
APIs make this the main event, not a side quest. They expose application logic and data directly, in a format built for machines to call at scale, so a single unchecked parameter is reachable by anyone with a key and a script.
API Testing vs API Security Testing vs API Penetration Testing
These three terms get used interchangeably, and they are not the same job. They share tools and diverge on intent.
API testing (functional) | API security testing | API penetration testing | |
|---|---|---|---|
Question it answers | Does the API work correctly? | Can the API be abused? | Can an attacker chain abuses into real impact? |
Typical owner | QA and developers | AppSec and developers | Security team or external testers |
What it checks | Responses, schemas, performance, edge inputs | Authorization, authentication, input handling, business logic | End-to-end exploit paths, privilege escalation, data exfiltration |
Cadence | Every build, in CI | Continuous, plus periodic deep testing | Point-in-time, at least annually and after major change |
Output | Pass or fail on the contract | A ranked list of weaknesses | Proven exploit chains with evidence |
The takeaway is that functional testing keeps the API honest for people using it as intended. The other two ask what happens when someone does not, and that is what the rest of this guide covers.
Why API Security Testing Matters
APIs moved from plumbing to product. They now carry the logic and the sensitive data that used to sit behind a server-rendered web form, and they carry it in a format designed for automation.
Two forces sharpen the risk. Nearly every developer now builds with generative AI, while only a fraction design their APIs for the machine-speed traffic that AI agents generate, a gap Postman has tracked across its State of the API research. An endpoint built for human-paced use behaves differently when an agent calls it thousands of times a second.
The result is a wide attack surface that traditional web testing was never shaped for. A web app has pages and forms a human clicks through. An API has hundreds of endpoints, each with parameters, each reachable directly, many of them undocumented or left over from a previous version.
OWASP API Security Top 10: Risks Mapped to Real CVEs
The reference standard for API risk is the OWASP API Security Top 10. One point of confusion is worth clearing up first, because it trips up a lot of teams.
OWASP shipped a new web application Top 10 in the 2025 edition, finalized in early 2026. The API Security Top 10 is a separate list, and its current edition is still 2023. When you scope API testing, the 2023 API list is the one that applies.
Here is that list, with what each risk means in plain terms and where it showed up in the CodeAnt research on Dolibarr, an open-source ERP.
Risk (API Top 10 2023) | What goes wrong | Seen in the research |
|---|---|---|
API1 Broken Object Level Authorization | A caller reaches another object by supplying its ID, with no ownership check | CVE-2026-71505 portal takeover, CVE-2026-71507 IBAN redirection |
API2 Broken Authentication | Logins, tokens, or keys can be guessed, forged, or bypassed | Chained from CVE-2026-71503, reflected XSS to a second admin and a stolen key |
API3 Broken Object Property Level Authorization | A caller writes fields it should not set, or reads fields it should not see | CVE-2026-71504 and CVE-2026-71508 mass assignment, CVE-2026-71510 and CVE-2026-71511 data exposure |
API4 Unrestricted Resource Consumption | No rate or cost limits, so one caller exhausts compute, memory, or spend | Not covered in this assessment |
API5 Broken Function Level Authorization | A low-privilege caller reaches an action meant for a higher role | CVE-2026-71506 payment deletion, CVE-2026-71509 expense self-approval |
API6 Unrestricted Access to Sensitive Business Flows | A flow like signup or checkout can be automated and abused at scale | Not covered in this assessment |
API7 Server Side Request Forgery | The API fetches an attacker-supplied URL and reaches internal systems | Not covered in this assessment |
API8 Security Misconfiguration | Weak defaults, verbose errors, and missing hardening leak access or information | Partly, a verbose SQL error that mapped the schema in the column-disclosure finding |
API9 Improper Inventory Management | Old, undocumented, or debug endpoints stay exposed and unpatched | Not covered in this assessment |
API10 Unsafe Consumption of APIs | An application trusts data from a third-party API too much | Not covered in this assessment |
Notice where the evidence clusters. Eight of the nine findings are authorization failures, spread across API1, API3, and API5.
That is not a quirk of one codebase. Authorization is the hardest API control to get right, because it depends on context the framework cannot see on its own, who the caller is, what they own, and what this specific action is supposed to mean.
The Dolibarr set shows the pattern in one recurring shape, which the research calls split-brain authorization. Two routes write the same database row, and only one of them checks whether the caller may. The dedicated endpoint enforces the rule, and a second, more general endpoint reaches the same data and never runs it. The full write-up walks all nine.
How to Perform API Security Testing: A 6-Step Methodology
A good test is systematic, not a grab bag of payloads. The order below front-loads the checks that find the most real damage.
1. Inventory every endpoint, parameter, and role
You cannot test what you have not mapped. Pull the OpenAPI or Swagger spec, then compare it against real traffic, because specs drift and the dangerous endpoints are often the undocumented ones.
Enumerate the roles too. Provision a low-privilege account, a peer account, and an admin, since most authorization testing is a comparison between what each role can reach.
2. Test authorization first
This is where the breaches are, so spend the most time here. For object-level access, take a request that works for your account and replay it against another user's object ID, watching for a 200 that should be a 403.
For function-level access, take an admin-only action and send it from a low-privilege key. The finding is any state-changing call that succeeds without the right the action is supposed to require.
3. Test authentication and tokens
Check how sessions, JWTs, and API keys are issued, validated, and revoked. Look for tokens that never expire, signatures that are not verified, and keys that carry more scope than the caller needs.
Weak authentication rarely acts alone. It becomes the entry point that makes an authorization flaw reachable, the way a stolen key turns a read-only account into a launch pad.
4. Probe input handling
Send malformed, oversized, and unexpected input to every parameter, and confirm the API rejects it rather than passing it downstream. Injection still matters here, in SQL, NoSQL, command, and template forms.
Read the error responses closely. A verbose stack trace or database error is a finding in itself, because it hands an attacker a map of the schema before they read a single value.
5. Attack the business logic
This is the step scanners cannot do for you. Ask what the workflow assumes and then break the assumption, filing an expense and approving it yourself, or setting a field that a different permission is supposed to own.
Every request here is valid and authenticated. The bug is that the application allowed a sequence its own rules forbid, and only a tester who understands the workflow can see it.
6. Confirm impact, then rank by it
A status code is not proof. Confirm each finding by the state it changed, the row that moved, the record you should not have read, the account that gained rights.
Rank what you find by real impact, not by scanner severity. A self-approval that reaches the finance queue outranks a missing header, whatever a tool scores them.
Why Automated API Security Scanners Miss the Worst Vulnerabilities
Automated scanners are genuinely good at one half of this list. They catch missing security headers, injectable parameters, known-vulnerable components, and exposed debug routes, and you should run them continuously.
They go quiet on the other half. Business-logic and authorization flaws use valid, authenticated requests that return normal responses, so there is no malformed input to match and no error to flag. The scanner sees a clean request answered correctly, because that is exactly what it is.
The column-disclosure finding is the sharp version of this. Its filter passed every injection check, because the regex stripped every special character an injection needs. The filter did its job. Its job was the wrong job, and no signature could tell.
Closing that gap takes reasoning across roles and routes, which is manual work, or agentic work that behaves like a careful tester rather than a pattern matcher.
Where CodeAnt fits: CodeAnt AI is a defensive and offensive security platform, pairing AI code review and SAST with agentic pen testing. Its agentic pentesting chains authenticated requests across roles and routes and proves each finding by the state it changed, not the status code it returned, which is how the nine findings above were confirmed.
How to Build API Security Testing Into Your Development Workflow
Point-in-time testing alone leaves most of the year uncovered, because new endpoints ship every week. The fix is two layers running at different speeds.
The fast layer lives in CI. Wire schema validation, dependency checks, and known-issue scanning into every pull request, so a broken auth check or an outdated library fails the build before it merges.
The deep layer runs on a cadence. Book a full API penetration test at least annually and after any major change to authentication, authorization, or a sensitive data flow, and treat the business-logic review as the part only a human or an agent can do.
Keep an inventory underneath both. An endpoint nobody remembers is an endpoint nobody tests, and improper inventory management is on the OWASP list for exactly that reason.
API Security Testing Is About Proving What Should Not Be Possible
API security testing is not about finding endpoints that return errors. It is about proving that requests which look completely legitimate can still cross a boundary they should not.
The OWASP API Security Top 10 tells you where those boundaries usually fail. The nine Dolibarr CVEs show what happens when they do: another user's account becomes accessible, a payment gets redirected, payroll data changes, or an attacker creates an administrator, sometimes while every request returns a perfectly normal 200.
That is why effective API security testing combines automated coverage with reasoning across endpoints, roles, objects, permissions, and business workflows. The hardest vulnerabilities are often the ones that look completely normal to a scanner.
The question is not whether your API works. It is whether it refuses the requests it should.
Test your APIs beyond the 200… CodeAnt AI combines code-aware security analysis with agentic penetration testing to trace API vulnerabilities from source code to a working exploit. Instead of stopping at a suspicious response, it tests authenticated attack paths across roles and endpoints and validates the resulting impact.
See how CodeAnt AI tests APIs →
If you're building or securing APIs, start with the API penetration testing guide to turn the methodology in this guide into an actual test plan.
