API Security Assessment: Beyond REST Status Codes

The API Attack Surface

APIs now handle more sensitive operations than the web pages in front of them. A banking application's website might display your account balance, but its API is what processes transfers, updates personal details, and manages authentication tokens. Every mobile app, every single-page application, every microservice architecture relies on APIs as the backbone of data flow. When those APIs are misconfigured, the consequences are direct and severe.

The 2023 OWASP API Security Top 10 reflects this reality. Broken authentication, broken object-level authorization, unrestricted resource consumption, and server-side request forgery all target API-specific patterns that traditional web vulnerability scanners were never designed to find. A scanner that checks HTTP status codes and response headers will miss most of these issues entirely, because the vulnerabilities live in the application logic behind those responses. Even thorough passive analysis can only detect the surface-level indicators of deeper API flaws.

Authentication Weaknesses

API authentication failures are the most consequential vulnerability class because they gate access to everything else. If authentication is broken, every endpoint behind it is exposed regardless of how well it is individually secured.

JWT algorithm confusion is a textbook example. JSON Web Tokens can be signed with symmetric algorithms (like HS256, using a shared secret) or asymmetric algorithms (like RS256, using a public/private key pair). The alg field in the JWT header tells the server which algorithm to use for verification. If the server trusts this field without restriction, an attacker can change the algorithm:

{
  "alg": "none",
  "typ": "JWT"
}

The alg: none attack tells the server that the token requires no signature verification at all. A surprising number of JWT libraries accept this by default. The attacker strips the signature from the token, changes the payload to claim any identity they want, and the server accepts it because the header says no verification is needed.

The HS256/RS256 confusion attack is subtler. If the server expects RS256 (asymmetric) tokens, the attacker crafts a token signed with HS256 (symmetric) using the server's public key as the HMAC secret. Since the public key is, by definition, public, the attacker has everything they need:

# Fetch the public key
curl -s https://api.example.com/.well-known/jwks.json | jq -r '.keys[0]'

# Craft a token signed with HS256 using the public key as the secret
# The server may verify the HS256 signature using its RSA public key
python3 -c "
import jwt
token = jwt.encode(
    {'sub': 'admin', 'role': 'superuser'},
    open('public_key.pem').read(),
    algorithm='HS256'
)
print(token)
"

Detecting this vulnerability requires examining the API's JWT validation behavior -- something a status code scanner cannot do.

Rate Limiting Gaps

Rate limiting is the API equivalent of a deadbolt on a door. Without it, an attacker can make unlimited requests, enabling credential stuffing, data scraping, enumeration of valid usernames or account numbers, and denial-of-service attacks.

Effective rate limiting assessment goes beyond checking whether a 429 Too Many Requests response eventually appears. The questions that matter are more nuanced:

Per-endpoint granularity. Does the API apply rate limits per endpoint, or globally? A global limit of 1000 requests per minute is meaningless if the login endpoint processes 999 authentication attempts before the limit kicks in.

Key-based vs. IP-based. IP-based rate limiting is trivially bypassed by rotating through proxy addresses. API key or session-based limiting is harder to circumvent but is often only applied to authenticated endpoints, leaving login and registration flows unprotected.

Response header consistency. Well-implemented rate limiting advertises its state through response headers:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1709571200
Retry-After: 60

The absence of these headers does not confirm the absence of rate limiting -- the API might enforce limits silently. But their presence allows assessment of whether the limits are reasonable for the endpoint's sensitivity. A login endpoint allowing 100 attempts per minute is effectively unprotected against automated credential stuffing.

Endpoint Enumeration

APIs frequently expose more endpoints than their developers intend. Documentation files, debug routes, administrative interfaces, and deprecated versions often remain accessible in production because no one remembers to remove them.

OpenAPI/Swagger exposure is the most common form. APIs built with frameworks like FastAPI, Express, or Spring Boot often auto-generate OpenAPI specification files and serve interactive documentation at predictable paths:

/swagger.json
/openapi.json
/api-docs
/swagger-ui/
/docs
/redoc

These specification files enumerate every endpoint, every parameter, every request/response schema, and every authentication requirement. They are a complete map of the API surface, freely available to anyone who requests them.

Version endpoint exposure compounds the problem. When an API evolves from v1 to v2, the v1 endpoints often remain active. The older version frequently has weaker authentication, less input validation, and known vulnerabilities that were fixed in v2 but never backported:

/api/v1/users     # Legacy, no rate limiting, returns full user objects
/api/v2/users     # Current, rate-limited, returns sanitized responses

An attacker who discovers v1 endpoints can bypass every security improvement made in v2 simply by changing a version prefix in the URL.

Broken Object-Level Authorization

BOLA (Broken Object-Level Authorization) -- ranked #1 in the OWASP API Security Top 10 -- occurs when an API does not verify that the authenticated user has permission to access the specific resource they are requesting. The API confirms that you are logged in but does not check that the resource belongs to you:

# Authenticated as user 42, requesting user 42's data -- allowed
curl -H "Authorization: Bearer $TOKEN" https://api.example.com/users/42/invoices

# Same token, requesting user 43's data -- should be denied, often is not
curl -H "Authorization: Bearer $TOKEN" https://api.example.com/users/43/invoices

This vulnerability is endemic in APIs because authorization checks must be implemented per-endpoint, per-resource-type, and per-operation. Missing a single check on a single endpoint creates a data exposure path. Unlike authentication flaws, BOLA does not require any special technique to exploit -- just changing an ID in the URL.

How CyberShield Approaches API Assessment

CyberShield's API assessment examines the observable security properties of API endpoints without attempting exploitation. The assessment checks for exposed documentation files, JWT configuration weaknesses (including algorithm support and token validation behavior), rate limiting implementation across sensitive endpoints, and common authorization patterns.

Findings include specific evidence: the exposed specification URL, the exact headers indicating rate limit configuration, the JWT algorithms the server accepts. This specificity lets your team verify each finding using the API security testing checklist and prioritize remediation based on which gaps create the most realistic attack paths.

API security cannot be reduced to checking status codes and response times. The vulnerabilities that matter live in authentication logic, authorization boundaries, and rate limiting implementation -- all of which require purpose-built assessment that understands how APIs are designed and how they fail. Pair this with strong HTTP security headers to defend the transport layer while you address application logic.

Start a scan to assess your API surface before an attacker maps it for you.