Updated on November 4, 2026
API security tools find the APIs an organisation exposes, test them for flaws such as broken object-level authorisation before release, and detect or block abuse in live traffic once they run in production. The good ones go further than listing endpoints or firing alerts. They see shadow and internal APIs that no gateway routes, show which endpoints carry sensitive data, map findings to the OWASP API Security Top 10, and send each issue to the team that can fix it with enough context to act. This guide, updated in November 2026, compares 12 API security tools across three buying motions (discovery, testing, and runtime protection) and explains which tool fits which environment and team.
Key takeaways
- ✓No single API security tool covers discovery, pre-production testing and runtime protection equally well, so most mature programmes combine at least two categories.
- ✓An API gateway enforces authentication and rate limits on the routes it knows about, but it cannot see shadow APIs or service-to-service calls that bypass it.
- ✓Runtime-based discovery (eBPF sensors, traffic mirroring) finds APIs that spec files and code scans miss, because it records what is actually being called.
- ✓Testing tools catch BOLA, broken authentication and schema flaws before release, while runtime tools catch business-logic abuse and credential stuffing that only appear in real traffic.
- ✓Score vendors on weighted criteria and run a proof of concept with your own traffic before you compare quotes.
How we evaluated API security tools
We judged each tool by how well it handles one or more of the three API security jobs (discovery, testing and runtime protection) and how much effort it takes to run in a real environment. The risk model behind the scoring is the OWASP API Security Top 10, the most widely used of the API security standards. Its 2023 edition lists BOLA, broken authentication, broken object property level authorisation, unrestricted resource consumption, broken function level authorisation, unrestricted access to sensitive business flows, SSRF, security misconfiguration, improper inventory management and unsafe consumption of APIs. NIST’s draft SP 800-228 guidelines for API protection in cloud-native systems add a lifecycle view of controls before and after deployment.
Inclusion criteria: the tool must have API discovery, API testing or runtime API protection as a documented core use case, and it must be available to buy or download in 2026. Exclusion criteria: pure API management products with no security controls, and generic network firewalls that have no understanding of API schemas.
Scoring weights
| Dimension | Weight | What we look for |
|---|---|---|
| Discovery and inventory | 20% | Shadow, zombie and internal API detection; sensitive-data classification |
| Runtime detection and blocking | 20% | Behavioural baselining, blocking modes, false-positive controls |
| Testing and shift-left | 15% | OpenAPI audit, fuzzing, CI/CD gates, spec-to-traffic drift |
| Remediation workflow | 10% | Ticketing, developer feedback, forensics, attack timelines |
| AI and agent traffic | 10% | Visibility into LLM, MCP and agent-driven API calls |
| Deployment flexibility | 10% | SaaS, self-hosted, sensor, sidecar, edge and gateway options |
| Governance and compliance | 10% | SSO/SAML, RBAC, audit logs, data residency, framework mapping |
| Time to value | 5% | Hours or weeks to the first useful finding |
Test conditions to replicate: run each candidate against the same staging environment with mirrored production traffic. Seed it with one undocumented endpoint, one BOLA flaw (for example, GET /orders/{id} returning another tenant’s order) and one endpoint that returns card numbers. Then record which tools find all three, how long each takes, and how many unrelated alerts each raises.
Master comparison
| Tool | Primary motion | Deployment model | Best for | Main tradeoff |
|---|---|---|---|---|
| Upwind | Runtime discovery, protection, posture | eBPF sensor plus agentless cloud connection | Cloud-native and Kubernetes teams | Platform approach rather than a standalone edge WAF |
| Wiz | Posture and cloud context | Agentless | Multi-cloud posture consolidation | Less live traffic-level API depth |
| Palo Alto Networks Cortex Cloud | Code-to-cloud plus WAAS | Platform with agents and pipeline integrations | Large Palo Alto estates | Setup complexity and cost |
| Aqua Security | Container runtime enforcement | Full agent architecture | Container-heavy enterprises | API security features not its focus |
| Salt Security | Dedicated API discovery and detection | Traffic integrations | Enterprises with large API estates | Another console beside your CNAPP |
| Akamai API Security | Discovery and edge protection | SaaS and edge | Existing Akamai customers | Strongest when traffic runs through Akamai |
| Cloudflare API Shield | Edge enforcement | Reverse proxy at the edge | Public APIs on Cloudflare | Limited sight of internal east-west calls |
| 42Crunch | Contract-first testing | IDE, CI/CD, API firewall | Teams with OpenAPI discipline | Depends on accurate specs |
| StackHawk | API DAST in CI/CD | Scanner in pipeline | Developer-owned testing | No runtime blocking |
| OWASP ZAP | Open-source DAST | Self-hosted | Free, scriptable testing | Tuning and maintenance burden |
| Burp Suite | Manual and assisted testing | Desktop and enterprise scanner | Pen testers and assessments | Expertise-heavy |
| Amazon API Gateway + AWS WAF | Gateway enforcement | AWS managed services | AWS-native teams | Only sees routes it fronts |
Best API security tools for 2026
For discovery and protection, the strongest picks are runtime-aware platforms. Specialist API vendors lead on traffic analytics, contract and DAST scanners handle testing, and gateways cover baseline enforcement. Each entry below uses the same structure so you can compare them directly.
Upwind
Upwind is a runtime-first CNAPP whose lightweight eBPF sensors observe what is actually running, including the API calls between services. It ties API exposure to the workloads, vulnerabilities, identities and data behind each endpoint.
- ✓Builds API visibility from runtime evidence, so it finds internal and service-to-service APIs that never appear in a gateway or spec file.
- ✓Shows which APIs actually carry sensitive data by combining API visibility with DSPM, and which vulnerabilities behind them are loaded and reachable.
- ✓Detects threats as they happen through cloud detection and response, and its Agentic Pack AI agents investigate, validate exposure and generate fixes from runtime context.
- ✓Uses a hybrid model that pairs agentless posture data with a runtime sensor, which sees which package is loaded and which process just spawned a shell.
- ✓Reviewers report full installation across EKS sensors, cloud connection and CI/CD in a few hours, and several say it fills API security and service-to-service gaps alongside their primary CNAPP.
Best for: cloud-native and Kubernetes teams that want API risk prioritised by real runtime exposure in the same platform as posture, vulnerabilities and detection. Customer rating: 4.8/5 from 88 reviews on Gartner Peer Insights.
Wiz
Wiz is an agentless CNAPP that assesses API-related risk through its cloud context graph. Reviewers highlight “toxic combinations” such as a public serverless function with an administrative IAM role.
- ✓Ships with 100+ built-in compliance frameworks, including PCI DSS, HIPAA, SOC 2, FedRAMP, GDPR and DORA.
- ✓Has native integrations with Splunk, Microsoft Sentinel, Jira, ServiceNow, GitHub, GitLab, Jenkins and Terraform.
- ✓Imports SCA and SAST findings into the Wiz Security Graph to correlate code risk with cloud context.
- ✗Avoid if you need live traffic-level API behaviour analysis. Agentless snapshots infer risk from configuration rather than observing calls.
- ✗A few reviewers say detection and response is still maturing compared with its posture features.
Best for: multi-cloud posture consolidation. Customer rating: 4.8/5 from 285 reviews on Gartner Peer Insights.
Palo Alto Networks Cortex Cloud
Cortex Cloud, which grew out of Prisma Cloud, includes Web Application and API Security (WAAS) as one capability inside a broad code-to-cloud platform.
- ✓Covers IaC scanning, secrets scanning, SCA and SBOM generation for each build, with the option to fail builds on critical issues.
- ✓Its cloud detection and response monitors for anomalous API calls, privilege escalation and unauthorised access, and can isolate resources, block IPs or disable credentials.
- ✗Avoid if you have a small team. Reviewers describe setup, custom workflows and alert tuning as tedious, and some want more granular RBAC.
- ✗Pricing is quote-based, and several reviewers call it expensive.
Best for: large enterprises already standardised on Palo Alto Networks. Customer rating: 4.5/5 from 255 reviews on Gartner Peer Insights.
Aqua Security
Aqua Security uses a full agent architecture for real-time enforcement inside running containers and Kubernetes workloads.
- ✓Reviewers praise image scanning, runtime protection, virtual patching and malware detection from build through to runtime.
- ✗Avoid if API discovery is your primary need. Aqua does not document its API security capabilities as a focus.
- ✗Reviewers say onboarding and tuning need experienced staff.
Best for: container-heavy enterprises. Customer rating: 4.3/5 from 48 reviews on Gartner Peer Insights.
Salt Security
Salt Security is a dedicated API security platform that builds an API inventory and behavioural baselines from traffic collected through gateway, load balancer and cloud integrations.
- ✓Specialises in API posture and in tracking attacker behaviour across many API calls.
- ✗Avoid if you want fewer consoles. It adds a separate tool beside your CNAPP and WAF.
Best for: enterprises with large, externally exposed API estates.
Akamai API Security
Akamai’s API security product runs alongside its edge WAF and bot management, combining API discovery with protection for traffic that passes through Akamai.
- ✓Pairs API visibility with edge-level DDoS and bot defence.
- ✗Avoid if your traffic does not run through Akamai’s edge. Coverage of internal calls depends on extra integrations.
Best for: existing Akamai customers with heavy public API traffic.
Cloudflare API Shield
Cloudflare API Shield enforces API controls at Cloudflare’s edge, including schema validation against uploaded OpenAPI files and mutual TLS.
- ✓Blocks malformed requests before they reach origin servers.
- ✗Avoid if your main risk sits in east-west traffic inside Kubernetes, because the edge never sees those calls.
Best for: public-facing APIs already proxied through Cloudflare.
42Crunch
42Crunch takes a contract-first approach. It audits OpenAPI definitions, runs conformance scans against live endpoints, and can enforce the contract with an API firewall.
- ✓Catches weak authentication definitions and loose schemas while developers are still writing code.
- ✗Avoid if your specs are incomplete or outdated. Contract tools are only as good as the contract.
Best for: design-first teams that keep OpenAPI specs current.
StackHawk
StackHawk runs dynamic API scans inside CI/CD pipelines so developers get findings on each pull request.
- ✓Tests REST, GraphQL and gRPC APIs and reports results in a form developers can act on.
- ✗Avoid as a runtime control. It finds flaws before release but does not block attacks in production.
Best for: teams where developers own security testing.
OWASP ZAP
OWASP ZAP is a free, open-source DAST scanner that can import OpenAPI definitions and run automated API scans from scripts or Docker.
- ✓It costs nothing, takes extensions, and is easy to add to any pipeline.
- ✗Avoid if you lack people to tune scan policies and authentication scripts. Expect false positives without tuning.
Best for: budget-constrained teams and startups.
Burp Suite
Burp Suite from PortSwigger is the standard toolkit for manual API testing. A free Community edition exists alongside paid Professional and enterprise scanning editions.
- ✓It is the best option for finding business-logic and authorisation flaws by hand.
- ✗Avoid if you need continuous coverage. Its depth depends on tester skill and time.
Best for: penetration testers running a point-in-time API security assessment.
Amazon API Gateway with AWS WAF
Amazon API Gateway handles authentication (IAM, Cognito, Lambda authorisers) and throttling, while AWS WAF adds managed rules and rate-based rules.
- ✓Gives AWS-native workloads baseline API endpoint security with little setup effort.
- ✗Avoid relying on it alone. It sees only the routes it fronts and does no behavioural or BOLA detection.
Best for: AWS teams that need baseline enforcement before adding dedicated tooling.
Discovery, testing and runtime protection compared
Discovery tells you which APIs exist, testing finds flaws before release, and runtime protection catches abuse that only shows up in live traffic. Each job relies on different data sources, and each data source has blind spots.
Shadow API discovery methods
| Method | What it sees | What it misses |
|---|---|---|
| eBPF sensors | Live calls at the kernel level, including east-west and encrypted service traffic on the host | Hosts without a sensor |
| Traffic mirroring / inspection | Full request and response payloads | Segments that are not mirrored |
| Gateway logs | Managed, routed APIs | Shadow APIs that bypass the gateway |
| OpenAPI ingestion | Documented design intent | Undocumented or drifted endpoints |
| Code repository scanning | Route definitions before deployment | Whether those routes are deployed or called |
| Service mesh sidecars | Mesh-managed service traffic | Workloads outside the mesh |
| External attack-surface scanning | Internet-facing hosts and endpoints | Internal APIs |
The most useful single check is spec-to-traffic drift. Compare the OpenAPI file with observed calls and flag endpoints that receive traffic but are not documented. These are often zombie versions such as /v1/ routes left running after /v2/ shipped, which is the improper inventory management risk in the OWASP list.
Runtime blocking modes
- ✓Inline (gateway, WAF, edge): blocks requests directly, but a false positive breaks production traffic. Start in monitor-only mode.
- ✓Out-of-band (mirrored traffic): adds no latency and detects through behavioural baselines, then blocks by pushing rules to a gateway or WAF.
- ✓Workload-level (sensor): correlates API activity with process, identity and data access, and responds by killing a process, isolating a workload or revoking credentials. Learn more about detecting threats while workloads run.
Judge detection quality by three things: how long baselining takes, whether you can suppress alerts per endpoint, and whether each alert includes an attack timeline. That timeline should show the source identity, the sequence of calls and the data returned, so an analyst can triage without replaying logs.
API attack classes and which tool category helps
| Attack class | Testing tools | Gateway / edge | Runtime platforms |
|---|---|---|---|
| BOLA / BFLA | Partial (needs multi-user test setup) | No | Yes (behavioural, per-object access patterns) |
| Broken authentication | Yes | Yes (token validation) | Yes (token misuse) |
| Schema abuse / mass assignment | Yes (fuzzing) | Yes (schema validation) | Partial |
| Credential stuffing and bot abuse | No | Yes (rate limits, bot management) | Yes |
| Unrestricted resource or token consumption | Partial | Yes (quotas) | Yes (anomaly detection) |
| Unsafe consumption of third-party APIs | Partial | No | Yes (outbound call visibility) |
API security testing tools and free options
Use contract testing for spec quality, DAST and fuzzing for implementation flaws, and manual testing for business logic. Most teams need at least two of these to find API vulnerabilities reliably.
- ✓Contract and spec audit: flags missing auth schemes, unbounded strings and loose schemas in OpenAPI files before code is merged.
- ✓DAST and fuzzing: sends malformed, oversized and out-of-type payloads to running endpoints. See how API-capable scanners compare in our guide to dynamic application scanners compared.
- ✓Business-logic abuse testing: uses two test users to confirm that user A cannot read user B’s objects. This is the only reliable pre-production check for BOLA.
- ✓CI/CD gates: fail the build on new critical findings only, so existing debt does not block every release.
- ✓Drift detection: re-run conformance checks after deployment to catch behaviour that departs from the spec.
The good free API security testing tools are OWASP ZAP for automated scanning and Burp Suite Community for manual work. You pay for free tools in staff time instead of licence fees. Maintaining authentication scripts for 40 microservices with rotating OAuth tokens, for example, can take a few engineer-days per quarter.
Do testing tools replace runtime protection? No. A scanner tests the code paths you point it at. Credential stuffing, scraping and slow BOLA enumeration across thousands of IDs only show up in production traffic patterns.
How to choose an API security solution
Match the solution to your architecture first, then to your buyer profile, and only then to price. A gateway alone handles rate limiting, authentication and logging, but it misses shadow APIs and advanced bot or multi-vector DDoS attacks. Defence in depth adds WAF, bot management and dedicated API protection on top.
Deployment patterns
- ✓Gateway-only: fits a small number of public APIs on one cloud. Add a free scanner in CI.
- ✓Gateway plus dedicated API security: mirrored traffic feeds a specialist platform that pushes blocking rules back to the gateway. Fits large external API estates.
- ✓Kubernetes or service-mesh heavy: most API traffic is east-west, so you need sensor or sidecar visibility that an edge proxy cannot provide.
Buyer profiles
| Profile | Starting stack |
|---|---|
| Startup | Cloud gateway with WAF, plus OWASP ZAP in CI |
| Mid-market SaaS | CI/CD API DAST, plus runtime discovery tied to cloud posture |
| Regulated enterprise | Platform with framework mapping (PCI DSS, HIPAA, GDPR), SSO/SAML, granular RBAC, audit logs and data residency options, plus edge WAAP |
| Platform engineering team | Low-overhead sensors and policy-as-code, with no per-service agents to babysit |
| Cloud-native team | eBPF-based runtime platform covering APIs, workloads and data |
| AI-product team | Runtime visibility into LLM, MCP and agent API calls, plus quotas against token exhaustion |
Pricing and implementation burden
Commercial API security services are usually quote-based, so normalise quotes yourself. Ask what the unit is (API calls, endpoints, workloads or cloud accounts), which features sit in premium tiers, and what infrastructure you must run, such as traffic mirroring, collectors or sidecars. Ask for a realistic time to first finding as well. Sensor-based platforms can show results within days, while traffic-mirroring deployments often need network changes first. If you already run application security posture management, check that API findings flow into it so you do not end up with a second backlog.
API security best practices
Most API breaches come from logic flaws rather than missing patches, so the practices that matter most are keeping an accurate inventory, enforcing authorisation at the object level, and monitoring live behaviour.
- Inventory every API, including internal, deprecated and third-party ones, from runtime evidence rather than documentation alone.
- Classify which endpoints return PII, credentials or payment data, and rank API security risks by that sensitivity.
- Enforce authorisation checks on every object access server-side. Never trust client-supplied IDs.
- Validate requests against schemas and reject unknown properties to prevent mass assignment.
- Apply rate limits and quotas per identity, not just per IP, to blunt credential stuffing and token exhaustion.
- Gate CI/CD on new critical API findings and re-test after every spec change.
- Run behavioural detection in production and route alerts with full attack timelines to ticketing and your SIEM.
- Review and retire unused API versions and credentials on a fixed schedule as part of ongoing API security management.
How Upwind fits into your API security strategy
Upwind is the runtime layer that connects API exposure to the workloads, identities and data behind it. One eBPF sensor shows which APIs are actually called, which carry sensitive data, and whether the vulnerabilities behind them are loaded and reachable. Its detection and response and Agentic Pack AI agents then investigate and generate fixes. A gateway or edge WAF keeps doing inline enforcement, and Upwind supplies the context that decides what to fix first. Reviewers note that GCP support is less developed than AWS support.
- ✓Discovers internal and external APIs from live traffic
- ✓Prioritises API risk by data sensitivity and reachability
- ✓Combines API, DSPM, vulnerability and identity context in one platform
- ✓Investigates live threats with AI agents grounded in runtime data
Building an API security stack for 2026
Combine runtime-based discovery, pre-release testing and enforcement at the gateway or edge, and have each layer feed the same remediation workflow. Start by scoring candidates against the weights above. Run a proof of concept with seeded flaws and mirrored traffic, then add testing and edge controls where your architecture exposes gaps. Choose API security tools by what they prove about your real traffic rather than by how many alerts they produce.
FAQ
Can one API security tool handle discovery, testing, and runtime protection equally well?
No. The article explains that no single API security tool covers discovery, pre-production testing, and runtime protection equally well, so most mature programmes combine at least two categories.
Why is an API gateway or WAF not enough on its own?
A gateway can enforce authentication, throttling, and rate limits on the routes it knows about, but it cannot see shadow APIs, undocumented endpoints, or internal service-to-service calls that bypass it. The guide recommends defense in depth with testing and runtime visibility.
What is the most effective way to find shadow and internal APIs?
The article says runtime-based discovery is most effective because it records what is actually being called. Methods such as eBPF sensors and traffic mirroring can find APIs that spec files, gateway logs, and code scans miss.
Do API security testing tools replace runtime protection?
No. Testing tools can catch flaws such as broken authentication, schema issues, and some BOLA cases before release, but they cannot see production-only abuse patterns like credential stuffing, scraping, or slow BOLA enumeration across many IDs.
How should teams evaluate API security tools before buying?
The guide recommends scoring vendors on weighted criteria and running a proof of concept with your own traffic. It suggests testing each candidate against the same staging environment with mirrored production traffic and seeded issues such as an undocumented endpoint, a BOLA flaw, and an endpoint that returns card numbers.