What is API Security?

What API security means

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 API security matters

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 reported in their 2024 State of the Internet report that API attacks grew 109% year-over-year, with web attacks targeting APIs accounting for 29% of all web attacks. Gartner predicted 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.

Salt Security’s State of API Security report found that 95% of organizations experienced an API security incident 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 our 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 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.

Top API security tools

These are the tools I would evaluate first. For full reviews, see the API security tools page.

• 42Crunch — API specification auditing with 300+ checks, conformance scanning, and micro API firewalls for runtime protection. The free IDE extensions (2M+ downloads across VS Code, JetBrains, Eclipse) make it the most accessible starting point for API security. Best for shift-left API security in development workflows.

• Salt Security — AI-powered API discovery and behavioral threat detection built on the Salt Illuminate platform. Discovers shadow and zombie APIs, detects BOLA and logic-based attacks through behavioral ML, and maps posture against PCI DSS, HIPAA, GDPR, and SOC 2. Strong on AI agent and MCP server security.

• Akamai API Security — Enterprise-scale API protection built on the former Noname Security platform (acquired by Akamai in June 2024). Discovers shadow and GenAI APIs, runs 150+ CI/CD security tests, and monitors east-west and north-south traffic. KuppingerCole Leader across four API security categories in 2025. Platform-agnostic.

• Wallarm — Integrated WAF and API protection across 160,000+ protected APIs. Auto API discovery, OWASP API Top 10 coverage, bot management, and GraphQL security. Multiple deployment options including DNS-based Security Edge for fast rollout.

• Cequence — Unified API protection with native inline blocking, bot management, and behavioral fingerprinting. Processes over 10 billion daily API interactions. KuppingerCole API Security Leader in 2025. Strong on account takeover prevention and fraud.

• APIsec — AI-powered API penetration testing with 1,200+ security playbooks. Covers REST, GraphQL, SOAP, and RAML APIs. Free tier available for testing public APIs (up to 100 endpoints). Trusted by 5,000+ organizations.

Acquired: Traceable AI was acquired by Harness in March 2025 and is being integrated into the Harness DevSecOps platform. Its distributed tracing approach to API security was notable, and the capabilities continue under the Harness brand.

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

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.