API Security

API Security

Overview

APIs are the primary attack surface of modern applications. As architectures shift toward microservices, serverless functions, and third-party integrations, the number of exposed API endpoints grows dramatically. Every endpoint is a potential entry point for attackers. Securing APIs requires a layered approach that includes transport security, authentication, authorization, input validation, rate limiting, and proper response handling. A single misconfigured header or overly permissive CORS policy can expose an entire system.

Security Headers

Security headers instruct browsers and clients on how to handle responses, significantly reducing the attack surface for common web-based attacks.

For pure JSON APIs that are not serving HTML, a minimal set of headers should include Strict-Transport-Security, X-Content-Type-Options, Cache-Control (for sensitive responses), and X-Request-Id. The full set above is recommended when the API serves content rendered in a browser.

CORS Configuration

What CORS Is

Cross-Origin Resource Sharing (CORS) is a browser-enforced mechanism that controls which origins are permitted to make requests to your API. When a browser makes a cross-origin request, it sends an Origin header; the server must respond with appropriate Access-Control-* headers to allow or deny the request.

Dangerous Misconfigurations

• Wildcard with credentials: Setting Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true is invalid per the specification, but some implementations attempt it. This would allow any website to make authenticated requests to your API.
• Reflecting the Origin header: Dynamically returning whatever origin the request sends without validation is equivalent to a wildcard and defeats the purpose of CORS.
• Overly broad origin patterns: Matching *.example.com without anchoring can be tricked by domains like evil-example.com.

Proper Configuration Example

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-Request-Id
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

Key rules:

• Explicitly list allowed origins; never use wildcard with credentials.
• Restrict allowed methods to only those the API actually supports.
• Restrict allowed headers to those your API requires.
• Set Access-Control-Max-Age to cache preflight responses and reduce latency.

Preflight Requests

Browsers send an OPTIONS preflight request before making "non-simple" requests (those with custom headers, methods other than GET/POST, or non-standard content types). Your API must handle OPTIONS requests and return the appropriate CORS headers with a 204 No Content response. Ensure preflight handling does not require authentication.

Content Security Policy

Content Security Policy (CSP) tells the browser which sources of content are trusted, providing a strong defense against cross-site scripting (XSS) and data injection attacks.

Key Directives

Example Policies

For a JSON API (minimal CSP since no HTML rendering):

Content-Security-Policy: default-src 'none'; frame-ancestors 'none'

For a web application:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://api.example.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

Monitoring Violations

Use report-uri (deprecated but widely supported) or report-to to receive violation reports without blocking content. Start with Content-Security-Policy-Report-Only to monitor before enforcing:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Rate Limiting

Rate limiting protects APIs from abuse, brute-force attacks, and denial-of-service attempts by restricting the number of requests a client can make within a given time window.

Algorithms

Response Headers

Include rate limit information in every response so clients can self-regulate:

Tiered Limits by Authentication Level

API Authentication

Different authentication mechanisms suit different contexts. Choose based on the trust level, client type, and security requirements.

Key considerations across all methods:

• Always transmit credentials over HTTPS.
• Implement token/key rotation and revocation mechanisms.
• Log authentication events for audit and anomaly detection.
• Use short-lived tokens and refresh mechanisms where possible.

API Gateway Security

An API gateway acts as a centralized entry point for all API traffic, providing a single location to enforce security policies consistently across services.

What an API Gateway Provides

• Authentication and authorization: Validate tokens, API keys, and certificates at the edge before requests reach backend services.
• Rate limiting: Enforce per-client and per-endpoint rate limits centrally.
• Request validation: Validate request schemas (JSON Schema, OpenAPI spec) and reject malformed input before it reaches application logic.
• TLS termination: Handle HTTPS at the gateway; backend services can communicate over a trusted internal network.
• Logging and monitoring: Capture request/response metadata, latency metrics, and error rates in a centralized location.
• IP allowlisting/blocklisting: Restrict access by source IP for internal or partner APIs.
• Request/response transformation: Strip sensitive headers, mask fields, or add security headers uniformly.

Common API Gateways

Best Practices

• Enforce HTTPS everywhere — never allow plaintext HTTP for any API endpoint; use HSTS headers to prevent downgrade attacks and configure TLS 1.2 as the minimum supported version.
• Validate all input on the server side — never trust client-side validation alone; validate request bodies against schemas, enforce type and length constraints, and reject unexpected fields.
• Use the principle of least privilege for API scopes — issue tokens with the minimum scopes and permissions required for the specific operation; avoid wildcard or admin scopes for routine operations.
• Implement defense in depth — combine multiple security layers (gateway, authentication, authorization, input validation, rate limiting, monitoring) so that no single control failure results in a breach.
• Return minimal error information — never expose stack traces, internal paths, or database error messages in API responses; use generic error messages with correlation IDs for debugging.
• Log all security-relevant events — record authentication attempts, authorization failures, rate limit hits, and input validation rejections; feed logs into a SIEM for real-time alerting.
• Version your APIs and deprecate securely — maintain security patches across all supported versions; when deprecating, provide clear timelines and ensure old versions are eventually decommissioned.
• Audit third-party API integrations — review the security posture of external APIs your application depends on; validate their responses, enforce timeouts, and implement circuit breakers to prevent cascading failures.