An API security RFP that asks bidders whether they "cover the OWASP API Security Top 10" will get a yes from every one of them, and still not tell you whether the platform can spot one authenticated customer reading another customer's records. This template is a ready-to-issue request for proposal for an API security platform: discovery and posture, specification drift, runtime detection and response, API testing, data handling and the security of the platform itself. Every requirement has an ID, a type and a way to prove it in a proof of concept. It is vendor-neutral and written for API and AppSec leads, platform engineering, procurement and evaluation panels. For how the market works and what each deployment mode can and cannot do, read the API Security Buyer's Guide first; for the underlying controls, the API Security Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [number of APIs] and [gateways in use], with your own details. Delete requirements that do not apply and add your own using the same ID scheme.
- Each requirement has an ID (for example API-RUN-02) and a type: M mandatory (pass or fail), S scored (0 to 5, then weighted) or I informational (not scored, used for clarification and contract terms).
- Weights, volumes, timings and percentages in brackets are illustrative, not benchmarks. Fix them before issue and do not change them after responses arrive.
- Issue sections 1 to 9 to bidders. The Implementation guidance section is for your evaluation panel only.
- If you are also buying edge protection, align overlapping requirements with the WAF and WAAP RFP Template so schema enforcement and bot controls are not bought twice. API testing in pipelines overlaps with the Application Security Testing RFP Template.
1. Purpose and scope
[Organisation] invites proposals for an API security platform, implementation services and support for a term of [three] years. The platform must discover and inventory [Organisation]'s APIs, assess their posture against agreed policy, detect and help respond to abuse at runtime, test APIs before release, and report measurable risk reduction. In scope: approximately [number] APIs across [REST, GraphQL, gRPC, SOAP, webhooks], exposed as [public, partner and internal] interfaces, fronted by [gateways, ingress controllers, service meshes] in [cloud providers and data centres]. Out of scope: replacement of existing API gateways and web application firewalls, unless offered as a separately priced option.
2. Organisation background and current state
- API estate: [number] APIs, of which approximately [percentage] have a maintained OpenAPI description; [number] GraphQL endpoints; [number] partner integrations.
- Traffic: peak [requests per second] and average [requests per day] across in-scope APIs; [percentage] east-west traffic between services.
- Existing controls: API gateways [types], WAF or WAAP [type], bot management [yes or no], identity provider [type], SIEM [type], SOAR [type], ticketing [type].
- Development: source control [platforms], CI/CD [platforms], number of API-owning teams [number].
- Drivers: [for example unknown and deprecated endpoints found in a penetration test, regulatory obligations for personal or payment data, partner security questionnaires].
- Data constraints: [whether raw request and response bodies may leave Organisation's environment, permitted hosting regions, retention limits].
3. Instructions to bidders
- Answer every requirement with Comply, Partially comply (explain) or Does not comply, plus a description of how it is met and whether the capability is generally available, in beta or on the roadmap. Roadmap and beta items score zero.
- For each requirement, state which deployment mode delivers it (out-of-band, inline, agent or sidecar, code and specification analysis). A requirement met only in a mode [Organisation] has not chosen is Partially comply.
- Identify any requirement met through a third-party product, a partner or professional services.
- State where customer data is processed and stored, which fields of captured traffic leave [Organisation]'s environment, and list sub-processors.
- Provide [three] references of similar scale and architecture, including one with [gateway type] in the request path.
- Submit clarification questions by [date]. Responses are due by [date] in the response workbook provided.
4. Functional requirements
4.1 Discovery and inventory
| ID | Requirement | Type |
|---|
| API-DIS-01 | Discovers APIs and endpoints from at least two independent sources among traffic, gateway and ingress configuration, cloud accounts and source code; list each source supported and the access each requires. | M |
| API-DIS-02 | Records for each endpoint the host, path, method, version, environment, authentication scheme observed, data sensitivity and owning team, in line with OWASP API9:2023 Improper Inventory Management. | M |
| API-DIS-03 | Identifies shadow endpoints (live but undocumented), deprecated or zombie versions still receiving traffic, and endpoints exposed in an environment where they should not be. | M |
| API-DIS-04 | Supports REST, GraphQL, gRPC and SOAP; state the depth of support for each (for example GraphQL operation-level inventory rather than a single endpoint). | S |
| API-DIS-05 | Assigns ownership from [service catalogue, CMDB, CODEOWNERS files, gateway metadata] and lets [Organisation] correct it, with corrections retained across rescans. | S |
| API-DIS-06 | Records third-party APIs that [Organisation]'s services consume, to support OWASP API10:2023 Unsafe Consumption of APIs. | I |
4.2 Posture and specification drift
| ID | Requirement | Type |
|---|
| API-POS-01 | Imports OpenAPI descriptions (state the versions supported, including 3.1 and 3.2) and compares them with observed behaviour, flagging undocumented endpoints, parameters, response fields and status codes. | M |
| API-POS-02 | Generates a draft OpenAPI description from observed traffic for APIs without one, exportable for review by the owning team. | S |
| API-POS-03 | Flags unauthenticated endpoints, weak authentication schemes (for example static API keys in query strings, tokens without expiry), missing rate limits and sensitive data returned without need. | M |
| API-POS-04 | Lets [Organisation] write custom posture policies and explains the check behind every posture finding, rather than presenting an unexplained score. | S |
| API-POS-05 | Classifies personal, payment, health and credential data in requests and responses, with classifiers [Organisation] can tune and extend. | S |
4.3 Runtime detection
| ID | Requirement | Type |
|---|
| API-RUN-01 | Detects broken object level authorization (API1:2023) by baselining which caller identity accesses which object identifiers, and alerts on enumeration and cross-tenant access. | M |
| API-RUN-02 | Detects broken function level authorization (API5:2023), such as ordinary users calling administrative functions or tampering with HTTP methods. | M |
| API-RUN-03 | Detects excessive data exposure and mass assignment (API3:2023), including unexpected properties written in requests. | S |
| API-RUN-04 | Detects credential stuffing and token abuse against authentication endpoints (API2:2023), correlating by token, client and session, not only source IP address. | M |
| API-RUN-05 | Detects unrestricted resource consumption (API4:2023) and automated abuse of sensitive business flows (API6:2023) that [Organisation] defines, for example [account creation, checkout, password reset]. | S |
| API-RUN-06 | Detects server-side request forgery patterns (API7:2023), including requests that cause calls to internal or cloud metadata addresses. | S |
| API-RUN-07 | Provides evidence with every alert: the requests, caller identity, object identifiers, the baseline it deviated from and the reason it fired. | M |
4.4 Response and enforcement
| ID | Requirement | Type |
|---|
| API-RSP-01 | Offers graded responses (alert, rate limit, block, step-up authentication, token revocation) through [gateways, WAF or WAAP, identity provider], configurable by confidence and by API tier. | S |
| API-RSP-02 | For any inline component, documents added latency at [peak traffic], the fail-open or fail-closed behaviour, and how it is bypassed in an outage. | M |
| API-RSP-03 | Enforces schemas from OpenAPI descriptions at runtime (positive security model), with a log-only mode before blocking. | S |
| API-RSP-04 | Sends alerts and findings to [SIEM] and [SOAR] in a documented schema with delivery latency stated, and creates tickets in [ticketing] routed to the owning team. | M |
4.5 API testing
| ID | Requirement | Type |
|---|
| API-TST-01 | Generates security tests from OpenAPI or GraphQL schemas and from observed traffic, and runs them in [CI/CD platforms] with build failure on agreed severities. | S |
| API-TST-02 | Runs authorisation tests with at least two test identities and roles, swapping object identifiers and functions between them to find API1 and API5 flaws. | M |
| API-TST-03 | Runs safely against non-production environments by default; state which tests can modify data and how production testing is restricted. | M |
| API-TST-04 | Exports findings in SARIF 2.1.0 or a documented JSON format with stable identifiers for deduplication. | S |
For manual testing that complements automated tests, see the API Penetration Testing Guide; for GraphQL specifics, the GraphQL Security Guide.
4.6 Reporting
| ID | Requirement | Type |
|---|
| API-REP-01 | Reports inventory coverage, specification coverage, unauthenticated and sensitive endpoints, open findings by severity and owner, and time to remediate, exportable by API. | M |
| API-REP-02 | Maps findings to the OWASP API Security Top 10 2023 and to [Organisation]'s control framework for audit evidence. | S |
5. Data handling and privacy
Captured API traffic holds bearer tokens, session cookies, personal data and sometimes payment data. These requirements are usually decisive.
| ID | Requirement | Type |
|---|
| API-DAT-01 | Masks or tokenises configured fields (authorisation headers, cookies, [named fields]) at the sensor, before data leaves [Organisation]'s environment. | M |
| API-DAT-02 | Allows body capture to be disabled or limited per API and per field, and states which detections stop working when it is. | M |
| API-DAT-03 | Hosts data in [regions]; states default and configurable retention for metadata, payload samples and alerts; deletes data on request and at contract end with confirmation. | M |
| API-DAT-04 | Signs a data processing agreement meeting [GDPR Art. 28 or applicable law] and lists sub-processors with notice of change. | M |
The platform holds a map of every API, samples of sensitive traffic and credentials for gateways and cloud accounts. Treat it as a high-value system with non-human identities of its own. See the API Key Management Guide.
| ID | Requirement | Type |
|---|
| API-SEC-01 | Supports SSO with SAML or OIDC, enforced MFA, SCIM provisioning and role-based access, with access to raw payload samples restricted to named roles. | M |
| API-SEC-02 | Sensor, connector and integration credentials are scoped to least privilege, read-only by default, rotatable by [Organisation] without downtime, and short-lived or federated where the source supports it; document every permission requested. | M |
| API-SEC-03 | Provides a customer-visible audit log of user and API actions, including policy changes and payload views, exportable to [SIEM]. | M |
| API-SEC-04 | Provides current independent assurance (for example a SOC 2 Type II report or ISO/IEC 27001 certificate), a description of its secure development practice and an SBOM for deployed sensors on request. | S |
| API-SEC-05 | Notifies [Organisation] of security incidents affecting its data within [hours], with named contacts. | M |
7. Implementation, services and support
- API-SVC-01 (M): an implementation plan reaching discovery across [percentage] of in-scope traffic within [60 days] and runtime detection on [tier 1 APIs] within [90 days].
- API-SVC-02 (S): named technical contact, tuning support during the first [six months], and training for AppSec, SOC and API-owning teams.
- API-SVC-03 (M): support hours, severity definitions, response times, and a platform availability commitment of [99.9%] for the management plane.
- API-SVC-04 (I): process and typical time to add support for a new gateway, protocol or data classifier.
8. Pricing schedule
| Line | What the bidder must state |
|---|
| API-COM-01 Licence metric (M) | Unit (APIs, endpoints, requests, hosts or sensors) and exactly how it is counted, including discovered shadow endpoints and non-production traffic. |
| API-COM-02 Annual subscription (M) | Price for years 1 to [3] at current volume and at [150%] growth, every module itemised. |
| API-COM-03 Overage (M) | Charges or throttling when traffic exceeds the licence, including during an attack. |
| API-COM-04 Services (M) | Implementation, tuning and training days with day rates. |
| API-COM-05 Exit (S) | Export of inventory, findings and generated specifications in documented formats at no cost, during the term and at exit. |
9. Evaluation method and proof of concept
Responses are scored in two stages: the written response, then a proof of concept for the [two or three] highest scoring bidders. Any mandatory failure excludes the bid. Scored requirements are rated 0 (absent) to 5 (fully met and demonstrated) and multiplied by the area weight.
| Area | Illustrative weight |
|---|
| Discovery, inventory and posture (4.1, 4.2) | [25%] |
| Runtime detection and response (4.3, 4.4) | [25%] |
| API testing and reporting (4.5, 4.6) | [15%] |
| Data handling and platform security (5, 6) | [15%] |
| Services (7) | [5%] |
| Pricing (8) | [15%] |
Proof of concept script, run on [Organisation]'s own traffic and a seeded test service over [three to four weeks]:
- Discovery: give the bidder no inventory. After [seven] days compare what it found with the panel's known list, including [two] planted shadow endpoints and [one] deprecated version still receiving traffic.
- Drift: deploy a change adding an undocumented parameter and a new sensitive response field; record time to detection.
- BOLA: with two test accounts, have account A request account B's objects in a seeded service; confirm detection, the evidence shown and the response options.
- BFLA: have an ordinary user call an administrative function and change GET to DELETE on a protected resource.
- Credential stuffing: run a controlled, approved replay of failed logins from a small rotating set of addresses against a test login API.
- Testing: run the bidder's pipeline tests against the seeded service and count true and false findings against the planted flaws.
- Data handling: inspect what actually reached the bidder's cloud and confirm masked fields are masked.
- Platform permissions: compare the permissions granted to sensors and connectors with API-SEC-02.
Implementation guidance
This section is for the evaluation panel and is not issued to bidders.
Before you issue
- Build the known list: an inventory you trust, however partial, with planted shadow endpoints. Discovery claims cannot be judged without it.
- Decide enforcement needs: which APIs need real-time blocking (payments, account recovery) and which only need detection and a ticket. This decides whether inline requirements are mandatory.
- Prepare a seeded test service: deliberate API1, API3, API5 and API7 flaws with two test identities, so the proof of concept measures detection rather than demos.
- Agree data rules with privacy and legal: which fields must be masked and whether payloads may leave your environment, before bidders design around assumptions.
- Map the boundary with the gateway and WAAP: record which controls stay in the gateway (authentication, quotas) so the platform adds detection rather than duplicating policy. See the API Gateway Security Guide.
Choosing between approaches
| Approach | Fits when | Trade-off |
|---|
| Gateway policies, schema validation and pipeline tests only | Small estate, one gateway, a few dozen documented APIs | Little runtime insight into authorisation abuse; discovery is manual |
| Dedicated out-of-band API security platform | Many teams and gateways, unknown estate, low tolerance for added latency | Blocking depends on integrations with the gateway or WAAP |
| API protection inside a WAAP | Mostly public APIs already behind a WAAP, strong need for inline blocking | Weaker visibility of internal east-west APIs and per-object behaviour |
Small organisations should weight pricing and services higher and may make runtime detection scored rather than mandatory. Large organisations with partner APIs should weight discovery, BOLA detection and data handling most heavily.
Common failure patterns
- Accepting a Top 10 mapping on paper: every bidder maps all ten risks. Only seeded tests show which are detected on your traffic.
- Testing discovery with an inventory supplied: if you give the bidder your specifications first, you test import, not discovery.
- Ignoring what leaves the network: full payloads stored in a vendor cloud by default can create a larger data exposure than the APIs being protected.
- Single-user tests: authorisation flaws need two identities. A platform tested with one account looks better than it is.
- Licence surprises: a per-endpoint price grows sharply once discovery finds the shadow estate you bought it to find. Model the price at discovered volume.
Lessons from incidents
In the T-Mobile API breach, records on about 37 million accounts were pulled through a single API for roughly six weeks before detection. The root cause was not confirmed publicly, which is why requirements API-RUN-01, API-RUN-05 and API-REP-01 focus on per-caller volume and object access baselines rather than on one known flaw.
Framework alignment
| RFP area | Reference |
|---|
| 4.1 Discovery and inventory | OWASP API9:2023; NIST CSF 2.0 ID.AM-02; NIST SP 800-53 CM-8 |
| 4.2 and 4.5 Posture and testing | NIST SP 800-228 pre-runtime controls; NIST SP 800-53 SA-11, RA-5; OWASP ASVS 5.0 as the requirement baseline |
| 4.3 and 4.4 Runtime detection and response | NIST SP 800-228 runtime controls; NIST SP 800-53 SI-4, SI-10, SC-7; NIST CSF 2.0 DE.CM-09; ATT&CK T1190, T1110.004 |
| 5 and 6 Data handling and platform security | NIST SP 800-53 AC-6, AU-2, SR-6; NIST CSF 2.0 GV.SC-06 |
Standards and references
Related NHI Mgmt Group resources: API Security Buyer's Guide · API Security Guide · Security Vendor Evaluation and RFP Guide · API Security Checklist · WAF and WAAP RFP Template