API Security Testing Beyond OWASP API Top 10

The OWASP API Security Top 10 is useful onboarding material. It is not a testing methodology, and it should not be the ceiling of an API security assessment. During enterprise web and API engagements we frequently identify critical findings that map awkwardly to the OWASP list, or do not map at all. They are findings automated scanners do not surface, authenticated DAST does not reach, and internal review usually treats as theoretical. They are also the findings that move risk in real environments.

This post walks through eight patterns we see in nearly every API assessment for financial services, healthcare, and B2B SaaS clients in Toronto and across Canada.

Why the OWASP API Top 10 Is a Starting Line, Not a Methodology

The OWASP API Security Top 10 (2023 edition) is a taxonomy of common categories. It tells you what classes of failure exist. It does not tell you how to find them in a specific environment, what the exploit chain looks like in your tech stack, or which finding actually carries business impact.

Categories overlap. A broken object property level authorisation finding (API3:2023) often coexists with broken function level authorisation (API5:2023) and broken authentication (API2:2023). One root cause produces three findings that look distinct on a report but share remediation.
It is identity-provider agnostic. Real APIs fail in patterns specific to Cognito, Auth0, Azure AD, Keycloak, or custom JWT middleware.
It is silent on business logic. The most damaging issues we report rarely match a category, because business logic vulnerabilities are by definition application-specific.

JWT Algorithm Confusion in Practice

JWT algorithm confusion is one of the oldest authentication mistakes still shipping in 2026. The exploit assumes a server library will accept both RS256 (asymmetric, RSA signature) and HS256 (symmetric, HMAC) on the same endpoint without an explicit algorithm whitelist.

How the attack works

When the server verifies an RS256 token, it uses the RSA public key to validate the signature. That public key is often exposed at /.well-known/jwks.json, in an OIDC discovery document, or embedded in a mobile app. An attacker downloads the public key, then constructs a new token with alg set to HS256 and signs it using the public key as the HMAC secret. If the verification library accepts any algorithm the token declares, it validates the HS256 signature using the same key material, and the forged token passes.

How we test for it

curl https://target.example.com/.well-known/jwks.json | jq -r '.keys[0]' > pubkey.json
jwt encode --secret @pubkey.pem --alg HS256 '{"sub":"admin","roles":["administrator"]}'

Defensive guidance

Pin the accepted algorithm explicitly at verification time. Never accept alg from the token header.
Reject tokens with alg=none at the gateway.
Use separate verification keys for separate token issuers.
Where possible, switch to opaque tokens validated by introspection (RFC 7662).

GraphQL Introspection and Schema Abuse

GraphQL introspection is a developer convenience that frequently survives into production. The __schema query returns the complete type system, including every field, mutation, and argument.

What "disabled introspection" still leaks

Teams that have disabled introspection often leave field suggestions enabled. A query against a misspelled field returns an error message containing similar valid field names. Iterating against this behaviour reconstructs the schema without ever running an introspection query. Apollo Server, GraphQL Yoga, and Hot Chocolate all have this behaviour by default.

Field-level authorisation drift

The most consistent GraphQL finding we report is field-level authorisation gaps. A type User may expose email and passwordResetToken in the same shape, with authorisation checked only on the top-level query, not on each field. A standard user querying me { passwordResetToken } retrieves another user's reset token if the resolver does not check ownership for that specific field.

OAuth Scope Escalation and Token Confusion

Front-end vs back-end scope assumptions

A frequent finding is a back-end API that checks the presence of a token but not the scopes the token actually carries. The front-end requests read:invoices when the user signs in. The API accepts any valid token, regardless of granted scope, because scope enforcement was assumed to be the front-end's job.

We test by replaying authenticated calls using tokens issued for unrelated scopes, sometimes from a different client application registered against the same authorisation server.

Refresh token reuse and silent privilege upgrades

Refresh tokens issued long before a permission change continue to mint access tokens after the change should have demoted the user. Where the authorisation server caches user roles at refresh time and does not re-evaluate against the source of truth, a revoked admin remains an admin until the refresh window expires.

Mass Assignment in Nested Object Graphs

Mass assignment is the original API vulnerability, and it has not gone away. The pattern modern frameworks introduce is mass assignment through nested object graphs. A profile update endpoint accepts PATCH /users/me with a JSON body. The serializer maps incoming fields onto the model. Fields like role, tenant_id, email_verified, and billing.plan often are not in the allowlist, but the serializer accepts them anyway.

In nested cases, the problem deepens. {"name":"Ana","organization":{"id":"other-tenant-uuid"}} moves the user to a different tenant if the ORM's nested-update behaviour writes through the relationship without authorisation.

Business Logic Race Conditions

Race conditions in API endpoints are increasingly common as teams move to event-driven and microservices architectures. The endpoint validates state, then performs an action. Between the validation and the action, a parallel request changes state. Patterns we see most often:

Discount and gift card redemption. Two parallel requests to redeem the same one-time code, where the redemption check is read-then-write without a database-level uniqueness constraint or row lock.
Limit checks on withdrawals or transfers. Daily limit is read at request time, two concurrent withdrawals each pass the check, both execute.
Account creation with unique username. Concurrent signups with the same username, both pass the existence check, both insert.
Friend or follow requests bypassing block lists. Block check and follow-insert are not atomic.

During testing we use Burp turbo intruder or simple Go goroutines to fire 50-200 concurrent requests at endpoints where state transitions matter. Endpoints that pass functional testing fail consistently under concurrency.

API Authorization Failures Beyond BOLA

Endpoints that enforce ownership at object level but accept query parameters which filter across tenants. GET /api/reports?tenant=other returns the other tenant's data because filtering is done in the database query and not validated against the caller's identity.
Admin endpoints reachable from outside the admin network because the network ACL is enforced in the load balancer for one path but the application also serves the same controller on a second mount point.
Feature flags that gate UI but not API. A "preview" feature disabled in the customer's settings UI is still callable via the underlying endpoint.
Time-bound authorisations (free trial expired, contract ended) enforced in the billing service but not in the API resource servers.

API Gateway Trust Assumptions

API gateways are often misused as security boundaries when they are really routing tools. The trust assumption fails in three places:

Back-end services accessible directly. Service-to-service network is rarely as restricted as the diagram. We routinely identify private subnets where back-end pods or VMs accept connections from anywhere inside the VPC.
Header trust. The gateway adds headers like X-User-Id or X-Tenant-Id after authenticating. The back-end trusts those headers. If the back-end is reachable directly, an attacker injects whatever values they want.
Inconsistent enforcement across gateway paths. A new endpoint added via a wildcard route inherits the wildcard policy, which is usually weaker than the explicit policies of older named routes.

CI/CD Pipeline API Exposure Risks

OIDC trust relationships from GitHub Actions, GitLab CI, or CircleCI into cloud accounts that permit any repository or any branch to assume privileged roles. We frequently identify findings where the OIDC sub claim filter is too permissive (repo:org/* instead of repo:org/specific-repo:ref:refs/heads/main).
Pipeline secrets exposed via build artifacts, log files, or downloadable workflow runs.
Self-hosted runners on writable infrastructure where one job can persist tools that the next job inherits.

How We Actually Test APIs During an Engagement

Surface discovery. Crawl documented endpoints, parse OpenAPI or GraphQL schemas where exposed, intercept mobile and SPA traffic, enumerate paths from JavaScript bundles, and identify legacy or undocumented versions still routed.
Identity and trust modelling. Map every authentication path, token type, scope set, and role.
Per-endpoint behavioural testing. Replay each operation as unauthenticated, low-privilege, peer-tenant, and high-privilege identities. Differences that should not exist become findings.
State and concurrency testing. Identify endpoints that transition state. Fuzz with concurrent requests against business invariants.
Boundary review. Test the gateway, the back-end direct reachability, the CI/CD identity, and the secret stores feeding the deployment.
Reporting with attack chains, not just findings. A BOLA chained with a JWT alg confusion that issues admin tokens is an attack path, and that distinction matters to engineering leadership.

Compliance Relevance

PCI DSS v4.0: Requirements 6.2, 6.3.2, 8.3.1, 11.4. Authentication and authorisation findings on cardholder data APIs are direct requirement failures.
SOC 2 CC6.1, CC7.1: Logical access controls and system monitoring. API authorisation gaps that allow tenant crossover are direct evidence that logical access boundaries are not in place.
PIPEDA Schedule 1 Principle 7: Personal information exposed via API authorisation failure is a reportable safeguard failure.

Frequently Asked Questions

Is the OWASP API Security Top 10 enough for a complete API assessment?

No. It is a useful taxonomy and we map findings to it for reporting consistency, but it is not a methodology. Real engagements require identity modelling, business logic testing, concurrency probing, and infrastructure boundary review.

How long does a typical API penetration test take?

For a contained API with 30 to 80 endpoints and two identity tiers, two weeks of testing time is typical. Large multi-tenant APIs with federated identity, multiple gateway tiers, and event-driven back ends usually need three to five weeks.

Can automated scanners replace manual API testing?

Scanners are useful for known-pattern coverage. They do not find business logic flaws, race conditions, complex authorisation gaps, or JWT alg confusion in non-trivial token shapes. We use automation for breadth and human testing for depth.

How do you test APIs without breaking production?

Most engagements run against a staging or pre-production environment that mirrors production architecture. Where production testing is required, we coordinate with the client on testing windows, rate limits, and rollback procedures.

Do you provide remediation support after the engagement?

Yes. Every engagement includes a remediation re-test pass at no additional cost within 60 days of the original report. For larger remediation programs we provide architecture-level guidance.

What deliverables come out of an API security assessment?

An executive summary mapped to business impact, a technical findings report with reproduction steps for every issue, a compliance mapping (PCI DSS, SOC 2, PIPEDA), and an attack chain diagram for findings that combine.

API Security Testing: The OWASP Top 10 Misses Half the Story