Most WAF tenders are decided by a demo that blocks a textbook SQL injection, and then fail in production because legitimate customers get blocked, APIs go unprotected and nobody owns rule tuning. This template is a ready-to-issue request for proposal for a web application firewall (WAF) or the broader web application and API protection (WAAP) category: rule engine and tuning, API schema enforcement, bot and abuse controls, layer 7 denial of service, virtual patching, client-side script protection, logging, platform security and commercials. Every requirement has an ID, a type and a proof of concept test. It is vendor-neutral and written for application security, network and platform teams, procurement and evaluation panels. For the market, deployment models and capability areas, read the WAF and WAAP Buyer's Guide first.
How to use this template
- Replace text in square brackets, such as [Organisation], [number of applications] and [CDN or load balancer in use], with your own details. Delete requirements that do not apply.
- Each requirement has an ID (for example WAF-RUL-03) and a type: M mandatory (pass or fail), S scored (0 to 5, then weighted) or I informational.
- 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 panel only.
- If you are buying a dedicated API security platform as well, align section 4.3 with the API Security RFP Template. If network-layer scrubbing is a separate purchase, see the DDoS Protection Buyer's Guide.
1. Purpose and scope
[Organisation] invites proposals for a [WAF or WAAP] service or product, implementation services, optional managed rule tuning and support for a term of [three] years. The solution must protect [number] public-facing web applications and [number] APIs across [domains] against web attacks, API abuse, automated threats and application-layer denial of service, with tuning that keeps false positives within agreed limits. Deployment: [cloud-delivered reverse proxy, cloud-native WAF attached to load balancers and API gateways, virtual appliance, or software engine in Kubernetes ingress], or a combination the bidder proposes and justifies. Out of scope: [network firewalls, origin hosting, content delivery unless bundled and separately priced].
2. Organisation background and current state
- Applications: [number] browser applications, [number] public APIs, [number] partner APIs, [number] mobile back ends; [percentage] with OpenAPI descriptions.
- Traffic: normal peak [requests per second], largest observed attack [requests per second], monthly volume [requests or bandwidth].
- Hosting: [cloud providers, data centres, Kubernetes clusters], TLS termination points [list], certificate management [process].
- Current protection: [existing WAF type and mode, for example monitor only], bot management [yes or no], DDoS protection [type].
- Compliance: [for example PCI DSS v4.0.1 cardholder data environment applications, sector regulators].
- Operations: SIEM [type], SOAR [type], infrastructure as code [tooling], change process [summary], team that will tune rules [team and size].
3. Instructions to bidders
- Answer every requirement with Comply, Partially comply (explain) or Does not comply, plus how it is met and whether it is generally available, in beta or on the roadmap. Roadmap and beta items score zero.
- State which deployment model each answer applies to. Where capabilities differ between models, say so per requirement.
- Identify requirements met through add-on modules, a partner or managed services, and price them in section 8.
- State where TLS is terminated, where private keys are held and which logs and request data leave [Organisation]'s environment, with hosting regions and sub-processors.
- Provide [three] references of similar traffic and application mix.
- Submit clarification questions by [date]. Responses are due by [date] in the response workbook provided.
4. Functional requirements
4.1 Rule engine and detection
| ID | Requirement | Type |
|---|---|---|
| WAF-RUL-01 | Provides managed rules for injection, cross-site scripting, path traversal, remote file inclusion, protocol violations and other OWASP Top 10 web risk classes, updated by the bidder; state the update process and notice given before new rules block. | M |
| WAF-RUL-02 | Uses anomaly or confidence scoring so a request is blocked on accumulated evidence, with thresholds configurable per application and per path. | S |
| WAF-RUL-03 | Offers graded rule sensitivity levels and can run a stricter level in log-only mode alongside the blocking level, to measure the effect before change. | S |
| WAF-RUL-04 | Supports custom rules on any request element (method, path, header, cookie, argument, body field, client identity, geography) with a documented rule language. | M |
| WAF-RUL-05 | Inspects request bodies in JSON, XML, multipart and URL-encoded formats; state body size limits and the action taken on bodies above the limit. | M |
| WAF-RUL-06 | Optionally inspects responses for data leakage (for example error messages, stack traces, card numbers) with redaction in logs. | I |
4.2 Tuning and false positive management
| ID | Requirement | Type |
|---|---|---|
| WAF-TUN-01 | Allows exclusions scoped to rule, parameter, path, method and application, never only global; every exclusion is versioned, attributed and commented. | M |
| WAF-TUN-02 | Supports per-rule and per-application log-only mode, staged rollout and one-step rollback of policy versions. | M |
| WAF-TUN-03 | Suggests exclusions from observed false positives for human approval, never applying them automatically without approval. | S |
| WAF-TUN-04 | Manages policies as code through an API and [infrastructure as code tooling], so changes pass [Organisation]'s review and CI/CD. | S |
4.3 API protection
| ID | Requirement | Type |
|---|---|---|
| WAF-API-01 | Imports OpenAPI descriptions (state versions supported) and enforces them: undeclared endpoints, methods, parameters, types and content types are logged or blocked. | M |
| WAF-API-02 | Discovers API endpoints from traffic and flags those missing from the imported descriptions (OWASP API9:2023 Improper Inventory Management). | S |
| WAF-API-03 | Detects object identifier enumeration and abuse of defined business flows per authenticated client (API1:2023, API6:2023); describe the method and its limits. | S |
| WAF-API-04 | Validates JSON Web Tokens (signature, issuer, audience, expiry) at the edge where configured, and rate limits per token or client identifier. | S |
| WAF-API-05 | Applies GraphQL protections such as query depth, complexity and introspection controls. | I |
4.4 Bots, rate limiting and denial of service
| ID | Requirement | Type |
|---|---|---|
| WAF-BOT-01 | Classifies automated clients and applies actions (allow, challenge, rate limit, block) by behaviour, with known good bots allowed by verified identity, not user agent alone. | S |
| WAF-BOT-02 | Protects login, registration, password reset and checkout against credential stuffing (ATT&CK T1110.004) and scripted abuse without breaking accessibility requirements. | M |
| WAF-BOT-03 | Applies rate limits per client, route, token and session, with burst and sustained thresholds. | M |
| WAF-BOT-04 | Mitigates application-layer floods (ATT&CK T1499.003 Application Exhaustion Flood); for cloud-delivered models, state network-layer mitigation capacity (T1498) and any attack traffic charges. | M |
See the Bot Management Guide and the Credential Stuffing Attack Response Playbook.
4.5 Virtual patching and client-side protection
| ID | Requirement | Type |
|---|---|---|
| WAF-VPT-01 | Publishes managed rules for newly exploited vulnerabilities in common platforms; state typical time from public disclosure to rule availability and how customers are notified. | S |
| WAF-VPT-02 | Lets [Organisation] write and deploy a custom virtual patch in log-only mode within [one hour], then promote it to blocking. | M |
| WAF-CSP-01 | Inventories scripts loaded on [payment pages], detects unauthorised changes and supports authorisation and integrity evidence for PCI DSS v4.0.1 requirement 6.4.3. | S |
4.6 Logging and integration
| ID | Requirement | Type |
|---|---|---|
| WAF-LOG-01 | Logs every blocked and flagged request with rule IDs, anomaly score, matched data, client identity, application and policy version; redacts [named sensitive fields]. | M |
| WAF-LOG-02 | Streams logs to [SIEM] in a documented schema within [60 seconds]; state retention in the bidder's console. | M |
| WAF-LOG-03 | Provides dashboards and an API for blocked requests per application, false positive reports, rule hits and top attack sources. | S |
| WAF-LOG-04 | Triggers [SOAR] playbooks or webhooks on defined events, such as a new attack campaign or a threshold breach. | I |
5. Compliance requirements
- WAF-CMP-01 (M): for in-scope cardholder data environment applications, the solution supports [Organisation]'s compliance with PCI DSS v4.0.1 requirement 6.4.2: an automated technical solution in front of public-facing web applications that detects and prevents web-based attacks, is configured to block or alert, generates audit logs and is kept up to date. The bidder states which evidence it provides to an assessor. See the PCI DSS 4.0 Guide and the PCI DSS for E-commerce Payment Page Scripts Guide.
- WAF-CMP-02 (S): provides reports mapping protection to the OWASP Top 10 web risks and OWASP API Security Top 10 2023 for audit and customer questionnaires.
- WAF-CMP-03 (M): hosts logs and request data in [regions] and signs a data processing agreement meeting [GDPR Art. 28 or applicable law].
6. Security of the WAF or WAAP platform
A WAF terminates TLS, holds private keys, sees every request including credentials, and in cloud deployments runs under a cloud role. It is a privileged non-human identity and a high-value target.
| ID | Requirement | Type |
|---|---|---|
| WAF-SEC-01 | Describes TLS private key custody: where keys are stored, who at the bidder can access them, hardware protection used, and support for customer-held or keyless key options. | M |
| WAF-SEC-02 | Supports SSO with SAML or OIDC, enforced MFA and role-based administration separating policy authors, approvers and read-only analysts. | M |
| WAF-SEC-03 | For cloud-native and self-hosted deployments, documents the minimum cloud permissions the WAF needs and confirms it needs no access to application data stores. | M |
| WAF-SEC-04 | Provides a customer-visible audit log of administrative changes and API calls, exportable to [SIEM]; API credentials are scoped and rotatable. | M |
| WAF-SEC-05 | Provides current independent assurance (for example a SOC 2 Type II report or ISO/IEC 27001 certificate), vulnerability disclosure arrangements and incident notification within [hours]. | S |
See the Leaked TLS Private Key Response for what to plan if custody fails.
7. Implementation, services and support
- WAF-SVC-01 (M): an onboarding plan moving [tier 1 applications] from log-only to blocking within [90 days], with a false positive target agreed per application.
- WAF-SVC-02 (S): optional managed tuning service: scope, response times for false positive requests, and who approves changes.
- WAF-SVC-03 (M): 24x7 support for attacks in progress, with response times by severity and an emergency contact route.
- WAF-SVC-04 (M): data plane availability commitment of [99.99%] and service credits; state the behaviour if the service fails (fail-open or fail-closed) and how [Organisation] can bypass it.
8. Pricing schedule
| Line | What the bidder must state |
|---|---|
| WAF-COM-01 Licence metric (M) | Unit (requests, bandwidth, applications, domains, instances or cores) and how it is counted, including attack traffic and blocked requests. |
| WAF-COM-02 Subscription (M) | Price for years 1 to [3] at current volume and at [150%] growth, every module (bots, API, client-side, DDoS) itemised. |
| WAF-COM-03 Attack costs (M) | Any charge, cap or throttling during a denial of service event. |
| WAF-COM-04 Services (M) | Onboarding, managed tuning and training with day rates or fixed fees. |
| WAF-COM-05 Exit (S) | Export of policies, custom rules and logs in documented formats at no cost. |
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 to 5 and multiplied by the area weight.
| Area | Illustrative weight |
|---|---|
| Detection on [Organisation]'s applications (4.1, 4.5) | [20%] |
| False positives and operability (4.2) | [20%] |
| API protection (4.3) | [15%] |
| Bots, rate limiting and DoS (4.4) | [10%] |
| Logging, compliance and platform security (4.6, 5, 6) | [15%] |
| Services and pricing (7, 8) | [20%] |
Proof of concept script, run in front of [named applications] in a mirrored or staged environment over [three to four weeks], with written approval for every test:
- Shadow period: run the default policy in log-only mode on real traffic for [seven] days and count legitimate requests that would have been blocked per 10,000.
- Tuning effort: record panel and bidder hours to bring false positives under [target], and check that every exclusion is narrowly scoped.
- Detection replay: replay findings from [Organisation]'s recent DAST scans and penetration tests through the candidate in blocking mode and record what is stopped.
- Schema enforcement: import an OpenAPI description, then send requests with an undeclared endpoint, extra parameter and wrong type.
- Virtual patch: the panel describes a hypothetical flaw; the bidder deploys a custom rule in log-only mode, then blocking, against a test endpoint, timed.
- Bot and rate limit: run a controlled, approved login replay and a modest layer 7 load test against a test endpoint.
- Logging: confirm fields, redaction and delivery latency in [SIEM].
- Rollback: revert a policy version and time it.
Implementation guidance
This section is for the evaluation panel and is not issued to bidders.
Before you issue
- Inventory what is exposed: list domains, applications and APIs, which handle card data and which have OpenAPI descriptions. Applications missing from this list will be missing from the policy.
- Decide the operating model: your team, a managed service or a partner tunes rules. This changes the weighting of WAF-TUN and WAF-SVC-02 more than any detection feature.
- Collect replay material: recent DAST and penetration test findings and a sample of legitimate traffic that is known to trip generic rules (rich text editors, search fields, file uploads).
- Agree key custody: security and legal should decide whether a third party may hold TLS private keys before bidders answer WAF-SEC-01.
Choosing between approaches
| Approach | Fits when | Trade-off |
|---|---|---|
| Cloud-delivered reverse proxy WAAP | Many internet-facing applications, need for DDoS capacity and bot controls | DNS changes, third-party TLS termination, origin must be locked to the provider |
| Cloud-native WAF on load balancers and gateways | Workloads in one cloud, policies managed as code | Feature depth varies; multi-cloud estates need several policy sets |
| Open source rule engine with a community rule set in ingress | Strong in-house engineering, data must stay on premises | You own tuning, updates, scale and support |
A useful neutral reference for scoring behaviour is the OWASP Core Rule Set: each matching rule adds to an anomaly score (5 critical, 4 error, 3 warning, 2 notice), the default inbound blocking threshold is 5 and outbound is 4, and four paranoia levels trade detection for false positives. Use it to frame questions, not as a requirement that bidders use it. Small organisations without tuning staff should weight managed rules and managed service quality higher; large estates should weight API schema enforcement and policy as code.
Common failure patterns
- Scoring the demo: blocking a known payload on a sample site proves nothing about false positives on your forms and APIs.
- Staying in monitor mode: without a dated plan and owner to move to blocking, the WAF becomes a logging tool. WAF-SVC-01 exists to prevent this.
- Global exclusions: disabling a rule everywhere to fix one form removes protection from every application.
- Origin left open: a cloud-delivered WAF can be bypassed if the origin still accepts traffic from the internet. Require origin lock-down in onboarding.
- Over-privileged WAF identity: a WAF role that can read data stores turns a WAF flaw into a data breach.
Lessons from incidents
The Capital One breach began with a misconfigured web application firewall: the attacker obtained temporary credentials for the cloud role the firewall ran as, and that role could read far more storage than a firewall needs. Requirements WAF-SEC-03 and the over-privileged identity failure pattern come directly from that lesson.
Framework alignment
| RFP area | Reference |
|---|---|
| 4.1 and 4.5 Detection and virtual patching | NIST SP 800-53 SC-7, SI-10, SI-4; NIST CSF 2.0 PR.IR-01; ATT&CK T1190; PCI DSS v4.0.1 requirement 6.4.2 |
| 4.3 API protection | OWASP API Security Top 10 2023; NIST SP 800-228 runtime controls |
| 4.4 Bots and DoS | ATT&CK T1110.004, T1499.003, T1498 |
| 4.6 Logging | NIST SP 800-53 AU-2; NIST CSF 2.0 DE.CM-09 |
| 6 Platform security | NIST SP 800-53 AC-6, SR-6; NIST CSF 2.0 GV.SC-06 |
Standards and references
- OWASP: Top 10 Web Application Security Risks
- OWASP: API Security Top 10 2023
- OWASP Core Rule Set: Anomaly Scoring
- OWASP Core Rule Set: Paranoia Levels
- PCI Security Standards Council: PCI DSS Document Library
- NIST: SP 800-228 Guidelines for API Protection for Cloud-Native Systems
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: WAF and WAAP Buyer's Guide · API Security RFP Template · Security Vendor Evaluation and RFP Guide · Bot Management Buyer's Guide · DDoS Protection Guide