Cloud Armor WAF & Rate-Limit Policy Review Prompt
Harden a Cloud Armor security policy — WAF rules, rate limiting, and bot defense — by reasoning from rule order, preconfigured-rule sensitivity, and preview-mode evidence instead of pasting in a blanket deny.
- Target user
- Platform, security, and SRE engineers fronting GCP load balancers with Cloud Armor
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior security engineer who has run Cloud Armor in front of production load balancers without locking out real users. You reason from rule evaluation order and preview-mode logs, and you know the preconfigured WAF rules (OWASP CRS) are powerful but noisy — so you tune sensitivity rather than enabling everything at max strictness on day one. I will provide: - The current policy: [`gcloud compute security-policies describe POLICY --format=yaml` — rules with priorities, match expressions, actions, rate-limit configs, adaptive protection] - The threat or goal: [BLOCK SQLi/XSS / RATE-LIMIT ABUSE / GEO-RESTRICT / STOP A BOT FLOOD / PASS A PENTEST FINDING] - Traffic context: [legitimate client IPs/regions, expected request rate, whether there's a CDN/proxy in front affecting the source IP] - Any preview-mode log evidence: [requests that matched rules in preview] Your job: 1. **Read the rule order** — Cloud Armor evaluates by priority (lower number first) and the first match wins. Walk the priorities and flag any rule that's shadowed by an earlier one or any allow that sits above a deny it was meant to catch. 2. **WAF sensitivity, tuned not maxed** — for preconfigured OWASP rules (sqli, xss, lfi, rce), recommend a sensitivity level appropriate to the app and propose enabling them in **preview mode first** so we measure false positives before enforcing. Identify likely false-positive sources (e.g., legitimate SQL-like strings in a search box). 3. **Rate limiting** — design a `rate_based_ban` or `throttle` keyed on the right dimension (IP, header, or XFF when behind a CDN), with a threshold derived from expected legitimate rate, an enforce-on-key that won't punish shared NAT users, and a ban duration. Note the trusted-proxy / `userIpRequestHeaders` config if a CDN sits in front, or the rate limit will key on the proxy. 4. **Adaptive Protection & bots** — recommend whether to enable Adaptive Protection for L7 DDoS and how to handle its alerts, plus reCAPTCHA/bot rules where appropriate. 5. **Rollout plan** — preview mode, then a canary enforce on a fraction, then full enforce, with the log query to watch matched/blocked counts at each stage. Output: (a) an ordered rule table with priorities and a note on any shadowing, (b) the specific rule definitions (gcloud commands), (c) the rate-limit config with the threshold rationale, (d) the preview-to-enforce rollout steps, (e) the log query to validate. Default every new blocking rule to preview mode first. Never recommend a broad deny or a strict WAF sensitivity going straight to enforce without a preview measurement — flag the false-positive risk for me to confirm.
Why this prompt works
Cloud Armor is unforgiving in a specific way: rules evaluate strictly by priority and the first match wins, so a single misordered deny can black-hole all production traffic in one command. This prompt makes rule-order analysis the first step, surfacing shadowed rules and allows that sit above the denies they were meant to enforce. That structural read catches the class of mistake that no amount of clever rule content can fix.
The prompt encodes the hard-won discipline of tuning rather than maxing. The preconfigured OWASP rules are genuinely useful but noisy, and engineers who flip them all to max sensitivity in enforce mode end up blocking legitimate users whose input happens to look like SQL. By defaulting every blocking rule and WAF enablement to preview mode first, the prompt turns a guess into a measurement: you see exactly what would have been blocked before anything actually is. The rate-limiting step carries the same realism, forcing the model to account for the CDN-in-front case where keying on the wrong IP either bans everyone or no one.
The guardrails reflect the two ways Cloud Armor changes cause outages: a broad or misordered deny, and a rate limit that keys on a proxy IP. Both are flagged for human confirmation, and the rollout plan — preview, canary enforce, full enforce — means the engineer always has evidence before committing. The result is a hardening plan you can actually ship to a live edge without taking the site down to test it.