API Security: Risks, Standards, and Protective Controls

Application programming interfaces have become the dominant attack surface in enterprise software environments, with the OWASP API Security Top 10 project identifying API vulnerabilities as a distinct threat category requiring its own classification framework separate from general web application risks. This page covers the definition and scope of API security as a discipline, the mechanisms through which API threats operate, the scenarios in which API vulnerabilities are most commonly exploited, and the decision boundaries that distinguish API-specific controls from adjacent security domains such as application security and identity and access management.

Definition and scope

API security encompasses the policies, authentication mechanisms, authorization controls, traffic validation rules, and monitoring processes applied to protect application programming interfaces from unauthorized access, data extraction, manipulation, and denial of service. APIs serve as the integration layer connecting web applications, mobile clients, microservices, cloud platforms, and third-party data providers — making them a transit point for sensitive data flows across organizational perimeters.

The scope of API security spans three primary interface types:

The OWASP API Security Top 10 (2023 edition) defines the authoritative public classification of API-specific risks, distinguishing them from the OWASP Web Application Top 10 on the basis of interface exposure, object-level authorization failures, and function-level access control breakdowns unique to API architectures.

Regulatory frameworks that directly implicate API security controls include the NIST Cybersecurity Framework (CSF) 2.0 under its Protect and Detect functions, PCI DSS v4.0 for payment data APIs, and the HHS Office for Civil Rights guidance under HIPAA (45 CFR §164.312) for APIs that transmit protected health information.

How it works

API security operates through a layered control architecture applied at the gateway, transport, and application logic levels. The primary mechanism involves intercepting and validating API requests before they reach backend services.

A functional API security control framework follows this sequence:

  1. Authentication — Verifying the identity of the API caller using mechanisms such as OAuth 2.0 (RFC 6749), API keys, or mutual TLS (mTLS). OAuth 2.0 with OpenID Connect (OIDC) is the standard specified by the OpenID Foundation for delegated authorization in API contexts.
  2. Authorization — Enforcing object-level authorization (OLA) and function-level authorization (FLA), the two control categories most frequently absent in vulnerable APIs per OWASP API1:2023 and API5:2023.
  3. Input validation — Inspecting request payloads, query parameters, and headers against defined schemas to reject malformed or injected content before processing.
  4. Rate limiting and throttling — Restricting request volume per caller to prevent resource exhaustion attacks classified under OWASP API4:2023 (Unrestricted Resource Consumption).
  5. Traffic inspection and logging — Routing API traffic through a gateway or service mesh that records metadata for anomaly detection, feeding into SIEM and log management pipelines.
  6. Encryption in transit — Enforcing TLS 1.2 or TLS 1.3 for all API communication, a baseline requirement under NIST SP 800-52 Rev. 2.

The distinction between API gateway controls and API management platform controls is significant: gateways enforce security policies at the network boundary, while management platforms govern the full API lifecycle including versioning, documentation, and developer access provisioning. Both operate as complementary layers in a zero-trust architecture model.

Common scenarios

API security failures cluster around three operational scenarios that account for the preponderance of disclosed API-related breaches:

Broken object-level authorization (BOLA) — An authenticated user manipulates an object identifier in an API request (e.g., substituting a different account ID in a REST endpoint) to retrieve records belonging to another user. BOLA, listed as OWASP API1:2023, is the most frequently exploited API vulnerability category because authorization logic is often implemented per-function rather than per-object.

Exposed administrative APIs in cloud environments — Cloud-native applications frequently expose management APIs that are not subject to the same authentication requirements as public-facing endpoints. This scenario intersects directly with cloud security controls and is addressed in the NIST SP 800-204 series on security strategies for microservices.

Third-party API integrations with excessive permissions — Organizations that consume external APIs (payment processors, identity providers, data enrichment services) often grant API credentials with broader scopes than individual operations require. This overpermissioning scenario is a third-party risk management concern as much as an API-specific one, particularly when credential rotation policies are absent.

Shadow APIs — Undocumented or deprecated API endpoints that remain active but are excluded from access control reviews. Shadow APIs are identified through vulnerability management scanning and API discovery tooling, and their prevalence increases in organizations that lack formal devsecops pipeline integration.

Decision boundaries

API security as a discrete discipline diverges from adjacent domains along several classification boundaries:

API security vs. application security — Application security covers the full software development lifecycle including code review, static analysis, and web application firewall policies. API security is a subset focused specifically on interface exposure, authentication protocols, and runtime authorization enforcement. An organization may have mature application security practices while still lacking API-specific schema validation or rate-limiting controls.

API security vs. identity and access management — IAM governs identity lifecycle, credential issuance, and access provisioning across enterprise systems. API security consumes IAM outputs (tokens, credentials, roles) and enforces them at the interface layer. The boundary sits at token validation: IAM issues and manages tokens; API security enforces their scope at runtime.

API security vs. network security — Network security fundamentals address perimeter controls, firewall rules, and traffic segmentation. API security operates at Layer 7 (application layer) and requires inspection of HTTP methods, payload schemas, and semantic request logic that packet-level controls cannot assess.

Compensating controls for legacy SOAP environments vs. modern REST/GraphQL — SOAP API security relies heavily on WS-Security standards (published by OASIS) for message-level encryption and signature validation. REST and GraphQL environments depend on transport-level TLS combined with token-based authorization. Organizations maintaining both interface types require parallel control sets with distinct tooling.

The NIST SP 800-204A publication, "Building Secure Microservices-based Applications Using Service-Mesh Architecture," provides the federal reference framework for API security controls in distributed service environments and is the primary NIST guidance applicable to organizations operating container-based API deployments alongside container and Kubernetes security programs.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator