What API security means#
API security is the practice of protecting application programming interfaces (APIs) from misuse, abuse, and unauthorized access. It covers three layers: discovery (knowing your APIs exist), testing (finding weaknesses before attackers do), and runtime protection (blocking attacks on live API traffic).
The OWASP API Security Top 10 — currently the 2023 edition — is the canonical reference for the risk categories the discipline targets.
API security is about finding and fixing vulnerabilities in your APIs before attackers exploit them, and stopping attacks against those APIs at runtime.
APIs are not web pages. They are machine-to-machine interfaces that expose data and business logic directly.
When a mobile app fetches your bank balance, it calls an API. When a partner system places an order, it calls an API.
When a microservice authenticates a user, it calls an API. Every one of these interactions is a potential attack vector.
The vulnerabilities that matter for APIs are different from traditional web application flaws.
SQL injection and XSS still apply, but the real API-specific risks are authorization failures, excessive data exposure, and business logic abuse.
A DAST
scanner might find an injection flaw in your API, but it will not catch that your /api/users/123/orders endpoint lets any authenticated user view any other user’s orders just by changing the ID.
That is Broken Object Level Authorization (BOLA) , and it is the number one risk on the OWASP API Security Top 10.
API security covers the full lifecycle: auditing API specifications at design time, testing APIs for vulnerabilities during development, discovering all APIs in your environment (including the ones nobody documented), and monitoring API traffic at runtime for anomalies.
Why does API security matter?#
APIs are now the primary attack surface for most organizations. That is not a vendor talking point.
It is the reality of how modern software is built.
Akamai’s 2025 State of the Internet report found a 33% year-over-year increase in web attacks targeting APIs, with API attacks accounting for a growing share of all web attacks. Gartner predicted in 2021 that APIs would become the most frequent attack vector by 2024, and the data supports that prediction.
The breaches tell the story. T-Mobile had 37 million customer records exposed through an API in January 2023 .
Optus lost 9.8 million customer records through an unauthenticated API endpoint in 2022. Twitter had 5.4 million user records scraped through an API vulnerability that same year.
These were not sophisticated zero-day exploits. They were basic authorization and authentication failures in APIs.
Why does this keep happening? Organizations have thousands of API endpoints, many undocumented, and traditional security tools were not built to understand API-specific risks.
A WAF might block SQL injection payloads, but it has no concept of whether user A should be allowed to access user B’s data through a legitimate API call.
According to Salt Security’s State of API Security report, 95% of organizations experienced API security problems in production APIs in the past 12 months. The number of APIs is growing faster than security teams can manually keep up with.
OWASP API Security Top 10#
The OWASP API Security Top 10 (2023 edition) is the standard reference for API-specific risks. If you are evaluating API security tools, this is the baseline of what they should detect.
API1:2023 — Broken Object Level Authorization (BOLA)#
The most common and most exploited API vulnerability. The API exposes object IDs in requests (/api/users/123/records), and the server does not verify that the authenticated user is authorized to access that specific object.
An attacker changes 123 to 124 and gets someone else’s data. It is trivially easy to exploit and invisible to traditional scanners.
API2:2023 — Broken Authentication#
Weak authentication mechanisms in APIs : missing rate limiting on login endpoints, tokens that never expire, API keys transmitted in URLs, weak password policies on API-accessible accounts. Authentication is harder to get right for APIs than for web applications because there is no browser managing sessions.
API3:2023 — Broken Object Property Level Authorization#
The API returns more data than the client needs (excessive data exposure ), or accepts property modifications it should not (mass assignment).
An API that returns a user profile might include internal fields like role or is_admin that the frontend just ignores but an attacker can read.
Or a user update endpoint might accept a role field in the request body that the UI never sends but an attacker can add.
API4:2023 — Unrestricted Resource Consumption#
APIs that lack rate limiting, pagination limits, or request size constraints . An attacker can exhaust server resources, run up cloud costs, or perform denial-of-service by calling an expensive API endpoint in a tight loop.
API5:2023 — Broken Function Level Authorization#
The API does not enforce authorization at the function level. A regular user can call admin endpoints by guessing the URL pattern. GET /api/users is allowed for everyone, but DELETE /api/users/123 should only work for admins, and the API does not check
.
API6:2023 — Unrestricted Access to Sensitive Business Flows#
Automated abuse of legitimate API functionality: mass account creation, inventory hoarding, automated purchasing. The API works as designed, but uncontrolled automation turns it into a vulnerability.
API7:2023 — Server-Side Request Forgery (SSRF)#
The API accepts a URL as input and fetches it server-side. An attacker points that URL at internal services, cloud metadata endpoints, or other resources the server can reach but the attacker cannot .
API8:2023 — Security Misconfiguration#
Missing security headers, verbose error messages, unnecessary HTTP methods enabled, CORS misconfiguration, default credentials on API gateways. The same category as web misconfiguration, but API-specific configurations add more surface area.
API9:2023 — Improper Inventory Management#
The organization does not know which APIs exist, which versions are running, or which are exposed to the internet. Old API versions with known vulnerabilities stay live because nobody tracks them. This is the shadow API problem .
API10:2023 — Unsafe Consumption of APIs#
Your application trusts data from third-party APIs without validation . If a partner API is compromised or returns unexpected data, your application becomes vulnerable because it does not sanitize or validate the response.
Types of API security testing#
API security testing happens at different stages of the lifecycle. Each stage catches different problems.
Design-time: specification auditing#
Before writing code, test the API specification itself. Tools like 42Crunch audit OpenAPI/Swagger specs against 300+ security checks and assign a score from 0 to 100.
They catch problems like missing authentication requirements, overly permissive schemas, and sensitive data in URL parameters before any code is written.
This is the cheapest place to find issues. A flawed API contract produces flawed implementations across every team that builds against it.
Build-time: SAST for APIs#
Static analysis applied to API code. Traditional SAST tools catch injection flaws in API handlers the same way they do for web controllers.
Some API security tools add API-specific rules: checking that authorization middleware is applied to every route, verifying that response schemas do not leak internal fields.
Test-time: dynamic API testing#
Running security tests against a deployed API. This is where dedicated API security tools differ most from generic DAST.
Tools like APIsec and 42Crunch Conformance Scan import your API specification, understand the expected behavior, and test every endpoint for deviations: authentication bypass, authorization failures, input validation gaps, and response data leakage.
APIsec runs 1,200+ security playbooks against APIs, including business logic tests like BOLA and RBAC violations that generic fuzzers miss. For a complete walkthrough of API testing methods and OWASP API Top 10 coverage, see the API security testing guide .
Runtime: discovery, monitoring, and protection#
The always-on layer. Runtime API security tools sit in the traffic path (or analyze traffic mirrors) and do the following:
Discovery — Inventory every API in your environment by analyzing actual traffic. Find shadow APIs, zombie APIs (old versions still receiving traffic), and undocumented endpoints.
Behavioral detection — Baseline normal API traffic patterns and flag anomalies. A user who normally calls the profile API once per session suddenly calling it 10,000 times with sequential IDs is a BOLA attack in progress.
Protection — Block malicious requests inline. Wallarm and Cequence offer native inline blocking capabilities that can stop attacks without relying on an external WAF.
How do API security tools work?#
API security platforms have capabilities that traditional application security tools do not. Here is what the major ones do under the hood.
API discovery#
You cannot protect APIs you do not know about. Every API security program starts with discovery.
Tools analyze traffic from API gateways, load balancers, cloud environments, and service meshes to build a complete API inventory. Salt Security pulls metadata from AWS, Azure, GCP, and gateways like Kong and Apigee. Akamai API Security monitors both north-south (external) and east-west (internal service-to-service) traffic.
The output is an inventory of every API endpoint, including its parameters, data types, authentication mechanisms, and whether it handles sensitive data like PII or financial information.
Posture management#
Once APIs are discovered, posture management checks them against security standards. Are all endpoints authenticated?
Do they conform to their OpenAPI specification? Are they compliant with OWASP API Security Top 10? Are they exposing sensitive data?
Akamai API Security maps posture against compliance frameworks. Salt Security offers a Policy Hub with roughly 100 pre-loaded posture rules covering PCI DSS, HIPAA, GDPR, and SOC 2.
Behavioral threat detection#
Signature-based detection misses API-specific attacks because the requests look legitimate. A BOLA attack uses the same endpoint with the same HTTP method and valid authentication. The only difference is the object ID.
API security tools use machine learning to baseline normal behavior and detect deviations. Salt Security and Akamai API Security build behavioral models from traffic patterns and flag anomalies that indicate attacker activity: sequential ID enumeration, unusual access patterns across endpoints, spikes in error rates from specific clients.
Runtime protection#
Some platforms go beyond detection and block attacks inline. Wallarm combines WAF capabilities with API-specific protection, handling API abuse, bot management, and DDoS protection across 160,000+ APIs. Cequence processes over 10 billion API interactions daily with native inline blocking and behavioral fingerprinting.
API security vs DAST#
Generic DAST tools can scan APIs. Most modern DAST scanners import OpenAPI specs and test API endpoints for injection flaws and misconfigurations.
So why would you need a dedicated API security tool?
The answer comes down to what each approach can detect.
What DAST catches in APIs: injection vulnerabilities (SQL injection, command injection, XSS in API responses), security misconfigurations (missing headers, verbose errors, unnecessary HTTP methods), some authentication issues (weak tokens, missing rate limiting).
What DAST misses: BOLA and BFLA (the scanner does not understand your authorization model), excessive data exposure (the scanner does not know which fields should be in the response), shadow API discovery (DAST tests known endpoints, it does not find unknown ones), business logic abuse (rate abuse, inventory hoarding, automated scraping), behavioral anomalies at runtime.
If your API surface is small, a handful of internal services with clear specifications, DAST plus manual penetration testing covers most risks. Add a spec linter like 42Crunch for design-time checks.
If you have dozens or hundreds of APIs, external-facing endpoints, microservices architectures, or regulatory requirements around API data handling, you need a dedicated platform. Discovery, behavioral analysis, and continuous runtime monitoring are things DAST was never designed to do.
Getting started#
If you have not invested in API security before, here is a practical path.
Know what you have. You cannot secure APIs you do not know exist.
Start with an inventory. If you have an API gateway, pull the list of registered routes.
If you use Kubernetes, check your Ingress and Service definitions. For a quick manual assessment, that gets you partway there.
For a thorough inventory including shadow APIs, you need a tool that analyzes actual traffic.
Audit your API specifications. If you have OpenAPI specs, run them through 42Crunch using the free IDE extension.
Fix the issues it finds. If you do not have OpenAPI specs, writing them is a valuable exercise that forces you to document authentication, authorization, and data schemas.
Test your most critical APIs. Pick your highest-risk APIs: the ones that handle authentication, payments, or personal data.
Run them through APIsec or a manual penetration test focused on OWASP API Security Top 10 risks. BOLA testing alone will likely find issues.
Add runtime monitoring. Deploy an API security tool that monitors traffic to your APIs.
Start with discovery to validate your inventory, then enable behavioral detection. Salt Security , Akamai API Security , and Wallarm all offer this.
Integrate into CI/CD. As your API security program matures, add specification auditing and security testing to your pipeline. 42Crunch conformance scans and APIsec automated testing both integrate with CI/CD systems.
Do not try to do everything at once. Inventory first, test the critical APIs, add monitoring, then automate. You will find real issues at every step.
FAQ#
What is API security? API security is the practice of protecting application programming interfaces (APIs) from misuse, abuse, and unauthorized access across discovery, testing, and runtime layers. It targets the risks captured in the OWASP API Security Top 10 — broken object-level authorization, broken authentication, excessive data exposure, and the rest — using a mix of design-time, development-time, and production-time controls.
What is the OWASP API Top 10? The OWASP API Security Top 10 is the canonical risk reference for APIs, published by the Open Web Application Security Project. The current version is the 2023 edition, which lists BOLA (broken object-level authorization), broken authentication, broken object property level authorization, unrestricted resource consumption, broken function-level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, and unsafe consumption of APIs as the top risks. I dig deeper into each in my API security testing guide .
How is API security different from web application security? Web application security tools — including most DAST scanners — were built for HTML pages, browser sessions, and form-based input. APIs expose machine-to-machine endpoints with structured payloads, and the highest-impact risks (BOLA, broken function-level authorization, business-logic abuse) are not detectable by signature-based web scanners. The “API security vs DAST” section above covers this in more detail.
What are the 9 types of API testing? The discipline usually divides into nine types: validation testing (request and response shape), functional testing (does the endpoint behave correctly), UI testing (the consuming client), load testing (volume and concurrency), runtime testing (live traffic monitoring), security testing (OWASP API Top 10 scans), penetration testing (manual or automated adversary simulation), fuzz testing (malformed input generation), and interoperability testing (third-party integrations). Most modern API security tools combine three or four of these — typically discovery, security testing, runtime monitoring, and fuzz testing.
How do you test API security? Start with the API inventory — most teams underestimate the count by 30–40% once shadow APIs are included — then layer security testing for OWASP API Top 10 categories on top, and finally add runtime monitoring against the live traffic. Tools like 42Crunch handle contract-first conformance, APIsec automates pentests against running endpoints, and Salt Security or Akamai API Security cover runtime detection.
What are common API security risks? The dominant category in production incidents is broken object-level authorization (BOLA — OWASP API1:2023), where one authenticated user accesses another user’s data by manipulating an object identifier. Broken authentication, excessive data exposure, lack of resources and rate limiting, broken function-level authorization, and security misconfiguration round out the risk set most teams encounter, and all six are tokenized in the API security tools comparison .
