API Security

Key Control Areas

• API Authentication and Identity Management (IA-02, IA-04, IA-05, IA-08, IA-09): Every API call must be authenticated. IA-02 mandates identification and authentication for organisational users accessing APIs, requiring OAuth 2.0 bearer tokens, API keys with HMAC signing, or mutual TLS certificates rather than basic authentication over plain HTTP. IA-04 manages the lifecycle of API credentials: provisioning, rotation, suspension, and revocation of API keys and client IDs. IA-05 governs authenticator management -- token signing key rotation, API key entropy requirements, and credential storage using secrets managers rather than embedded in source code or configuration files. IA-08 extends authentication to non-organisational users: third-party developers, partner integrations, and public API consumers who authenticate via OAuth client credentials, API keys, or federated identity. IA-09 addresses service-to-service authentication -- the critical requirement that internal APIs between microservices use mutual TLS, service mesh identity (SPIFFE/SPIRE), or signed JWTs rather than relying on network-level trust. Implementation requires centralised API key management, short-lived token issuance (15-minute access tokens with refresh rotation), and automated credential rotation with zero-downtime deployment.
• API Authorization and Access Control (AC-03, AC-04, AC-06, AC-07, AC-10, AC-12): Authorization in API security must operate at multiple granularities: endpoint level, resource level, field level, and operation level. AC-03 enforces access based on OAuth 2.0 scopes, RBAC roles, or ABAC policies -- critically, authorization must check not just whether the authenticated identity can access the endpoint, but whether it can access the specific resource instance (preventing Broken Object Level Authorization, OWASP API #1). AC-04 controls information flow between API boundaries, preventing APIs from leaking data across trust domains or returning more data than the consumer is authorised to see. AC-06 enforces least privilege: API tokens should carry the minimum scopes required for the specific operation, not blanket admin access. AC-07 limits unsuccessful authentication attempts with progressive rate limiting and account lockout to prevent credential stuffing against API authentication endpoints. AC-10 controls concurrent API sessions to prevent token farming and session multiplication attacks. AC-12 enforces token expiration and session termination -- access tokens must have short lifetimes, refresh tokens must be rotation-bound, and revocation must propagate to all enforcement points within seconds.
• API Gateway and Boundary Protection (SC-07, AC-17, AC-20, AC-21): The API gateway is the primary security enforcement point for all API traffic. SC-07 enforces boundary protection: the gateway terminates TLS, validates authentication tokens, applies rate limits, checks schema compliance, and routes only validated requests to backend services. No API consumer should ever communicate directly with backend services -- all traffic flows through the gateway. AC-17 governs remote access to APIs, ensuring that API endpoints exposed to the internet have defence-in-depth controls: WAF integration, DDoS protection, geographic restrictions where appropriate, and IP reputation filtering. AC-20 controls the use of external APIs that the organisation consumes -- third-party API dependencies must be inventoried, risk-assessed, and monitored for availability, security incidents, and breaking changes. AC-21 enables controlled information sharing via APIs while enforcing data classification policies: public endpoints return only public data, partner endpoints enforce contractual data boundaries, and internal endpoints may return richer data but only to authenticated internal services.
• Input Validation and Injection Prevention (SI-10, SI-03, SI-11, SI-15): Input validation is the most critical technical control in API security. SI-10 mandates validation of all API input: request parameters, headers, path segments, query strings, and request bodies must be validated against the API schema (OpenAPI, GraphQL schema, protobuf definition) before reaching business logic. This prevents SQL injection, NoSQL injection, command injection, XML external entity attacks, and server-side request forgery. Validation must be allowlist-based (accept known-good) rather than denylist-based (reject known-bad). SI-03 provides malicious code protection at the API layer: scanning uploaded files, detecting encoded payloads, and preventing polyglot attacks that bypass content-type restrictions. SI-11 controls error handling to prevent information leakage -- API error responses must return standardised error codes and messages without exposing stack traces, database schemas, internal paths, or implementation details that aid reconnaissance. SI-15 filters information output to prevent excessive data exposure (OWASP API #3): APIs must return only the fields required by the consumer, implement field-level filtering, and never expose internal identifiers, timestamps, or metadata that the consumer does not need.
• Transport Security and Cryptography (SC-08, SC-13, SC-23, SC-28): All API communication must be encrypted in transit and sensitive data encrypted at rest. SC-08 mandates TLS 1.2+ for all API traffic with no fallback to unencrypted HTTP -- this includes internal service-to-service communication, not just external-facing APIs. For service mesh architectures, mutual TLS (mTLS) provides both encryption and service identity verification. SC-13 specifies cryptographic protection for API tokens: JWTs must use asymmetric signing (RS256/ES256, not HS256 with shared secrets), API keys must be generated with sufficient entropy (256-bit minimum), and payload encryption (JWE) should be used for sensitive data in transit. SC-23 ensures session authenticity: API tokens must be bound to the client, protected against replay with short expiration and nonce values, and validated on every request including signature verification, expiration checking, and audience validation. SC-28 protects API data at rest: API logs containing request/response bodies must be encrypted, API key hashes stored rather than plaintext keys, and any API cache or queue containing sensitive data must be encrypted.
• API Inventory and Lifecycle Management (CM-02, CM-03, CM-07, CM-08): You cannot secure what you cannot see. CM-08 maintains a real-time inventory of all APIs: every endpoint, version, owner, consumer, authentication method, data classification, and deployment status. Shadow APIs and zombie APIs (deprecated but still accessible) are among the most dangerous attack surfaces. CM-02 establishes baseline configurations for API deployments: standard gateway policies, required security headers (CORS, CSP, HSTS), mandatory TLS versions, and default rate limits. CM-03 controls API changes: schema changes must be versioned, backward-compatible, and deployed through CI/CD with automated contract testing. Breaking changes require consumer notification and migration periods. CM-07 enforces least functionality: disable unused HTTP methods, remove debug endpoints before production deployment, disable GraphQL introspection in production, and decommission deprecated API versions on a published timeline rather than leaving them accessible indefinitely.
• API Monitoring and Anomaly Detection (AU-02, AU-03, AU-06, AU-12, CA-07, SI-04): API monitoring must capture both security events and business logic abuse. AU-02 defines auditable API events: all authentication attempts (success and failure), authorisation decisions, rate limit triggers, schema validation failures, and sensitive data access. AU-03 specifies audit record content: timestamp, source IP, authenticated identity, API endpoint, HTTP method, response code, response time, request size, and correlation ID for distributed tracing. AU-06 analyses API audit records to detect patterns: credential stuffing attacks (many failed auths from one IP), broken object level authorization attempts (sequential ID enumeration), data scraping (paginated bulk extraction), and business logic abuse (unusual transaction patterns). AU-12 generates audit records at the API gateway and within backend services, providing end-to-end request tracing. CA-07 provides continuous monitoring of API health, security posture, and compliance. SI-04 monitors API traffic in real-time for anomalies: unusual request volumes, geographic access pattern changes, new user agents, and response size anomalies that may indicate data exfiltration.
• API Security Testing and Assessment (CA-02, RA-03, RA-05, SA-08, SA-11): API security must be validated continuously through the development lifecycle. CA-02 provides security assessments of API implementations: penetration testing focused on OWASP API Top 10, fuzzing of all input parameters, and authentication/authorisation bypass testing. RA-03 requires API threat modelling during design: identifying trust boundaries, data flows, authentication points, and potential abuse scenarios before writing code. RA-05 mandates vulnerability scanning: automated DAST tools that test deployed APIs for injection, authentication bypass, and excessive data exposure, integrated into CI/CD pipelines. SA-08 applies security engineering principles to API design: schema-first development with security constraints defined in the API specification, fail-closed authorisation defaults, and defence-in-depth with validation at both gateway and service layers. SA-11 requires developer security testing: unit tests for authorisation logic, contract tests validating schema compliance, and integration tests that verify security controls function correctly across the API stack.

When to Use

This pattern applies to any organisation that exposes or consumes APIs. It is essential for organisations with public-facing APIs accessed by third-party developers, mobile applications that communicate via REST or GraphQL APIs, microservice architectures with significant service-to-service API traffic, open banking or PSD2 compliance requirements, partner integration programmes with API-based data exchange, IoT device fleets communicating via API endpoints, or any architecture where APIs are the primary interface for data access and business logic execution.

When NOT to Use

This pattern adds unnecessary overhead for purely internal monolithic applications that do not expose APIs. Organisations with exclusively file-based integrations (SFTP, batch processing) may find limited applicability until they modernise to API-based integration. Very early-stage prototypes may defer comprehensive API security controls, though basic authentication and input validation should never be skipped even in prototypes.

Typical Challenges

Legacy APIs that pre-date current security standards resist retrofitting -- they may use basic authentication, lack input validation, or return excessive data in responses. Shadow APIs created by development teams outside governance processes create unknown attack surface. GraphQL APIs with deeply nested queries enable denial-of-service without proper query depth and complexity limits. Versioning strategy disputes slow progress: URL versioning vs header versioning vs content negotiation each have trade-offs. Rate limiting at the right granularity is difficult: too coarse blocks legitimate high-volume consumers, too fine creates operational overhead. API key sprawl across multiple consumers makes rotation and revocation operationally painful without centralised key management. Microservice architectures generate enormous east-west API traffic that is expensive to monitor comprehensively. Documentation drift between API specifications and implementations creates false confidence in security testing. Partner API integrations involve contractual and technical constraints that limit security control options. API deprecation faces resistance when consumers depend on legacy endpoints and migration timelines slip indefinitely.

Threat Resistance

API Security addresses the OWASP API Security Top 10 and beyond. Broken Object Level Authorization (BOLA/IDOR) is mitigated by resource-level authorization checks at the service layer, not just endpoint-level (AC-03, AC-06). Broken authentication including credential stuffing and API key theft is addressed by strong authenticator management, short-lived tokens, and progressive rate limiting (IA-02, IA-05, AC-07). Excessive data exposure is prevented by field-level output filtering and response schema validation (SI-15, AC-04). Rate limiting bypass and API abuse are controlled by multi-layer throttling at gateway and service levels (AC-07, AC-10, SC-07). Injection attacks through API parameters are blocked by schema-based input validation and allowlist filtering (SI-10, SI-03). Server-side request forgery via API input is prevented by input validation and URL allowlisting (SI-10, SC-07). Mass assignment and parameter tampering are addressed by strict schema validation that rejects unexpected fields (SI-10, AC-03). API supply chain compromise through malicious third-party APIs is mitigated by vendor assessment, monitoring, and circuit-breaker patterns (AC-20, SR-02, SR-03). Man-in-the-middle on API traffic is eliminated by mandatory TLS and certificate pinning for sensitive integrations (SC-08, SC-13). Shadow API exposure is addressed by continuous API inventory and discovery scanning (CM-08, CM-07, RA-05). Token theft and replay attacks are mitigated by short-lived tokens, audience binding, and continuous session validation (SC-23, AC-12, IA-05). API denial of service through resource exhaustion is controlled by rate limiting, query complexity limits, and payload size restrictions (AC-07, SC-07, SI-10).

Assumptions

The organisation develops or consumes APIs as part of its technology stack. An API gateway or reverse proxy capability exists or can be deployed. Development teams follow a schema-first or design-first API development approach (OpenAPI, GraphQL SDL, protobuf). OAuth 2.0 or equivalent token-based authentication infrastructure is available. API consumers can be identified and authenticated (even public APIs should require API keys for rate limiting and abuse tracking). A CI/CD pipeline exists for automated testing and deployment. Logging and monitoring infrastructure can ingest and analyse API traffic at the expected volume.

Developing Areas

• GraphQL-specific security tooling is significantly less mature than REST API security tooling. While REST APIs benefit from decades of WAF rules, API gateway policies, and DAST scanners, GraphQL's flexible query language creates novel attack vectors (deeply nested queries, alias-based batching, field suggestion enumeration) that most generic API security tools do not handle. Purpose-built GraphQL security solutions like GraphQL Armor and Stellate are emerging, but enterprise-grade GraphQL security -- including field-level authorization, cost-based rate limiting, and query complexity analysis -- still requires substantial custom implementation.
• API abuse detection for business logic attacks is an emerging discipline that sits at the intersection of API security and fraud detection. Traditional API security tools focus on technical attacks (injection, authentication bypass), but the most damaging API attacks increasingly exploit business logic -- inventory manipulation, coupon stacking, price scraping, and competitive intelligence harvesting -- that appear as legitimate API usage at the technical level. Detecting these attacks requires understanding business context and establishing behavioural baselines that current API gateway and WAF products are only beginning to support.
• Machine-to-machine API authentication at scale is creating credential management challenges that outpace current tooling. As microservice architectures grow to hundreds or thousands of services, each requiring unique credentials for inter-service communication, the volume of API keys, certificates, and tokens becomes operationally unmanageable with manual processes. Service mesh identity (SPIFFE/SPIRE) and workload identity federation are emerging solutions, but adoption requires significant infrastructure investment and most organisations still manage M2M credentials through a mix of secrets managers and manual processes with inconsistent rotation.
• API sprawl discovery -- finding undocumented, shadow, and zombie APIs across the enterprise -- is a rapidly developing market driven by the recognition that organisations typically have 3-5x more APIs than they are aware of. API discovery tools that analyse network traffic, code repositories, and cloud configurations to build comprehensive API inventories are emerging from vendors like Noname Security, Salt Security, and Traceable, but the accuracy of automated discovery varies significantly and maintaining a continuously updated API inventory remains operationally challenging.
• Runtime API protection that operates independently of the API gateway is an emerging architectural pattern addressing the limitation that gateway-only security cannot detect or prevent business logic attacks, BOLA, or data exposure that depends on application-level context. Inline and sidecar-based runtime protection solutions inspect API traffic with awareness of the application's data model and authorization logic, but they add latency and complexity that creates tension with the performance requirements of high-throughput API architectures.