Authentication Testing

Authentication mechanisms are the gatekeepers of the API. Weaknesses here can lead to full account takeover. On an API the question is narrower than on a web app: where does the credential live, what does it claim, and does the resource server actually check those claims rather than trusting the header it was handed?

JWT: the API-Specific Part

The JWT attack catalogue — alg: none, weak HMAC secrets, RS256→HS256 confusion, kid path traversal, jku/x5u header injection — is owned by Web Pentest 06t — JWT Attacks and is not repeated here. What changes on an API is how the token travels, where it is stored, and which claims the resource server is willing to be lied to about.

Header or cookie: what the trade-off actually costs

Token storage

Read the client before you touch the server. In a browser SPA, an access token in localStorage is readable by any injected script and survives a tab close; a refresh token there is worse, because it mints new access tokens indefinitely. Check Application → Storage in DevTools after login, then check whether the refresh endpoint accepts the same token from a different origin.

aud and scope: the claims that are never checked

A token is valid for a purpose, not for everything the issuer signs. The failure mode on APIs is a resource server that verifies the signature and stops there: any token from the same issuer — a partner integration, a low-scope client, a different service — is then accepted as a user session.

• Audience confusion: take a token minted for service A and replay it against service B. If B accepts it, aud is either absent from the check or compared as a substring.
• Scope escalation: re-request the same grant with a wider scope than the client asked for, then use the token on an endpoint outside the original grant.
• Scope not enforced: a read-only token that can still POST means scopes are decoration, not authorization.
• Revocation: log out, then replay the access token. It should be dead server-side, not just absent from the client.

What the verifier has to do

The fix is a fixed algorithm allow-list passed to the verify call plus explicit claim checks — not "enforce RS256". Telling a verifier to require a named algorithm is the same shape as the bug: whatever the token header says decides how the signature is checked, so an HS256 token signed with the public key is accepted by an RS256 verifier that trusts the header.

const jwt = require('jsonwebtoken');

// The allow-list is server-side state. The token header never chooses it.
const ALLOWED = ['RS256'];

function verifyAccessToken(token) {
  const decoded = jwt.verify(token, PUBLIC_KEY, {
    algorithms: ALLOWED,          // rejects alg:none and HS256 outright
    audience: 'api.target.com',   // exact match, not substring
    issuer: 'https://auth.target.com/',
    clockTolerance: 30            // seconds; do not disable exp
  });

  if (!decoded.sub || !decoded.scope) throw new Error('missing claims');
  return decoded;
}

Test it from the outside: an alg: none token, an HS256 token signed with the public key, and a token from a different issuer should each be rejected with the same generic 401 — a verifier that distinguishes them in the error body is telling an attacker which check failed.

API Key Testing

API keys should be treated as secrets. Check how they are transmitted and if they are leaked.

Check if API key is in URL (bad practice):

GET /api/data?api_key=abc123

API key in header (better):

curl -H "X-API-Key: abc123" https://api.target.com/data
curl -H "Authorization: Api-Key abc123" https://api.target.com/data

Key leakage

Search for leaked keys in source code, mobile apps, or browser storage.

Check JavaScript source files:

grep -r "api_key|apikey|api-key|apiKey" *.js

Permission testing

Check if the key has excessive permissions.

curl -H "X-API-Key: $KEY" https://api.target.com/admin/users
curl -H "X-API-Key: $KEY" https://api.target.com/internal/config

Rate limiting bypass

Try to bypass rate limits by rotating keys or IP addresses.

for i in {1..100}; do
  curl -H "X-API-Key: $KEY" -H "X-Forwarded-For: 192.168.1.$i" https://api.target.com/data
done

OAuth 2.0 / OIDC: the API Delta

The attack mechanics of the authorization-code flow — missing state, redirect URI tricks, code injection, consent phishing — are covered in Web Pentest 06u — OAuth Attacks. On an API the interesting question is what the resource server does with the resulting token, and what the authorization server is still allowed to be sloppy about. Keep the flow order in mind, because each control below is one step of it:

The diagram is wider than this screen — swipe it sideways to read the labels.

RFC 9700 (BCP 240, January 2025) is the current security baseline for OAuth 2.0 — use it as the checklist rather than a blog post. The controls that matter at the API boundary:

Evidence Collection

False Positive Identification

Testing Checklist

Remediation & Defense