API Security

Key Control Areas

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.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.