Most API breaches do not need an exploit: they use a valid token against an endpoint nobody knew existed, or ask for another customer's object ID and get it. Gateways and web application firewalls were not built to see that, which is why a separate API security category has grown up around discovery, posture, runtime detection and testing. Products overlap with gateways, WAAP (web application and API protection) services and testing tools, so the label tells you little. This vendor-neutral buyer's guide is for application security leads, platform teams and architects. It covers requirements, scoring criteria, vendor questions, red flags and a trial plan you can run against your own traffic.
Key takeaways
- Discovery is the foundation. You cannot protect endpoints you have not inventoried. Compare what each platform finds from traffic, code, gateways and cloud accounts against a list you already trust.
- Authorisation flaws dominate. Three of the OWASP API Security Top 10 2023 risks (API1 BOLA, API3 property level and API5 BFLA) are authorisation failures that look like normal, authenticated requests. Test detection of those specifically.
- Deployment mode decides what is possible. Out-of-band analysis cannot block; inline enforcement adds latency and an outage risk. Decide which APIs need blocking before you choose.
- The platform sees everything you send it. Captured traffic contains tokens, personal data and secrets. Score data minimisation, masking, residency and the platform's own credentials as hard as detection.
- Prove it on your APIs. Seed known flaws in a test service and measure detection, false positives and time to an actionable ticket.
Define requirements
NIST SP 800-228 (Guidelines for API Protection for Cloud-Native Systems, updated March 2026) splits controls into pre-runtime and runtime stages and recommends an incremental, risk-based approach. Use the same split, and agree these points internally first.
- API estate: REST, GraphQL, gRPC, SOAP and webhooks; public, partner (B2B) and internal east-west APIs; how many gateways, ingress controllers and service meshes sit in the path.
- Specifications: what share of APIs have an OpenAPI description, whether it is generated in CI/CD, and who owns it. Drift between the specification and live behaviour is a core finding, not a nice-to-have.
- Enforcement need: which APIs must be blocked in real time (payments, account recovery) and which only need detection and a ticket.
- Data sensitivity: which APIs return personal, payment or health data, so the platform can classify responses and you can set masking rules.
- Existing controls: gateway, WAF or WAAP, bot management, SIEM and ticketing tools the platform must integrate with. See the Bot Management Guide.
- Data constraints: whether raw traffic may leave your environment, retention limits and the GDPR Art. 28 processor terms you need if it does.
Size changes the answer. A small team with one gateway and a few dozen APIs gets most of the value from gateway policies, schema validation and pipeline testing. A large estate with several clouds, gateways and partner APIs needs automated discovery and behavioural runtime detection, because no manual inventory stays current.
| Deployment mode | How it sees traffic | Strengths | Trade-offs |
|---|---|---|---|
| Out-of-band (mirroring or log ingestion) | Traffic mirroring, gateway or load balancer logs, cloud flow and API logs | No latency or availability risk; fast to deploy; good for discovery and detection | Cannot block on its own; relies on log fields that may omit bodies |
| Inline (proxy, gateway or WAAP plug-in) | Sits in the request path | Can block, rate limit and enforce schemas in real time | Adds latency; becomes a dependency; needs a fail-open or fail-closed decision |
| Agent or sidecar | Runs in the application runtime, container or mesh | Sees decrypted east-west traffic and code context | Per-runtime support; performance overhead; change control on every service |
| Code and specification analysis | Repositories, OpenAPI files, CI/CD | Finds issues before release; maps endpoints to owners | Sees intended behaviour only, not runtime abuse |
An API gateway authenticates, routes and rate limits; a WAAP adds signature and bot protection at the edge. Neither usually baselines which user should reach which object, which is where dedicated API security platforms claim their value. Many buyers keep the gateway or WAAP enforcing and add an API security layer that detects and feeds policies back.
Evaluation criteria
Weight the criteria to your requirements. An illustrative split is 25% discovery and posture, 25% runtime detection, 15% testing, 15% data handling and platform security, 20% integrations and operations; adjust it rather than copying it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Discovery | Combines traffic, gateway configuration, cloud accounts and code; finds shadow, deprecated and zombie endpoints; records environment, version, authentication and owner, as OWASP API9:2023 recommends | Inventory only from uploaded specifications; no environment or version field |
| Posture and specification drift | Flags undocumented endpoints and parameters, unauthenticated endpoints, weak authentication schemes and missing rate limits; compares live traffic with the OpenAPI description | Posture score with no explanation of the underlying checks |
| Data classification | Detects personal, payment and credential data in requests and responses; per-endpoint sensitivity used in prioritisation | Fixed regex list you cannot tune |
| Runtime detection | Per-user and per-object baselines that detect BOLA enumeration, BFLA method tampering, excessive data exposure, credential stuffing and business flow abuse | Only signatures for injection; alerts on IP address alone |
| Response options | Block, rate limit, step-up or revoke a token through the gateway, WAF or identity provider; graded by confidence | Block-only or alert-only with no middle ground |
| Testing | Generates tests from specifications and observed traffic, including authorisation tests with two test users; runs in CI/CD and fails builds on agreed severities | Generic fuzzing with no authenticated or multi-user tests |
| False positives | Evidence per alert (requests, user, object IDs); tuning and suppression with audit trail; measured precision in the trial | "Machine learning" with no explanation of why an alert fired |
| Integrations | Gateways, ingress, service mesh, WAF or WAAP, SIEM, SOAR, ticketing and repository owners; open API for all data | Export by CSV only; no SIEM schema documentation |
| Privacy of captured traffic | Masking or tokenisation at the sensor before data leaves your network; configurable body capture; regional hosting; short default retention | Full payloads stored in the vendor cloud by default |
| Platform security | SSO with enforced MFA, role-based access to raw payloads, customer-visible audit log, scoped and rotatable sensor and integration credentials, independent assurance | Shared admin accounts; long-lived keys you cannot rotate |
Mapping to the OWASP API Security Top 10 2023
Ask each vendor to show, not describe, which of the OWASP API Security Top 10 2023 risks each capability addresses.
| Risk | Discovery and posture | Runtime | Testing |
|---|---|---|---|
| API1 Broken Object Level Authorization (CWE-639) | Endpoints taking object IDs | Per-user object access anomalies, ID enumeration | Two-user swap tests |
| API2 Broken Authentication | Unauthenticated endpoints, weak schemes | Credential stuffing, token reuse | Token expiry and signature tests |
| API3 Broken Object Property Level Authorization | Sensitive fields in responses | Excessive data exposure, mass assignment | Unexpected property writes |
| API4 Unrestricted Resource Consumption | Missing rate limits | Volume anomalies, cost spikes | Pagination and size limits |
| API5 Broken Function Level Authorization | Admin functions on ordinary paths | Method tampering (GET to DELETE) | Role matrix tests |
| API6 Unrestricted Access to Sensitive Business Flows | Flows tagged by business owner | Automation patterns, sequence timing | Abuse case scripts |
| API7 Server Side Request Forgery | Parameters accepting URLs | Requests to internal or metadata addresses | SSRF payloads |
| API8 Security Misconfiguration | CORS, verbose errors, TLS | Error rate spikes | Configuration checks |
| API9 Improper Inventory Management | Shadow, old and non-production hosts | Traffic to undocumented versions | Coverage of all versions |
| API10 Unsafe Consumption of APIs | Third-party data flows | Anomalous upstream responses | Validation of consumed data |
Where identity fits
Most API callers are non-human: partner integrations, mobile apps and services holding API keys, OAuth client credentials or JWTs. Ask whether the platform attributes traffic to a client and user identity rather than an IP address, flags keys used from new networks or at unusual volume, and can trigger revocation. See the API Key Management Guide and the OAuth 2.0 and OpenID Connect Guide.
The platform is also a privileged non-human identity itself. Its sensors see decrypted traffic, it may hold TLS private keys for inline decryption, and its connectors hold gateway and cloud credentials. The Imperva breach showed how one stolen cloud API key at a security provider exposed customers' keys and certificates. Require read-only, scoped and rotatable credentials, named owners and an exportable connector inventory. See the Service Account Security Guide.
Questions to ask vendors
- Which discovery sources do you use (traffic, gateway configuration, cloud APIs, repositories), and how do you show an endpoint's environment, version, authentication method and owner?
- Show how you detect a BOLA attack where an authenticated user requests other users' object IDs at a low rate. What baseline does it need and how long does it take to learn?
- How do you detect business flow abuse, such as the scalping and referral scenarios OWASP describes for API6, without blocking legitimate customers?
- In inline mode, what latency do you add at our peak request rate, and do you fail open or closed?
- Where is payload data masked, what leaves our network by default, where is it stored and for how long?
- What credentials do your sensors and connectors need, are they read-only, and how are they rotated? Do you ever need our TLS private keys?
- How do alerts reach our SIEM, SOAR and ticketing tools, and how are they routed to the team that owns the endpoint? See the SIEM Guide.
- Can your tests authenticate as two different users to find authorisation flaws, in CI/CD and without production data?
- What does pricing count (APIs, endpoints, calls, sensors), and what happens when discovery finds far more endpoints than expected?
Red flags
- Discovery only from specifications you upload, which misses the shadow APIs you need to find.
- Runtime detection limited to injection signatures that a WAF already provides.
- Alerts with no request evidence, or "AI" scoring nobody can explain to an engineer.
- Full request and response bodies shipped to the vendor cloud with no masking at source.
- Inline deployment with no tested fail-open behaviour or latency figures.
- Sensors or connectors that need administrator rights or long-lived keys you cannot rotate.
Proof of concept
- Scope it: pick one public API, one partner API and one internal service, behind at least one gateway, plus one repository with an OpenAPI file. Agree pass criteria and weights before the first demo.
- Start out-of-band: deploy using mirroring or logs first, with masking on and dedicated read-only credentials with an expiry date. Record every permission requested.
- Measure discovery: compare the discovered inventory against your known list. Count endpoints found that were not on it, including old versions and non-production hosts.
- Seed flaws: deploy a test service with a BOLA flaw, an admin function reachable by a normal role, an unauthenticated endpoint and a sensitive field in a response. Score which are found by posture, runtime and testing.
- Run attacks: replay BOLA enumeration, method tampering and a scripted business flow from test accounts. Measure time to alert and the evidence provided. The T-Mobile API breach shows why low-and-slow abuse of a single API must be caught.
- Count false positives: run for two weeks or more on real traffic and record precision (confirmed alerts divided by all alerts).
- Test enforcement and roll back: if inline, block one seeded attack through the gateway, then remove the sensor and confirm traffic flows normally. Revoke all trial credentials and confirm deletion of captured data in writing.
Keep tracking after go-live: endpoints with an owner and current specification, shadow or deprecated endpoints, time to remediate authorisation findings, alert precision, and releases tested in CI/CD.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: API Key Management Guide · Bot Management Guide · Token and Session Security Guide · Attack Surface Management Guide · NHI Security Platform Buyer's Guide