API Security: Auth, Authorization & Exploits

Why APIs Are a Prime Target

APIs have become the dominant architectural pattern for modern applications — mobile clients, single-page apps, microservices, and third-party integrations all communicate through them. This ubiquity makes them an attractive target: a single vulnerable API endpoint can expose data from millions of users, bypass authentication, or grant unauthorized administrative access. OWASP maintains a dedicated API Security Top 10 list specifically because web application vulnerabilities don't fully capture API-specific risks.

Authentication: Proving Identity at the API Layer

API Keys

API keys are the simplest authentication mechanism — a static secret shared with the client. They're appropriate for server-to-server communication where the client is a trusted backend system. Critical practices:

• Treat API keys as passwords: never log them, never include them in URLs (use Authorization header), never commit them to source control
• Issue per-client keys so you can revoke individual keys without disrupting others
• Set expiration dates and rotate keys regularly
• Scope keys to the minimum required permissions

JWT-Based Authentication

JWTs (JSON Web Tokens) encode claims that the server can verify without a database lookup, making them popular for stateless APIs. A JWT consists of a header, payload, and signature: header.payload.signature, each Base64URL-encoded.

Critical validation steps:

1. Verify the signature using the correct algorithm (reject alg:none)
2. Check iss (issuer) matches your expected authority
3. Check aud (audience) is your API
4. Check exp (expiration) — reject expired tokens
5. Check nbf (not before) if present

Never trust the alg field in the token header to determine validation logic — always pin the expected algorithm server-side.

OAuth Scopes for Authorization

For user-facing APIs, use OAuth 2.0 with fine-grained scopes: read:profile, write:orders, admin:billing. Each API endpoint should validate that the presented token contains the required scope. A valid token doesn't mean access to everything.

OWASP API Security Top 10: The Critical Risks

Broken Object Level Authorization (BOLA)

BOLA — also called IDOR (Insecure Direct Object Reference) — is consistently the #1 API security risk. It occurs when an API endpoint accepts an object ID in the request but doesn't verify the requesting user actually owns that object:

GET /api/orders/12345  →  returns order 12345
GET /api/orders/12346  →  returns another user's order (BOLA!)

Defense: for every object-access endpoint, verify that the authenticated user has a relationship to the requested object. Never rely on the object ID alone.

Broken Function Level Authorization

Administrative functions are exposed at predictable URLs but rely on client-side hiding rather than server-side enforcement:

POST /api/admin/deleteUser  →  accessible to regular users

Defense: enforce role-based access control on every endpoint, server-side. Regularly test all endpoints regardless of whether they appear in the UI for your role.

Broken Object Property Level Authorization

An API may correctly restrict which objects you can access but expose or allow modification of internal fields within those objects:

PUT /api/users/me  {"role": "admin"}  →  mass assignment vulnerability

Defense: use explicit allowlists for fields that can be read or written per endpoint. Never pass request body objects directly to ORM methods (e.g., Rails update(params[:user]) without permit).

Unrestricted Resource Consumption

Without rate limiting, a single client can exhaust your API's compute, database connections, or third-party service quota:

• Implement rate limiting per user, per IP, and per API key
• Return 429 Too Many Requests with Retry-After headers
• Limit request body size to prevent DoS via oversized payloads
• Paginate and cap results: never return unbounded collections
• Apply query depth limits for GraphQL APIs

Use tools like nginx's limit_req module, AWS API Gateway throttling, or dedicated API gateways (Kong, Envoy) for rate limiting.

Security Misconfiguration

Common API misconfigurations include:

• CORS set to Access-Control-Allow-Origin: * on authenticated endpoints
• Verbose error messages exposing stack traces, database queries, or internal paths
• HTTP methods not restricted (PUT/DELETE enabled where only GET/POST should be)
• Missing HTTPS enforcement
• Swagger/OpenAPI documentation exposed publicly in production

Sensitive Business Logic Flaws

Not all API vulnerabilities are technical — some exploit the business logic itself:

• Applying a discount coupon code multiple times
• Transferring a negative amount to add funds
• Skipping required payment steps by calling a later API endpoint directly

These require domain knowledge to find and cannot be caught by automated scanners alone. Include business logic testing in your API security reviews.

Practical API Security Hardening

• Use HTTPS everywhere and redirect HTTP to HTTPS; set Strict-Transport-Security header
• Validate all input — reject unexpected fields, validate types, ranges, and formats
• Return minimal data — don't include internal IDs, server-side timestamps, or system metadata in responses
• Log all API calls with enough context (user ID, endpoint, response code, duration) for forensic analysis
• Use an API gateway for centralized authentication, rate limiting, logging, and threat detection
• Test with OWASP ZAP or Burp Suite against your own API documentation — every endpoint in your OpenAPI spec should be tested for auth bypass and BOLA