APIs: The New Attack Surface

APIs (Application Programming Interfaces) have become the most targeted layer in modern software: 150 billion of 311 billion total web attacks in 2024 targeted APIs, according to Akamai’s 2024 State of the Internet report. APIs provide direct programmatic access to application logic and sensitive data, and they proliferate faster than security controls around them. The recommended action: treat every API as a privileged access point, enforce TLS 1.3 and mutual TLS for all traffic, implement object-level authorization at every endpoint, and monitor API behavior continuously for anomalies that signatures alone cannot catch.

Quick Answer: Why Are APIs the New Attack Surface?

APIs have displaced traditional application layers as the primary attack surface for three compounding reasons. First, they provide direct, programmatic access to sensitive data and business logic without the friction of a UI layer. Second, they multiply rapidly as organizations build microservices and integrate third-party platforms, creating hundreds of endpoints per application with inconsistent security controls. Third, API-specific vulnerabilities such as Broken Object Level Authorization (BOLA, OWASP API1:2023) are structurally different from traditional web vulnerabilities and not caught by standard WAF rules or vulnerability scanners designed for HTML pages. FireTail’s 2024 report found that 57% of organizations experienced at least one API breach in the past two years, and among breached organizations, 73% experienced three or more incidents.

What Is API Security?

An API is a set of rules and protocols that enables software applications to communicate with each other. It defines how requests are made, how data is exchanged, and how responses are structured, allowing systems to work together in a standardized way. APIs power virtually every modern technology stack: banking apps, healthcare portals, e-commerce platforms, cloud infrastructure, and internal microservices all communicate through API calls.

REST (Representational State Transfer) APIs remain the dominant standard. GraphQL (Graph Query Language) APIs allow clients to specify exactly what data they need and have introduced new attack surfaces including introspection abuse and deeply nested query exhaustion. gRPC (Google Remote Procedure Call) uses protocol buffers and HTTP/2 for high-performance service communication. WebSocket APIs enable persistent bidirectional communication for real-time applications. Each API type has a distinct security profile requiring specific controls beyond general web application security.

API security refers to the set of controls that protect APIs from unauthorized access, data exposure, abuse, and denial of service. Because APIs act as direct entry points into application backends, weak API security frequently becomes the path of least resistance for attackers who have exhausted traditional perimeter controls.

API Threat Model: Attack Vectors and What They Exploit

OWASP API Security Top 10 (2023)	What it exploits	Example	Primary control
API1: Broken Object Level Authorization (BOLA)	Missing per-object authorization checks; API verifies authentication but not whether the user owns the specific resource	Changing /api/orders/1234 to /api/orders/1235 returns another user’s order	Enforce object-level authorization at every endpoint, not just session-level
API2: Broken Authentication	Weak token validation, missing expiry, accepting tokens from wrong issuers	JWT with algorithm:none accepted; expired tokens not rejected	Validate JWT signature and claims; enforce token expiry; use short-lived tokens
API3: Broken Object Property Level Authorization	API returns or accepts more fields than the user is authorized to see or set	Mass assignment attack setting admin:true in a user update request	Explicit allowlist of readable and writable fields per endpoint per role
API4: Unrestricted Resource Consumption	No rate limiting; API processes unlimited requests consuming CPU, memory, or downstream costs	Bulk enumeration of user records; query exhaustion via deeply nested GraphQL queries	Rate limiting per API key, IP, and user; query depth and complexity limits for GraphQL
API5: Broken Function Level Authorization	Administrative API functions exposed to non-admin users	Non-admin accessing /api/admin/users to list all users	Separate admin APIs; enforce role-based access control at function level
API6: Unrestricted Access to Sensitive Business Flows	APIs enabling high-risk business logic (account creation, payment) without flow controls	Automating account creation to build inventory-holding bot army for retail checkout	Business-logic rate limiting; CAPTCHA for sensitive flows; anomaly detection on flow patterns
API7: Server-Side Request Forgery (SSRF)	API fetches user-supplied URLs, enabling access to internal services	API fetching a URL that resolves to the internal metadata service, exposing cloud credentials	Allowlist permitted URL destinations; block private IP ranges at the application layer
API8: Security Misconfiguration	Default credentials, verbose error messages, open debug endpoints, missing TLS	Elasticsearch database exposed without authentication; API returning stack traces in errors	Disable debug modes in production; use generic error messages; audit configurations
API9: Improper Inventory Management	Undocumented or deprecated API endpoints still active and unmonitored	Legacy v1 API endpoint with weaker authentication active alongside hardened v2	Maintain complete API inventory; retire deprecated versions; monitor all active endpoints
API10: Unsafe Consumption of APIs	Organization’s own systems blindly trust data from third-party APIs without validation	Payment provider API returning malicious redirect URL that is executed without validation	Treat all third-party API responses as untrusted input; validate and sanitize before use

Real-World API Breaches: What Actually Happened

• GitHub repositories (March 2024): approximately 13 million API secrets were exposed through public repositories due to poor secret management practices. Attackers used these credentials to gain unauthorized access to cloud services and downstream applications. Prevention: use secret-scanning tools such as GitHub Advanced Security or TruffleHog in CI/CD pipelines; never commit API keys, tokens, or credentials to code repositories.
• Dell API breach (2024): an exposed API in Dell’s partner portal allowed attackers to access data belonging to 49 million customers. The breach was linked to inadequate request throttling and no anomaly detection on API traffic. This is a direct example of OWASP API4 (unrestricted resource consumption) combined with API8 (security misconfiguration).
• Microsoft Graph API abuse (May 2024): attackers exploited the Microsoft Graph API to create covert malware communication channels affecting thousands of organizations. By using legitimately obtained API access, they bypassed traditional perimeter security controls. This is a Living off the Land (LotL) attack: malicious activity using legitimate tools that blends into normal operations and requires behavioral detection rather than signature-based controls.
• APIsec incident (March 2025): a misconfigured Elasticsearch database belonging to API-testing firm APIsec exposed over three terabytes of sensitive customer data including API scan results, configuration secrets, and personally identifiable information. An OWASP API8 (security misconfiguration) failure at the database layer exposed data collected by an API security tool.
• Tea App (2025): an anonymous social app suffered a breach exposing 1.1 million private messages and thousands of user identity documents due to poorly secured storage and API endpoints. Sensitive information including phone numbers and identity documents was accessible through unprotected API endpoints, a combined API8 and API1 failure.

Encryption and Protocol Selection for API Security

Encryption protects API data in transit and at rest. Protocol selection determines whether the encryption is appropriately strong for the data being protected:

Control	Recommendation	What to avoid	Compliance relevance
External API traffic encryption	TLS 1.3; TLS_AES_256_GCM_SHA384 or TLS_CHACHA20_POLY1305_SHA256	TLS 1.0, TLS 1.1, SSL; CBC mode cipher suites; RSA key exchange (no PFS)	GDPR Art. 32; HIPAA Security Rule; PCI DSS Req. 4
Internal service-to-service API authentication	Mutual TLS (mTLS) with certificate-based identity per service	Shared static API keys without rotation; no authentication between internal services	PCI DSS Req. 8; zero-trust architecture requirements
API secrets and credentials at rest	AES-256-GCM in a dedicated secrets management system or HSM; never in code repositories	Plaintext in environment variables, config files, or source control	HIPAA; PCI DSS Req. 3; GDPR Art. 32
Token transmission	Authorization header (Bearer token); never in URL query strings	Tokens in URL query parameters (logged by proxies, CDNs, and server access logs)	PCI DSS Req. 6; OWASP API Security Top 10
Long-lived API data (PQC consideration)	Hybrid TLS: ECDHE + ML-KEM (FIPS 203) for APIs transporting data sensitive for 10+ years	RSA-only key exchange for APIs transmitting long-retention sensitive records	NIST IR 8547 2030 deprecation timeline

Authentication, Authorization, and Access Controls

Authentication and authorization failures account for the majority of exploitable API vulnerabilities in the OWASP Top 10 2023. These controls must be implemented correctly at every layer:

• OAuth 2.0 and OpenID Connect: OAuth 2.0 is the standard for delegated authorization; OpenID Connect (OIDC) adds identity verification on top. Use authorization code flow with PKCE (Proof Key for Code Exchange) for all user-facing API authentication. Machine-to-machine APIs should use client credentials flow with short-lived access tokens.
• JWT (JSON Web Token) validation: validate the signature, the issuer (iss claim), the audience (aud claim), and the expiry (exp claim) on every request. Never accept JWTs with algorithm:none. Use asymmetric key verification (RS256 or ES256) rather than shared symmetric secrets (HS256) for multi-service deployments.
• Multi-factor authentication (MFA): human-initiated API access (developer portals, API management consoles) must require MFA. FIDO2 passkeys or certificate-based authentication via CertSecure Manager provide phishing-resistant alternatives to TOTP.
• Mutual TLS (mTLS): mTLS requires both client and server to present valid certificates during the TLS handshake. For internal service-to-service APIs in microservice or zero-trust architectures, mTLS ensures that only authorized services can establish connections, eliminating the credential-only authentication that BOLA and broken authentication attacks depend on.
• OCSP stapling: enable OCSP stapling on API servers to provide real-time certificate validity checks without requiring clients to query the CA separately, reducing latency and preventing revoked certificate abuse.
• Least privilege and RBAC: each API client, user, and service account receives only the minimum permissions required for its function. Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) enforced at the API gateway and at the object level addresses BOLA and function-level authorization failures.

Monitoring, Logging, and Incident Response

API attacks frequently succeed not because defenses are absent but because anomalous behavior is not detected until significant damage has occurred. The Dell breach, for example, was linked to a lack of anomaly detection on API traffic. Effective monitoring requires:

• Behavioral baseline and anomaly detection: establish what normal API traffic looks like per endpoint: expected request volumes, typical client IDs, standard geographic distribution, normal response sizes. Deviations, such as a single API key making 50,000 requests in an hour, or responses consistently larger than the baseline, are detection signals. Signature-based rules catch known patterns; behavioral detection catches novel attacks and LotL abuse.
• SIEM integration: integrate SIEM platforms with API gateway logs, authentication logs, and application logs. SIEM correlation identifies attack patterns that appear normal in individual log streams but anomalous when correlated across sources.
• Complete audit logging: log every API request with the client identity, endpoint, HTTP method, request parameters, response code, response size, and timestamp. Logs must be stored in a write-protected environment separate from the application so that a compromised server cannot alter the audit trail. Log retention must satisfy applicable regulatory requirements (12 months under PCI DSS Requirement 10).
• API inventory monitoring: undocumented and deprecated endpoints are consistently exploited because they are not monitored. Maintain a complete API inventory and confirm that monitoring covers 100% of active endpoints, including legacy versions that should be retired.

Best Practices to Secure APIs: Implementation Checklist

1. Enforce TLS 1.3 on all API endpoints; disable TLS 1.0, 1.1, and cipher suites without perfect forward secrecy.
2. Implement object-level authorization on every endpoint; do not assume session-level authentication is sufficient to prevent BOLA.
3. Validate and sanitize all inputs; enforce JSON schema validation for REST APIs, query depth and complexity limits for GraphQL, and reject malformed requests before they reach application logic.
4. Deploy rate limiting per API key, user, and IP; apply exponential backoff on repeated failed authentication attempts.
5. Store all secrets in a dedicated secrets management system or HSM; rotate API keys on a defined schedule; scan repositories for accidentally committed credentials.
6. Use mTLS for internal service-to-service communication; manage service certificates through an automated lifecycle management platform.
7. Maintain a complete, current API inventory; retire deprecated endpoints; monitor all active endpoints including undocumented ones.
8. Integrate DAST (Dynamic Application Security Testing) tools such as OWASP ZAP into CI/CD pipelines; run API-specific security tests before every deployment.
9. Log every API request with full request metadata; integrate with SIEM; configure anomaly detection alerts for volume spikes, unusual access patterns, and responses that deviate significantly from baseline size.
10. Conduct threat modeling using STRIDE on every new API; map each threat category to a specific control before deployment rather than after a breach.

How Encryption Consulting Can Help

• Encryption Advisory Services: our Encryption Advisory Services assess API encryption coverage including TLS configuration, cipher suite selection, secrets management, and mTLS deployment. We identify gaps between current API security posture and requirements under NIST, GDPR, HIPAA, and PCI DSS, and provide a prioritized remediation roadmap.
• Encryption Audit Service: our Encryption Audit Service provides a thorough examination of cryptographic practices across your API infrastructure, identifying exposed secrets, weak algorithms, missing TLS enforcement, and PQC readiness gaps. We also assess HNDL exposure for APIs transporting long-lived sensitive data.
• CertSecure Manager: CertSecure Manager automates certificate lifecycle management for the mTLS certificates used in internal API authentication, covering discovery, issuance, renewal, and revocation across your service mesh.
• HSM as a Service: HSM as a Service provides FIPS 140-3 validated hardware storage for the API signing keys and encryption keys that, if compromised, would expose all API traffic. HSM storage prevents key extraction even under server compromise.
• PQC Advisory Services: our PQC Advisory Services assess which APIs face HNDL risk from the quantum threat, plan hybrid TLS deployments combining ECDHE with ML-KEM (FIPS 203), and provide a nine-phase migration roadmap aligned to NIST IR 8547’s 2030 deprecation timeline.

Limitations: What API Security Controls Cannot Do Alone

• Encryption does not prevent authorization failures: TLS secures the channel; it does not prevent BOLA. An attacker using a valid token to access another user’s data over a properly encrypted connection still succeeds. Encryption and authorization are separate control layers addressing different threats.
• WAFs do not catch API-specific vulnerabilities: traditional Web Application Firewalls are designed for HTML page attacks (XSS, SQL injection in form fields) and do not cover OWASP API Security Top 10 vulnerabilities like BOLA or function-level authorization failures, which require application-layer logic to detect.
• Static testing does not replace runtime monitoring: DAST and penetration testing catch vulnerabilities before deployment; behavioral anomaly detection catches attacks in production. Neither substitutes for the other. LotL attacks, where legitimate access is abused, can only be detected through runtime behavioral analysis.
• API gateways are not complete security solutions: gateways provide centralized authentication, rate limiting, and logging, but they do not enforce object-level authorization (which must be implemented in application logic) or detect LotL abuse (which requires behavioral monitoring).

Conclusion

APIs are the backbone of modern digital ecosystems, and that centrality is precisely what makes them the most productive target for attackers. With 150 billion API attacks in 2024 and 57% of organizations experiencing API breaches in the past two years, the question is not whether an organization’s APIs will be targeted, but whether its controls will contain the damage when they are.

Effective API security requires layered controls addressing distinct threat categories: TLS 1.3 with mTLS for channel security, OAuth 2.0 with object-level authorization enforcement for access control, rate limiting and anomaly detection for abuse prevention, HSM-backed secrets management for credential protection, and continuous behavioral monitoring for the attacks that signatures miss. Each layer addresses a specific class of threat; removing any one leaves a gap that the others cannot close.

If you want to assess your current API encryption posture, identify authentication and authorization gaps, or build the cryptographic controls that protect API data when everything else fails, contact Encryption Consulting to discuss an API security assessment.

Frequently Asked Questions

Why are APIs now the dominant attack surface?

APIs provide direct programmatic access to application logic and sensitive data, proliferate faster than security controls, and contain vulnerability classes (BOLA, broken function-level authorization) that standard web security tools do not detect. 150 billion of 311 billion web attacks in 2024 targeted APIs (Akamai 2024 SOTI). FireTail found API breaches rose 80% year-over-year in 2024.

What is BOLA (Broken Object Level Authorization)?

BOLA (OWASP API1:2023) occurs when an API authenticates a user but fails to verify they are authorized to access a specific object. An attacker changes an object ID in the request URL to access another user’s data. Prevention requires object-level authorization checks on every endpoint, not just session-level authentication.

What encryption is required for API security?

TLS 1.3 for all external API traffic; mutual TLS (mTLS) for internal service-to-service communication; AES-256-GCM for API secrets and sensitive data at rest stored in an HSM or secrets management system; tokens in Authorization headers, never in URL parameters.

What is a LotL (Living off the Land) API attack?

A LotL attack uses legitimate, authorized API access for malicious purposes. The attacker does not exploit a vulnerability to gain access; they abuse an API’s intended functionality using credentials they obtained legitimately. Behavioral baseline monitoring is the primary detection mechanism because signature-based tools cannot distinguish legitimate from malicious use of the same API call.

What compliance frameworks require API security controls?

GDPR Article 32 requires technical measures for personal data protection. HIPAA Security Rule requires access controls, audit logging, and transmission security for ePHI. PCI DSS v4.0 Requirements 4, 6, 7, 8, and 10 apply to APIs processing cardholder data. OWASP API Security Top 10 (2023) is the primary technical reference for API-specific vulnerability categories.

How do post-quantum requirements affect API security?

APIs transporting long-lived sensitive data face HNDL (Harvest Now, Decrypt Later) quantum risk. NIST finalized ML-KEM (FIPS 203) and ML-DSA (FIPS 204) in August 2024. Organizations should plan hybrid TLS deployments (ECDHE + ML-KEM) for high-sensitivity APIs, aligned with NIST IR 8547’s 2030 deprecation of RSA and ECC.