API Security
Home /
Glossary Index /
Alphabet A
What Is API Security?
API security is the set of practices, controls, and technologies used to protect Application Programming Interfaces (APIs) from unauthorized access, misuse, data exposure, and attack. An API is a defined interface through which software systems communicate — it exposes specific functionality and data to authorized callers, whether those are internal applications, third-party services, or end-user clients.
As APIs have become the primary mechanism for modern software integration, data exchange, and cloud connectivity, they have also become one of the most targeted and frequently exploited components of the enterprise technology stack. APIs often provide direct, structured access to the same sensitive data and backend functionality that user-facing applications are designed to protect — but frequently with weaker authentication controls, less rigorous testing, and far less monitoring than traditional application layers.
In 2026, API security is no longer a niche concern for development teams. It is a critical enterprise security discipline that spans development, deployment, and ongoing operations — and one where security gaps are routinely discovered through active exploitation before they are identified through internal review.
Why API Security Has Become a Critical Priority
Several converging trends have elevated API security to a board-level concern for organizations across industries.
- API proliferation: Modern organizations expose and consume thousands of APIs — both internally between microservices and externally with partners, customers, and cloud platforms. The API inventory in most large enterprises is poorly understood, inconsistently documented, and actively growing. What cannot be inventoried cannot be secured.
- APIs as primary data access channels: APIs frequently provide programmatic access to exactly the data that attackers want: customer records, financial transactions, health information, authentication tokens, and intellectual property. A single misconfigured or poorly authenticated API can expose the same data that would require substantial effort to reach through a properly secured application interface.
- Shadow APIs and zombie APIs: Many organizations have undocumented APIs (shadow APIs created without security review), deprecated APIs that were never decommissioned (zombie APIs), and APIs exposed by third-party integrations that are not tracked in internal inventories. These invisible exposure points are a primary source of API-related data breaches.
- Rapid development cycles: Agile and DevOps practices accelerate API deployment, often outpacing security review processes. APIs that reach production without adequate authentication, input validation, or rate limiting are common in environments where speed of delivery is prioritized over security review.
- Mobile and SaaS dependency: Mobile applications and SaaS platforms communicate almost exclusively through APIs. The explosion of both mobile-first and SaaS-dependent architectures has correspondingly expanded the API attack surface across consumer and enterprise environments.
The OWASP API Security Top 10
The Open Web Application Security Project (OWASP) maintains a dedicated API Security Top 10 list that documents the most critical and frequently exploited API vulnerabilities. Understanding this list is foundational to any API security program.
1. Broken Object Level Authorization (BOLA)
APIs fail to verify that the requesting user is authorized to access the specific object they are requesting. An attacker can manipulate object identifiers in requests to access records belonging to other users. BOLA (also known as Insecure Direct Object Reference, or IDOR) is the most commonly exploited API vulnerability category.
Example:
A user changes a numeric ID in an API request from their own account number to another user’s account number and receives that user’s data.
2. Broken Authentication
APIs implement authentication mechanisms incorrectly — weak tokens, tokens that do not expire, missing authentication on certain endpoints, or credential brute-force vulnerabilities.
Example:
An API endpoint that handles password resets does not implement rate limiting, enabling automated credential attacks.
3. Broken Object Property Level Authorization
APIs expose more data than the requesting user is authorized to see, or allow users to modify properties they should not have write access to.
Example:
An API returns a user object containing internal administrative flags that the consumer should not receive.
4. Unrestricted Resource Consumption
APIs do not implement rate limiting or resource consumption controls, enabling denial-of-service attacks, credential stuffing, or abusive automated usage.
Example:
A public-facing search API with no rate limiting can be queried millions of times per hour, exposing data at scale or degrading service availability.
5. Broken Function Level Authorization
APIs fail to verify that a user is authorized to invoke the specific function they are calling, exposing administrative or privileged operations to unauthorized callers.
Example:
A regular user discovers and successfully calls an administrative API endpoint because the API does not verify that the caller holds an administrative role.
6. Unrestricted Access to Sensitive Business Flows
APIs expose business processes without sufficient controls against automated abuse — enabling bots to purchase limited inventory, create fake accounts at scale, or execute fraudulent transactions.
7. Server-Side Request Forgery (SSRF)
APIs that fetch remote resources based on user-supplied URLs without validation can be exploited to make requests to internal services, metadata endpoints, or other resources that should not be accessible from outside the network.
8. Security Misconfiguration
APIs deployed with default settings, unnecessary features enabled, verbose error messages exposing internal details, or missing security headers.
9. Improper Inventory Management
Organizations lack visibility into all deployed API versions, deprecated endpoints, shadow APIs, and APIs exposed by third-party integrations.
10. Unsafe Consumption of APIs
Applications that consume third-party APIs without adequate validation of responses, failing to account for the possibility that the third-party API has been compromised or is returning malicious data.
Core API Security Controls
Authentication and Authorization
Every API endpoint must require authentication (verifying who is making the request) and enforce authorization (verifying that the caller is permitted to perform the requested operation on the requested resource). OAuth 2.0 and OpenID Connect are the widely adopted standards for API authentication in modern architectures. API keys provide a simpler alternative for service-to-service authentication where full OAuth flows are not practical.
Input Validation and Schema Enforcement
All API inputs — request bodies, query parameters, headers, and path parameters — must be validated against expected schemas before processing. Rejecting malformed or unexpected inputs prevents injection attacks, unexpected application states, and data corruption.
Rate Limiting and Throttling
APIs must implement per-user, per-client, and per-endpoint rate limits to prevent denial-of-service attacks, credential stuffing, and abusive automated access. Rate limiting should be applied at the API gateway layer and enforced consistently across all endpoints.
Transport Security
All API traffic must be encrypted using TLS. Certificate validation must be enforced on both server and client sides for sensitive integrations. APIs that accept HTTP traffic without TLS are exposing credentials and data to interception.
API Gateway and Centralized Policy Enforcement
Routing all API traffic through a centralized API gateway enables consistent enforcement of authentication, rate limiting, logging, and threat detection policies across all APIs — rather than requiring each API to implement these controls independently.
API Inventory and Discovery
Maintaining a complete, continuously updated inventory of all APIs — internal, external, shadow, and deprecated — is a prerequisite for effective security. API discovery tooling can identify undocumented endpoints that are not included in official API specifications.
Security Testing
APIs require dedicated security testing including automated scanning for OWASP API Top 10 vulnerabilities, manual penetration testing for complex business logic flaws, and continuous monitoring of API behavior in production. Static analysis of API specifications can identify authorization gaps before deployment.
Runtime Monitoring and Anomaly Detection
Monitoring API traffic patterns in production enables detection of abuse, unauthorized access, and data exfiltration attempts. Behavioral baselines help identify when API usage deviates from expected patterns in ways that may indicate attack or compromise.
API Security in the Context of Data Loss Prevention
APIs are a primary data exfiltration vector in modern environments. Sensitive data exposure through APIs — whether through misconfigured endpoints, broken authorization, or compromised API credentials — represents a form of data loss that traditional network-based DLP tools were not designed to detect.
Modern DLP platforms with SaaS API integrations and behavioral analytics provide visibility into data accessed and extracted through API channels. This includes detecting when unusually large volumes of records are requested through an API, when API access patterns deviate from established baselines, and when data is extracted through APIs to destinations outside approved business workflows.
Frequently Asked Questions
Broken Object Level Authorization (BOLA) — also known as Insecure Direct Object Reference (IDOR) — is consistently the most exploited API vulnerability category. These vulnerabilities occur when an API fails to verify that the requesting user is authorized to access the specific resource they are requesting, enabling attackers to access other users' data simply by manipulating identifiers in API requests. BOLA is highly prevalent because it results from authorization logic errors that are easy to introduce and difficult to catch through automated scanning alone.
Web application security focuses on protecting user-facing interfaces through controls like web application firewalls, input validation, and session management. API security addresses the programmatic interfaces through which applications communicate — which have distinct characteristics: they are often directly consumed by automated clients, they expose data in structured formats that are easy to extract at scale, they frequently lack the human interaction layer that catches suspicious behavior in user applications, and they are subject to specific vulnerability patterns (like BOLA) that don't have direct equivalents in traditional web application security.
A shadow API is an API endpoint that is deployed and accessible but not documented, not tracked in official API inventories, and not subject to the organization's standard security review and monitoring processes. Shadow APIs are created when developers publish endpoints outside of formal change management processes, when third-party integrations expose APIs that are not inventoried, or when old APIs are left running after new versions are deployed. They are dangerous because they receive no security attention — authentication may be absent, input validation may be missing, and they are invisible to security monitoring tools.
Both have appropriate use cases. OAuth 2.0 is the preferred authentication framework for APIs accessed by users (user-facing applications, mobile apps) or where delegated authorization (acting on behalf of a user) is required. API keys are appropriate for server-to-server communication where a human user is not involved and the client system has a stable, known identity. API keys must be treated as secrets — stored in secure vaults, rotated regularly, and never embedded in client-side code or public repositories.
An API gateway is a centralized infrastructure component that sits between API consumers and API backend services, routing requests and enforcing security policies consistently across all APIs. Key security functions provided by API gateways include: authentication and token validation, rate limiting and throttling, input validation and schema enforcement, TLS termination, logging and monitoring, and threat detection. Centralizing these controls at the gateway layer ensures consistent enforcement without requiring each individual API to implement them independently.
Microservices architectures dramatically increase the number of internal APIs — service-to-service communication that was previously handled within a monolithic application is now exposed as a network-accessible API surface. This internal API surface is often less rigorously secured than external APIs, creating east-west traffic risks where a compromised internal service can communicate with other services without authentication or authorization controls. Service mesh technologies and mutual TLS (mTLS) are commonly used to secure internal microservices communication in production environments.
