# API Security
API (Application Programming Interface) security is the discipline of protecting APIs from abuse, unauthorized access, and exploitation. APIs are the connective tissue of modern software: they enable applications to communicate with each other, mobile apps to access backend services, SaaS platforms to integrate with third-party tools, and microservices to function as a coordinated system. Every cloud-native application, every mobile application, and every SaaS integration depends on APIs.
APIs are also one of the fastest-growing attack surfaces. Gartner predicted that APIs would become the most frequent attack vector by 2025, and the prediction has materialized. APIs are targeted because they expose application logic and data directly: unlike web applications (where users interact through a browser-rendered interface), APIs expose structured endpoints that accept programmatic requests. An attacker who understands the API schema can construct requests that access data, modify configurations, or invoke functions that the application's user interface would not permit.
The attack surface is growing because API adoption is accelerating. A mid-market SaaS company may expose hundreds of API endpoints: public APIs for customer integrations, internal APIs for microservice communication, partner APIs for third-party data exchange, and administrative APIs for platform management. Each endpoint is a potential attack vector that requires authentication, authorization, input validation, and rate limiting.
The OWASP API Security Top 10 (2023 edition) identifies the most critical API security risks:
API1: Broken Object Level Authorization (BOLA). The most common and most exploited API vulnerability. The API does not verify that the authenticated user is authorized to access the specific object they are requesting. An attacker changes the object ID in the request (from /api/users/123/records to /api/users/456/records) and accesses another user's data. BOLA is an authorization failure: the API verifies who the user is but not whether they are permitted to access the specific resource.
Defense: implement object-level authorization checks on every request that accesses a specific resource. The API must verify that the authenticated user has permission to access the requested object, not just that they are authenticated.
API2: Broken Authentication. Weak or misconfigured authentication mechanisms: missing authentication on sensitive endpoints, weak API key generation, tokens that do not expire, authentication bypass through parameter manipulation. The T-Mobile API breach (2023) exposed data for 37 million customers through an API that did not properly authenticate requests.
Defense: enforce strong authentication on every API endpoint (OAuth 2.0, API keys with proper lifecycle management, mutual TLS for service-to-service). Implement token expiration. Protect against credential stuffing with rate limiting and account lockout.
API3: Broken Object Property Level Authorization. The API exposes object properties that the user should not see or modify. A user retrieval endpoint returns the user's role, internal ID, and subscription tier alongside their profile data, leaking internal information. A user update endpoint accepts role modifications, allowing a standard user to elevate their permissions.
Defense: return only the properties the client needs (response filtering). Accept only the properties the client is permitted to modify (input validation against a schema that is role-specific).
API4: Unrestricted Resource Consumption. The API does not limit the resources a single client can consume: unlimited requests per second (enabling brute force and denial of service), unlimited response sizes (enabling data harvesting through pagination abuse), and unlimited computation (enabling algorithmic complexity attacks). Without resource limits, a single malicious client can degrade service for all users.
Defense: implement rate limiting (requests per time period), pagination limits (maximum results per request), timeout enforcement, and resource quotas per client.
API5: Broken Function Level Authorization. The API does not restrict access to administrative functions. A standard user can invoke administrative endpoints (user creation, configuration modification, data export) because the API does not verify the user's authorization level for the requested function.
Defense: enforce role-based access control at the function level. Administrative endpoints require administrative roles. Data export endpoints require export permissions. Every function checks the caller's authorization before executing.
API keys. Simple bearer tokens included in request headers. API keys identify the calling application and provide a basic level of access control. Limitations: API keys do not identify individual users (only applications), they are static credentials that are difficult to rotate without disrupting integrations, and they are frequently exposed in source code, configuration files, and client-side code.
API keys are appropriate for low-sensitivity, application-level identification. They are not appropriate as the sole authentication mechanism for APIs that access sensitive data or perform privileged operations.
OAuth 2.0. The standard authorization framework for API access. OAuth 2.0 issues scoped, time-limited access tokens that define what the bearer can access and for how long. OAuth supports multiple grant types for different use cases: authorization code (for user-facing applications), client credentials (for service-to-service), and device code (for input-constrained devices).
OAuth 2.0 is the standard for APIs that serve external clients, partner integrations, and mobile applications. It provides granular scoping (the token permits specific operations on specific resources), time limitation (tokens expire), and revocability (tokens can be revoked independently of the client's credentials).
Mutual TLS (mTLS). Both the client and the server present certificates during the TLS handshake, providing bidirectional authentication. mTLS is the strongest API authentication mechanism for service-to-service communication because it binds the identity to a cryptographic certificate rather than a shared secret.
mTLS is standard for zero trust service mesh architectures (Istio, Linkerd, Consul Connect) where every service-to-service call is authenticated and encrypted. It is less practical for external APIs (requiring clients to manage certificates creates adoption friction).
JWT (JSON Web Tokens). Self-contained tokens that include claims (user identity, permissions, expiration) signed by the issuer. JWTs enable stateless authentication: the API validates the token's signature and claims without querying a central session store. JWTs are commonly used as the token format within OAuth 2.0 flows.
JWT security requires proper implementation: validate the signature algorithm (do not accept "alg: none"), verify the issuer and audience claims, enforce expiration, and do not store sensitive data in the payload (JWTs are encoded, not encrypted, by default).
API gateways (Kong, Apigee, AWS API Gateway, Azure API Management) provide a centralized enforcement point for API security controls:
Authentication enforcement. The gateway verifies authentication for every request before routing it to the backend API. Backend APIs trust requests from the gateway, simplifying backend security logic.
Rate limiting. The gateway enforces request rate limits per client, per endpoint, and per time window. Rate limiting prevents brute force, denial of service, and data harvesting.
Input validation. The gateway validates request parameters against the API schema (OpenAPI/Swagger specification), rejecting requests that do not conform to the expected format before they reach the backend.
Logging and monitoring. The gateway logs every API request with metadata (client identity, endpoint, parameters, response code, latency), providing the telemetry needed for security monitoring and forensic investigation.
WAF integration. API gateways integrate with Web Application Firewalls to inspect request payloads for injection attacks, cross-site scripting, and other application-layer threats.
Organizations cannot secure APIs they do not know about. Shadow APIs (undocumented endpoints deployed by development teams, deprecated endpoints that were not decommissioned, test endpoints exposed in production) are common and high-risk because they do not receive the security controls applied to documented APIs.
API discovery tools and practices identify all APIs in the environment: scanning network traffic for API patterns, analyzing application code for endpoint definitions, reviewing API gateway logs for undocumented endpoints, and using API security platforms (Salt Security, Noname Security, Traceable AI) that passively discover APIs from traffic analysis.
API inventory is the API equivalent of asset inventory (SPH) and attack surface management (VSD). You cannot secure what you have not inventoried.
Modern applications are API-first: the user interface (web, mobile, desktop) is a client that consumes APIs. The business logic lives in the API layer. The data is accessed through the API layer. Securing the user interface without securing the API is securing the lobby while leaving the vault unlocked: the attacker bypasses the interface and interacts with the API directly.
API vulnerabilities expose data at scale. A BOLA vulnerability in a user data API enables the attacker to enumerate every user record by incrementing the object ID. A broken pagination API enables the attacker to download the entire database through repeated paginated requests. A misconfigured data export API enables the attacker to extract data that the user interface would never display. API breaches routinely expose millions of records because APIs provide programmatic, high-speed access to data stores.
APIs that process personal data, financial data, or health data are subject to the same regulatory requirements as any other data processing system. GDPR, HIPAA, PCI DSS, and state privacy laws apply to data accessed through APIs. API security failures that expose regulated data trigger the same breach notification and regulatory reporting requirements as any other breach.
API security sits in the VSD (Vulnerability and Surface Defense) domain of the Planetary Defense Model. VSD is the ocean layer: the attack surface where adversaries probe and breach. APIs are a major and growing component of that surface. CSR (Continuous Surface Reduction) applies: every unnecessary API endpoint, every over-permissive scope, and every unauthenticated endpoint is an exposed surface that CSR identifies and eliminates.
The interaction with IAT is direct: API authentication and authorization are IAT functions implemented at the API layer. OAuth 2.0 token scoping, RBAC enforcement on API functions, and mTLS for service identity are IAT controls applied to VSD attack surface. ZPA applies: "Trust nothing. Possess nothing. Verify everything." Every API request is authenticated, authorized, and scoped to minimum required access.
VSD-B04 (Web Application Security, 32 estimated hours) includes API security as a core component: API discovery and inventory, authentication review (OAuth configuration, API key management, mTLS deployment), authorization testing (BOLA, broken function-level authorization), rate limiting configuration, input validation, and API gateway security hardening.
CDA approaches API security with one emphasis: API discovery and inventory is the prerequisite. An organization that secures its documented APIs while shadow APIs operate without authentication or rate limiting has a false sense of coverage. CDA's VSD-R03 (Application Security Assessment) includes API discovery as a standard component, identifying every API endpoint in the environment before evaluating their security posture.
Word count: 1,948