API Security: Risks, Standards, and Protective Controls

Application Programming Interface (API) security encompasses the technical controls, governance standards, and risk frameworks applied to protect APIs from unauthorized access, data exposure, and abuse. This page describes the API threat landscape, the control mechanisms used to defend API endpoints, the regulatory frameworks that apply to API-exposed data, and the classification boundaries that distinguish API security from adjacent disciplines such as application security and network security. The sector is structured around standards maintained by OWASP, NIST, and federal regulatory bodies including CISA and the FTC.

Definition and scope

APIs function as the connective tissue of modern software architecture, enabling machine-to-machine communication between internal services, third-party platforms, and external consumers. An API security failure is not an abstract risk: the OWASP API Security Top 10 — first published in 2019 and updated in 2023 — documents that broken object-level authorization (BOLA), authentication failures, and unrestricted resource consumption represent the dominant attack vectors across REST, SOAP, and GraphQL interfaces.

The scope of API security spans three layers:

1. Authentication and authorization controls — mechanisms that verify identity (OAuth 2.0, OpenID Connect, API keys) and enforce least-privilege access to resources
2. Transport and data exposure controls — TLS enforcement, payload encryption, and schema validation that limit what data travels across an API boundary
3. Rate limiting and abuse prevention — quotas, throttling policies, and anomaly detection that prevent denial-of-service conditions and credential stuffing

The NIST Special Publication 800-204, Security Strategies for Microservices-based Application Systems, formally classifies API security as a subdomain of application security with distinct control requirements tied to service mesh architecture, inter-service communication, and API gateway configuration. This distinguishes it from traditional perimeter-based controls.

Regulatory scope applies wherever APIs expose regulated data. Under HIPAA (45 CFR §164.312), covered entities must implement access controls and audit controls on any interface — including APIs — that transmits electronic Protected Health Information (ePHI). The FTC Act Section 5 has been applied to inadequate API security as an unfair or deceptive practice, as documented in enforcement actions published on ftc.gov.

How it works

API security operates through a layered control model applied at the gateway, service, and data layers. The following phases describe the standard enforcement architecture:

1. Identity verification — The API gateway or identity provider validates credentials using OAuth 2.0 bearer tokens or mutual TLS (mTLS) certificates before any request reaches a backend service. NIST SP 800-63B defines authenticator assurance levels (AAL1 through AAL3) applicable to API authentication systems (NIST SP 800-63B).

2. Authorization enforcement — Object-level and function-level authorization checks confirm that the authenticated caller has permission to access the specific resource being requested. BOLA attacks — ranked first in the OWASP API Security Top 10 (2023) — exploit gaps at this layer, not at authentication.

3. Input validation and schema enforcement — Requests are validated against a defined schema (OpenAPI Specification, JSON Schema) to reject malformed payloads before they reach application logic. This control directly counters injection attacks catalogued under CWE-89 (SQL Injection) and CWE-78 (OS Command Injection) in the MITRE Common Weakness Enumeration database.

4. Rate limiting and quota enforcement — Policies applied at the gateway layer restrict request volume per client, per endpoint, and per time window, mitigating the OWASP API4:2023 "Unrestricted Resource Consumption" risk category.

5. Logging, monitoring, and anomaly detection — API traffic logs feed into SIEM platforms where behavioral baselines are established. CISA's Secure by Design principles require that security-relevant events be logged with sufficient fidelity to support incident reconstruction.

6. Secrets management — API keys, tokens, and certificates are rotated on defined schedules and stored in dedicated secrets vaults rather than embedded in code. The National Vulnerability Database documents recurring exposures through hardcoded credential patterns (CWE-798).

REST APIs and GraphQL APIs present distinct risk profiles: REST exposes discrete endpoints that can be individually rate-limited and monitored, while GraphQL exposes a single endpoint where query complexity and introspection abuse require purpose-built controls not addressed by traditional WAF rule sets.

Common scenarios

API security failures manifest across four recurring operational scenarios that account for the majority of API-related breaches documented in public enforcement and disclosure records.

Broken object-level authorization in financial services — An API endpoint returning account data fails to verify that the authenticated user's token corresponds to the account ID in the request parameter. An attacker iterates account IDs to access records belonging to other users. This pattern was central to enforcement actions reviewed by the Consumer Financial Protection Bureau (CFPB) under Dodd-Frank Act authority over unfair, deceptive, or abusive practices.

Excessive data exposure in healthcare APIs — An API returns a full patient record object when the consuming application only requires a name and appointment date. ePHI fields travel unnecessarily across the API boundary, expanding the HIPAA minimum-necessary violation surface defined at 45 CFR §164.514(d). The HHS Office for Civil Rights has cited API configuration in breach investigations.

Unauthenticated API endpoints in cloud-native environments — Misconfigured microservice deployments expose internal APIs to external networks without authentication, a pattern addressed directly in the CISA Cloud Security Technical Reference Architecture. Infrastructure-as-code pipeline errors are a primary cause of this exposure.

Third-party API key compromise — Developers embed API credentials in public repositories. GitHub's 2023 secret scanning program detected over 1 million exposed secrets across public repositories (GitHub Secret Scanning documentation), with API keys representing one of the largest exposure categories.

For professionals navigating the broader security service landscape, the Information Security Providers provider network catalogs practitioners and firms organized by security discipline, including application and API security specializations.

Decision boundaries

API security is a distinct discipline from adjacent categories, and misclassifying a problem leads to applying the wrong control set. Three boundaries define where API security begins and ends relative to neighboring domains.

API security vs. application security — Application security addresses the full software development lifecycle, including source code review, dependency management, and secure SDLC processes. API security is a subset focused specifically on the interface layer — the published endpoint surface, authentication flow, and data transmission controls. An organization can pass a static application security test (SAST) scan and still expose a BOLA vulnerability at the API layer.

API security vs. network security — Network security controls (firewalls, IDS/IPS, network segmentation) operate at OSI Layers 3 and 4. The majority of API attacks, including authorization bypass and injection, operate at Layer 7 (application layer). Network controls do not inspect or enforce API-specific semantics such as object-level authorization or JWT claim validation. A Web Application Firewall (WAF) operates at Layer 7 but requires API-aware rule sets to address GraphQL or REST-specific attack patterns.

API security vs. identity and access management (IAM) — IAM governs the enterprise identity lifecycle: provisioning, deprovisioning, role assignment, and federation. API security consumes IAM outputs (tokens, certificates) but enforces access at the endpoint level. An IAM system may correctly issue a valid OAuth token to a legitimate user while an API still fails to enforce object-level authorization — the token is valid, but the authorization logic is absent. This distinction is formalized in NIST SP 800-204A, which addresses authorization architecture for microservices separately from identity federation.

Organizations operating under PCI DSS v4.0 (published by the PCI Security Standards Council) face specific API security obligations under Requirements 6.2 and 6.3, which mandate bespoke software security and the protection of public-facing APIs against known attack techniques — distinguishing those obligations from the network segmentation controls under Requirement 1.

The page defines how security disciplines are classified within this reference structure. Practitioners seeking to locate API security service providers by specialization can consult the Information Security Providers provider network, which organizes the service sector by technical domain.