WAF (web application firewall)
A filter in front of your app that reads every HTTP request and drops the ones that look like attacks before your code sees them.
See it
What it is
A WAF sits between the internet and your app, usually as a reverse proxy at the edge, and inspects each HTTP request: URL, headers, cookies, body. Requests that match attack signatures (an 'OR 1=1' in a query string, a script tag in a form field, a '../../etc/passwd' path) get blocked, challenged, or logged before your code runs. The canonical open ruleset is the OWASP Core Rule Set, the default brain of self-hosted ModSecurity and Coraza. Managed products vary: some offer CRS or a CRS-derived ruleset, others ship their own proprietary managed rules, so check what Cloudflare, AWS WAF, Fastly, or Azure Front Door actually gives you rather than assuming CRS underneath.
Reach for one when you want virtual patching (a known CVE in a dependency you cannot upgrade until Friday, blocked at the edge today), when you need a fast lever during an active attack, or when compliance asks for one by name. Most WAF products also carry rate limiting, bot rules, and geo blocking in the same box, which is usually the real reason teams turn one on.
The gotcha is false positives. Generic rules do not know that your CMS legitimately posts HTML, or that your support form contains the word 'select', and a blocked customer never files a bug report. Always start in count or log-only mode, watch a week of real traffic, then tune before enforcing. And a WAF is not a fix: it is a filter in front of the bug, attackers get through with encoding and chunking tricks, and it sees nothing at all if traffic can reach your origin directly, so lock the origin to the proxy's IPs.
Ask AI for it
Put a web application firewall in front of this app. First read the deployment config to work out which edge provider we are actually on (Cloudflare, AWS WAF, Fastly, Azure Front Door, or a self-hosted ModSecurity or Coraza) and which routes matter: admin surfaces, auth endpoints, and anything that legitimately accepts HTML. Then write provider-specific rules in that provider's own syntax, all in count or log-only mode so I can review matches before enforcing. Enable whatever managed baseline ruleset that provider offers, and name it rather than assuming it is the OWASP Core Rule Set. Add: an IP restriction on the admin surface, a rate limit on the login route, and a challenge for traffic with obviously scripted headers. Where the repo gives you no evidence for a value, leave an explicit [ADMIN_CIDRS] or [RICH_TEXT_ROUTE] placeholder instead of inventing one. Keep every false-positive exclusion scoped to a specific rule ID and a specific parameter, never a blanket path exemption. Finally, lock the origin so it only accepts traffic from that provider's published and verified proxy ranges, and show me the config for both the WAF rules and the origin firewall.