API Security Testing: The Complete Guide for Developers

APIs now carry most of the traffic in modern applications: mobile apps, single-page front ends, partner integrations and, increasingly, AI agents. They also expose business logic more directly than a web page ever did. An attacker doesn't need to click through your UI. They can call /api/v2/orders/1043 directly, change one number, and see what comes back.

API security testing is how you find out what an attacker would find before they do. This guide is written for developers. It explains what to test, how to test it, which tools help, and how to make the most important checks part of your normal test suite.

Before you start: only test APIs you own or have written permission to assess. Use a non-production environment and test accounts wherever possible. The techniques here are the same ones attackers use, and authorization is what separates testing from attacking.

Table of contents

• What API security testing covers
• The OWASP API Security Top 10 (2023)
• Step 1: Build an inventory of your API
• Step 2: Test authentication
• Step 3: Test authorization at every level
• Step 4: Test input handling and data exposure
• Step 5: Test resource limits and business flows
• Step 6: Test outbound calls and third-party data
• Testing GraphQL APIs
• Automating API security tests in CI
• Tools for API security testing
• Common mistakes
• API security testing checklist
• Frequently asked questions
• Conclusion
• References

What API security testing covers

API security testing checks whether an API enforces the rules it is supposed to enforce: who can call it, what they can see, what they can change, and how much they can consume. It differs from traditional web testing in three ways:

1. No UI hides anything. Every parameter, field and endpoint is directly reachable. Controls that exist only in the front end don't exist.
2. Authorization dominates. APIs pass object identifiers around constantly, so the most frequent serious findings are authorization flaws, not injection.
3. Responses over-share. APIs often return full objects and leave the client to filter them, so data leaks without any "exploit" at all.

There are three common approaches, and mature teams use all three:

The OWASP API Security Top 10 (2023)

The OWASP API Security Top 10 is the standard reference for API risks. The 2023 edition is the current one. Use it to structure your testing:

It complements the web-focused OWASP Top 10 2025. Many API risks have web equivalents, such as broken access control and misconfiguration, but the API list breaks authorization into three separate levels: object, property and function. That's where APIs fail most.

Step 1: Build an inventory of your API

You can't test what you don't know exists. Improper Inventory Management (API9) is on the list because forgotten endpoints are where attackers look first.

Gather:

• The specification. An OpenAPI (Swagger) document is the best starting point. Check whether your API publishes one at common paths such as /openapi.json, /swagger.json or /api-docs. If it is public, decide whether that is intended.
• Real traffic. Proxy your web and mobile clients through an intercepting proxy such as Burp Suite or ZAP. Real clients often call endpoints the spec doesn't document.
• Versions and environments. List every version that still answers (/v1, /v2, /beta) and every host (api., api-staging., internal-api.). Old versions often lack controls that were added to new ones.
• Roles. List each type of user (anonymous, customer, tenant admin, support, platform admin) and create at least two test accounts per role. Two accounts let you test cross-user access.

The output is a matrix of endpoints × methods × roles. It becomes your test plan.

Step 2: Test authentication

Authentication failures (API2) let attackers become someone else. For each authentication mechanism, test:

• Missing authentication. Remove the Authorization header or session cookie. Does the endpoint still answer? Test every method, not just GET.

• Token validation. For JWTs, check that the server:

  • rejects modified payloads;
  • rejects tokens signed with a different key;
  • rejects alg: none;
  • rejects expired tokens;
  • verifies iss and aud.

  RFC 8725 (JWT Best Current Practices) explains why the algorithm must be fixed by the server, never chosen by the token.

• Brute force and credential stuffing. Login, OTP verification and password reset endpoints need rate limits. A 6-digit OTP with no attempt limit can be guessed.

• Token lifecycle. Do tokens stop working after logout or a password change? How long do access tokens live?

• OAuth flows. If you use OAuth 2.0, review redirect URI validation, PKCE, and token storage against RFC 9700, the OAuth 2.0 Security Best Current Practice.

A quick manual check for an unsigned JWT, run only against your own test environment:

# Build a token with alg "none" and the payload of a valid test token.
# A secure API must reject it with 401.
HEADER=$(printf '{"alg":"none","typ":"JWT"}' | base64 | tr '+/' '-_' | tr -d '=\n')
PAYLOAD=$(printf '{"sub":"test-user-2","role":"user","exp":4102444800}' | base64 | tr '+/' '-_' | tr -d '=\n')

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer ${HEADER}.${PAYLOAD}." \
  https://api.staging.example.com/v1/me
# Expected: 401

Step 3: Test authorization at every level

This is the most important step. Three of the top five API risks are authorization failures.

Object level (API1: BOLA)

Log in as user A, create or find an object, and note its ID. Then log in as user B and request that object:

# As user A: create an order and note its ID (e.g. 1043)
curl -s -H "Authorization: Bearer $TOKEN_A" https://api.staging.example.com/v1/orders/1043

# As user B: the same request must fail
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $TOKEN_B" https://api.staging.example.com/v1/orders/1043
# Expected: 403 or 404 — never 200

Repeat for every method (GET, PUT, PATCH, DELETE) and every place an ID appears: path, query string, JSON body, headers. Also try nested routes such as /users/{userId}/orders/{orderId}. Some APIs check the parent ID and trust the child. OWASP is explicit that comparing the session's user ID with a URL parameter is not a sufficient fix on its own. The check must answer "may this user perform this action on this record?". We cover this in depth in our article on BOLA vulnerabilities.

Property level (API3)

Two directions:

• Excessive data exposure. Compare each response with what the client actually displays. Does /v1/users/me return passwordHash, mfaSecret, isAdmin or other users' email addresses?
• Mass assignment. Send fields the client never sends. If the API binds request bodies directly to models, this request might work:

curl -s -X PATCH https://api.staging.example.com/v1/users/me \
  -H "Authorization: Bearer $TOKEN_B" \
  -H "Content-Type: application/json" \
  -d '{"displayName":"Bob","role":"admin","emailVerified":true}'
# Then GET /v1/users/me — role and emailVerified must be unchanged

The fix is an explicit allowlist of writable fields per role. See the OWASP Mass Assignment Cheat Sheet.

Function level (API5: BFLA)

Using a normal user's token, call endpoints meant for other roles: /v1/admin/users, DELETE /v1/products/{id}, POST /v1/tenants/{id}/invite. Guess predictable admin paths from the patterns in your spec. A frequent finding: the admin UI is hidden from normal users, but the admin API doesn't check the role.

A simple way to stay organized is an authorization matrix:

Every "?" is a test case. Every unexpected 200 is a finding.

Step 4: Test input handling and data exposure

APIs are still vulnerable to classic injection. Test each parameter for:

• SQL and NoSQL injection. Quotes, operators such as {"$ne": null} in JSON bodies, and type confusion (an array where a string is expected).
• Server-side parameter pollution. Duplicate parameters, or values that get forwarded to internal APIs. PortSwigger has a good explanation.
• Content-type confusion. Send XML to a JSON endpoint. Some frameworks parse it anyway, which can open XXE.
• Error handling. Malformed input should produce a consistent, generic error, such as RFC 9457 problem details, not stack traces, SQL fragments or internal hostnames.

Schema-based fuzzing helps here. A tool reads your OpenAPI spec and generates valid and invalid requests automatically, so it can cover parameters you would never test by hand.

Step 5: Test resource limits and business flows

Unrestricted Resource Consumption (API4). Check for limits on:

• page size (?limit=100000);
• upload size;
• request rate per user and per IP;
• expensive operations such as exports, report generation and search.

Also check costs that hit you directly: SMS, email or AI model calls triggered per request.

Sensitive Business Flows (API6). These are legitimate actions that cause harm when automated at scale:

• creating thousands of accounts to abuse a referral bonus;
• reserving inventory without paying;
• scraping every product price;
• posting spam reviews.

Ask product owners which flows would hurt the business if a bot did them 10,000 times, and test whether anything stops it.

Step 6: Test outbound calls and third-party data

Server Side Request Forgery (API7). Any feature where the API fetches a URL is an SSRF candidate: webhooks, "import from URL", image previews, PDF generators. Supply URLs pointing at:

• localhost;
• private IP ranges;
• cloud metadata endpoints;
• internal hostnames.

Watch for redirects and DNS tricks that pass an allowlist check and then resolve internally. The OWASP SSRF Prevention Cheat Sheet describes robust defenses.

Unsafe Consumption of APIs (API10). Your API probably calls other APIs, such as payment providers, enrichment services and AI models. Check that data from them is validated and treated as untrusted, that redirects aren't followed blindly, and that timeouts are set. A compromised or misbehaving third party shouldn't be able to inject into your database or crash your service.

Testing GraphQL APIs

GraphQL changes the mechanics, but not the risks:

• Introspection. Check whether introspection is enabled in production. It's not a vulnerability by itself, but it maps the whole schema for an attacker. Many teams disable it outside development.
• Authorization per resolver. Authorization must be enforced in each resolver or field, not just at the endpoint. Test queries and mutations that take IDs exactly like REST BOLA tests.
• Query cost. Deeply nested queries, aliases (the same expensive field requested 1,000 times in one request), and batched operations can bypass per-request rate limits. Look for depth limits, cost analysis and limits on batching.

See the OWASP GraphQL Cheat Sheet and PortSwigger's GraphQL labs.

Automating API security tests in CI

Manual testing finds flaws. Automated tests keep them fixed. The highest-value automated security test is an authorization test that runs on every pull request:

// orders.authz.test.js — runs against a test environment with seeded users
import { describe, it, expect } from "vitest";
import { apiAs } from "./helpers/api-client.js"; // returns a fetch wrapper with a test user's token

describe("orders authorization", () => {
  it("lets the owner read their order", async () => {
    const res = await apiAs("alice").get("/v1/orders/order-alice-1");
    expect(res.status).toBe(200);
  });

  it("does not let another customer read it", async () => {
    const res = await apiAs("bob").get("/v1/orders/order-alice-1");
    expect([403, 404]).toContain(res.status);
  });

  it("does not let a customer change the order owner", async () => {
    await apiAs("alice").patch("/v1/orders/order-alice-1", { ownerId: "bob" });
    const res = await apiAs("alice").get("/v1/orders/order-alice-1");
    expect(res.body.ownerId).toBe("alice");
  });
});

Add a schema-based fuzzer and a DAST baseline scan to the same pipeline:

• Schema-based fuzzing. Schemathesis generates test cases from your OpenAPI or GraphQL schema and reports server errors and responses that don't match the schema.
• DAST baseline. ZAP can run an API scan using your OpenAPI definition.

Fail the build on new high-severity findings, and review the rest.

Tools for API security testing

Tools don't replace understanding. A scanner can't know that user B shouldn't see user A's invoice. You have to tell it, through test accounts and expected results.

Common mistakes

• Testing with a single account. Most serious API flaws only appear when you have two users and two roles.
• Trusting the front end. Hidden buttons and disabled fields aren't access control.
• Testing only the documented API. Old versions, mobile-only endpoints and staging hosts are part of your attack surface.
• Treating unpredictable IDs as protection. UUIDs slow down enumeration, but IDs leak through URLs, logs, emails and other API responses. Authorization still has to be checked.
• Rate limiting only by IP. Attackers rotate IPs cheaply. Limit by account and token too, and protect the business flow itself.
• Leaving security testing until the end. Authorization rules are easiest to test when they're defined, so write the tests with the feature.

API security testing checklist

• Inventory complete: spec, versions, hosts and roles, with two test accounts per role.
• Every endpoint rejects missing, expired, tampered and alg: none tokens.
• Login, OTP and reset endpoints are rate-limited, and tokens are invalidated on logout and password change.
• Cross-user object access is tested for every method and ID location (API1).
• Responses contain only the fields the client needs, and writable fields are allowlisted (API3).
• Role-restricted functions are tested with lower-privileged tokens (API5).
• Page size, payload size, rate and expensive operations are limited (API4).
• Sensitive business flows have abuse controls (API6).
• URL-fetching features are protected against SSRF (API7).
• CORS, TLS, error messages and HTTP methods are hardened (API8).
• Old API versions and non-production hosts are retired or protected (API9).
• Third-party API responses are validated and given timeouts (API10).
• Authorization tests run in CI on every change.

Frequently asked questions

What is API security testing?

API security testing checks that an API correctly enforces authentication, authorization, input validation and resource limits, and doesn't expose sensitive data. It combines automated scanning, developer-written tests and manual testing.

How is API penetration testing different from API security testing?

API security testing is the broad practice, including automated checks in CI. API penetration testing is a focused, usually manual assessment by security specialists who try to exploit weaknesses, especially authorization and business-logic flaws, the way a real attacker would.

What is the most common API vulnerability?

Broken Object Level Authorization (BOLA) is ranked first in the OWASP API Security Top 10 (2023). It happens when an API returns or changes an object without checking that the caller is allowed to access that specific object.

Can I test API security with Postman?

Postman is useful for organizing requests per role and scripting simple assertions, such as checking that user B gets a 403. For intercepting traffic, fuzzing and deeper manual testing, pair it with a proxy such as Burp Suite or ZAP.

How often should APIs be security tested?

Run automated tests on every change. Commission a manual assessment before major releases, after significant changes to authentication or authorization, and at least annually for APIs that handle sensitive data.

Do GraphQL APIs need different security testing?

The risks are the same, especially authorization, but the techniques differ. Test introspection exposure, per-resolver authorization, query depth and cost limits, and batching or alias abuse.

Is the OWASP API Security Top 10 updated for 2025 or 2026?

At the time of writing, the 2023 edition is the latest published version of the OWASP API Security Top 10. The web application list was updated separately as the OWASP Top 10:2025.

Conclusion

Good API security testing is systematic. Know every endpoint, test it as every role, and assume the client is hostile. Most serious API flaws aren't exotic. They are missing checks in places nobody tested with a second account. Turn your most important authorization rules into automated tests, and bring in manual testing for what tests can't anticipate.

If your API handles customer data, payments or multi-tenant workloads, an independent assessment is worth it. Cyber Secret Society's API security testing service covers the full OWASP API Security Top 10, with a focus on the authorization and business-logic flaws that automated tools miss. Every finding comes with reproducible requests and developer-ready fixes. Request an assessment or review our testing methodology.

References

• OWASP API Security Top 10 – 2023 edition
• OWASP API Security category pages: API1 BOLA, API2, API3, API4, API5, API6, API7, API8, API9, API10
• NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (updated March 2026)
• OWASP Cheat Sheets: REST Security, Authorization, Mass Assignment, JSON Web Token, GraphQL, SSRF Prevention
• RFC 8725 – JSON Web Token Best Current Practices
• RFC 9700 – OAuth 2.0 Security Best Current Practice
• RFC 9457 – Problem Details for HTTP APIs
• OpenAPI Specification
• PortSwigger Web Security Academy: API testing, Server-side parameter pollution, GraphQL API vulnerabilities
• MITRE CWE-639: Authorization Bypass Through User-Controlled Key
• Tools: ZAP, Schemathesis