What a web application firewall does, and what it will not do

When a client asks us to make their site more secure, a web application firewall is often the first thing they have heard of and the first thing they want. That instinct is reasonable. A well-configured WAF in front of a site routinely stops the majority of hostile requests before they reach the application. But we also see WAFs deployed as a substitute for patching, left in log-only mode for years, or tuned so aggressively that they block checkout for real customers. Here is what a WAF is actually good at, where it falls short, and how we roll one out.

What a WAF is good at

A WAF inspects HTTP requests before they reach your origin server and blocks or challenges the ones that match known bad patterns. On the sites we manage, the bulk of blocked traffic falls into a few categories:

• Automated vulnerability scanning. Bots probing thousands of sites for known flaws in popular plugins, frameworks and admin panels.
• Common injection payloads. SQL injection, cross-site scripting and path traversal strings in query parameters and form fields.
• Credential stuffing and brute force. High volumes of login attempts from rotating IP addresses, handled through rate limiting and bot scoring.
• Virtual patching. When a vulnerability is disclosed in a component you use, managed rulesets often ship a rule within hours, buying time until you can apply the real fix.
• Layer 7 floods. Request floods aimed at expensive pages such as search or cart, absorbed at the edge rather than by your database.

A secondary benefit is performance and cost. On one content site, moving bot filtering to the edge cut origin requests by about 35 percent, which let us downsize the server.

What it will not do

A WAF sees requests, not intent, and it knows nothing about your business logic. It will not stop:

1. Authorization flaws. If a logged-in customer can view another customer's invoice by changing an ID in the URL, the request looks perfectly normal.
2. Attacks with valid credentials. A phished administrator password produces legitimate-looking sessions.
3. Vulnerabilities without a matching rule. Custom code has no managed ruleset, and novel exploits bypass signature matching.
4. Compromises that did not come over HTTP. Stolen SFTP credentials, a compromised CI pipeline or a malicious dependency all bypass the WAF entirely.
5. Anything, if the origin is reachable directly. If attackers can find and hit your server's IP address, the WAF is decoration.

A WAF buys you time and absorbs noise. It does not replace patching, access control or code review, and it should never be the reason you delay an update.

How we roll one out without breaking things

Lock down the origin first

Before any rule tuning, we make sure the origin only accepts traffic from the WAF or CDN. That means firewall rules on the server or load balancer allowing only the provider's published IP ranges, or authenticated origin pulls using a client certificate. We also check DNS history and mail headers, because old records often leak the origin IP.

Start in log mode, briefly

We enable managed rulesets in log-only mode for three to seven days and review what would have been blocked. The usual false positives are predictable: rich-text editors submitting HTML, page builders posting large JSON payloads, payment and shipping webhooks, and API clients with unusual user agents. Each gets a narrowly scoped exception, for example skipping one rule on one path for authenticated editors, rather than disabling the rule globally.

Switch to block, and keep reviewing

After the review period we switch to blocking. The failure mode we see most often is teams that never leave log mode because nobody owns the decision. We set a date at the start and stick to it. After that, a short weekly review of blocked requests and a monthly check of exceptions keeps things healthy.

Add targeted rules

Beyond managed rulesets, a handful of custom rules usually pay off:

• Rate limits on login, password reset, search and checkout endpoints.
• Challenges for admin paths from countries where the business has no staff, if that fits the organization.
• Blocks on requests for files that should never be served, such as .env, .git and backup archives.

TLS and headers belong in the same project

Since the WAF usually sits on the same edge that terminates TLS, we handle certificates and security headers at the same time. That means automatic certificate renewal with expiry monitoring, TLS 1.2 as the minimum, HSTS once every subdomain is confirmed to support HTTPS, and a baseline set of headers such as X-Content-Type-Options, a sensible Referrer-Policy and a Content Security Policy that starts in report-only mode. CSP deserves its own project on complex sites, but even a report-only policy tells you which third-party scripts are loading, which is useful for security and privacy reviews.

Choosing a provider

For most of our clients, a WAF bundled with a CDN is the right answer: simple to operate, reasonably priced and good at absorbing bot traffic. Cloud-provider WAFs make sense when the application already lives in that cloud and you want rules managed alongside infrastructure code. Host-level plugins are the weakest option, since they run inside the application they are protecting, but they can complement an edge WAF with application-aware checks.

Our SSL and firewall setup service covers the rollout described here, including origin lockdown and exception tuning. If you want to know what a WAF would and would not catch on your specific application, penetration testing answers that directly, and CDN configuration is often done in the same engagement.

Put a properly tuned firewall in front of your site

Tell us your platform, hosting and any integrations that post data to your site, and we will send a fixed-price quote for a WAF rollout that blocks attacks without blocking customers. Get your quote.