Attackers no longer stop at port scans; they chain together SQL injection, XSS, path traversal and bot farms that hit GraphQL endpoints.
Google Cloud Armor ships with a generous bundle of OWASP signatures — think of it as a Swiss army knife. Your job is to decide which blades stay out and which fold back.
Key dials you’ll turn along the way:
- Sensitivity (
0-4)—the higher the number, the wider the net. - opt_out_rule_ids / opt_in_rule_ids — surgical control over signatures.
- JSON parsing — teaches Armor to read structured bodies, not panic at curly braces.
- Request-field exclusions — tell Armor to ignore a cookie, header or query param that is noisy but harmless.
- Add a rule
evaluatePreconfiguredWaf('sqli-stable', { 'sensitivity': 2 })
2. Flip on preview mode so traffic is only logged, not blocked.
3. Read the logs. If a customer form is flagged, something is too aggressive.
4. Mute the culprit signature:
…, 'opt_out_rule_ids':['owasp-crs-…-id942360-sqli']
5. Disable preview and let the rule enforce.
That’s the entire feedback loop — fast and safe.
1. “Books-in-an-Hour” marketplace & noisy SQL flags
Background. Sellers upload book data as CSV; fields contain lots of quotes. Sensitivity 2 fires constantly.
Fix. Kept sensitivity at 2, but muted the lone signature that hates single quotes. Upload flow is happy, real injections still die.
2. A fintech API protected by GraphQL
Background. Requests arrive as JSON, sometimes 6–7 KB. Without JSON parsing, Armor mistakes braces for danger.
Fix.
gcloud compute security-policies update my-policy \
--json-parsing STANDARD_WITH_GRAPHQL
XSS rule on sensitivity 1 now ignores valid payloads yet spikes on genuine scripts.
3. Video platform and sneaky path-traversal attempts
Background. Users add subtitle files; a few try ../../etc/passwd.
Fix. Rule with sensitivity 0 plus two LFI signatures opted-in. Zero false alarms, full coverage of malicious paths.
4. Corporate portal vs. credential-stuffing bots
Background. Bots hammer /login.html with thousands of passwords a minute.
Fix, three steps.
- Allow only if
token.recaptcha_action.score≥ 0.8. - Everything below 0.8 gets a reCAPTCHA challenge.
- Exceed five failed tries in ten minutes? Rate-limit bans the IP for an hour.
Humans sign in, bots burn out.
Targeted field exclusions
Your app stores a JWT in X-Auth; the = signs upset a signature. Exclude that header and keep the rest of the rule alive:
gcloud compute security-policies rules add-preconfig-waf-exclusion 900 \
--security-policy my-policy \
--target-rule-set "sqli-stable" \
--request-header-to-exclude "op=EQUALS,val=X-Auth"
Composite keys for rate limiting
Need a limit per path + cookie site_id rather than just per IP?
--enforce-on-key-configs="HTTP-PATH,HTTP-COOKIE=site_id"
Each tenant on a multi-site service now has an isolated quota.
A well-tuned preconfigured WAF is not duct tape; it’s a living security layer that grows with your product. Start gentle, log everything, quiet the noisy parts, embrace JSON parsing, and combine reCAPTCHA with smart rate limiting — those two together silently save millions of requests while you sleep.
🙏 If you found this article helpful, give it a 👏 and hit Follow — it helps more people discover it.
🌱 Good ideas tend to spread. I truly appreciate it when readers pass them along.
📬 I also write more focused content on JavaScript, React, Python, DevOps, and more — no noise, just useful insights. Take a look if you’re curious.
Source Credit: https://medium.com/google-cloud/secure-your-apis-in-2025-with-cloud-armors-ready-made-waf-filters-398dfad996eb?source=rss—-e52cf94d98af—4
