- Security testing asserts on what an API must refuse to do — the inverse of functional testing.
- Broken Object Level Authorization — changing an ID in a URL and receiving another user's data — has headed every edition of the OWASP API Security Top 10.
- Testing it requires two accounts. With a single test user, the entire category is untestable.
- Automation reliably catches the mechanical classes; business-logic flaws still need a human.
What is API security testing?
API security testing probes an interface for weaknesses an attacker could exploit — broken authorization, weak authentication, injection, excessive data exposure and missing rate limits. It differs from functional testing in orientation: functional tests confirm the API does what it should, security tests confirm it refuses what it shouldn't.
That inversion is why security gaps survive well-tested codebases. A suite can have complete coverage of every documented behaviour and never once ask what happens when a user requests a record belonging to someone else.
The OWASP API Security Top 10
The OWASP API Security Top 10, maintained by the Open Worldwide Application Security Project, is the standard reference for API risk. These are the categories that matter most in practice, with the probe for each.
1. Broken Object Level Authorization (BOLA)
The most common serious API flaw. An endpoint accepts an identifier and returns the corresponding record without checking whether the caller is entitled to it.
How to test it: authenticate as user A, note the ID of a resource they own, then request that same ID as user B. A correct API returns 403 or 404. A 200 with user A's data is a confirmed vulnerability. Repeat for every endpoint accepting an identifier — including nested paths like /orders/{id}/items, which are frequently missed because the parent check is assumed to cover them.
This single test class deserves disproportionate attention. It requires no special tooling, needs only two accounts and an ID swap, and finds real vulnerabilities in a large fraction of APIs that have never been tested for it.
2. Broken Authentication
Weaknesses in how identity is established. Probe for: tokens that survive logout, missing signature verification, the alg: none JWT attack, tokens without expiry, password reset flows that leak whether an account exists, and login endpoints with no rate limiting.
3. Broken Object Property Level Authorization
Two failure modes. Excessive data exposure: the endpoint returns the full record and expects the client to display a subset, so password hashes, internal flags and other users' emails travel over the wire. Mass assignment: the endpoint binds the request body straight to a model, so adding "role": "admin" to a profile update escalates privilege. Test by inspecting complete responses for fields the client never displays, and by submitting fields the client never sends.
4. Unrestricted Resource Consumption
Missing rate limits and unbounded operations. Probe with a burst of requests to confirm 429 arrives with a Retry-After header, request a page size of 100,000, and submit deeply nested JSON. For GraphQL, an over-deep query — see GraphQL testing for depth and complexity limits.
5. Broken Function Level Authorization
Administrative functions reachable by ordinary users. Test by enumerating admin endpoints and calling each with a standard user token, and by swapping HTTP methods — an endpoint correctly restricting DELETE may leave PUT unguarded.
6. Injection
SQL, NoSQL, command and template injection. Send payloads such as ' OR '1'='1, {"$gt": ""} and {{7*7}} into every parameter that reaches a query. The correct response is a 400 rejecting the input. A 500 suggests the payload reached the interpreter; a 200 with unexpected data suggests it succeeded.
7. Security Misconfiguration
The cheapest category to fix and the most commonly neglected. Check for missing HSTS, absent X-Content-Type-Options, permissive CORS (Access-Control-Allow-Origin: * alongside credentials), verbose errors exposing stack traces or framework versions, and enabled debug endpoints.
Building it into the pipeline
- Create two test users with identical permissions. Cross-user authorization testing is impossible without them, and this is the single highest-value setup step.
- Generate an authorization matrix. For every endpoint and every role, record the expected status. Turn the matrix into tests.
- Run injection and fuzz probes nightly. They are too slow for every commit but too valuable to run quarterly. See fuzz testing.
- Assert on security headers in smoke tests. They are fast, deterministic and regress silently after infrastructure changes.
- Fail the build on new findings, not on the existing backlog. A gate that fails from day one gets disabled within a week.
Where automation stops
Automated probes reliably catch the mechanical classes: missing authentication, injection reflections, absent rate limits, verbose errors, missing headers, and object-level authorization once you supply two accounts. These are pattern-matchable, and there is no reason to pay a human to find them.
What automation cannot find is business-logic abuse — applying a discount code twice, transferring a negative amount to reverse a payment, ordering a refund before a return. These require understanding what the application is for. Automation's job is to clear the mechanical backlog so a penetration test spends its budget on the logic instead.
Run security and fuzz probes against your API
Paste a URL. Flasqo discovers your endpoints, generates the suite and runs it — free, no credit card.
Start testing free