Technology
Web application firewalls and DDoS protection for agency websites
How state and local agencies evaluate WAF and DDoS protection for public websites, from monitor mode to contract terms.
Public agency websites are quiet for most of the year and then become the most visible thing the organization does. Election night results, a livestreamed council vote on a contested land use item, a utility rate increase, a boil water notice, a critical incident involving law enforcement: each draws a mix of genuine public interest, press attention, and people who would prefer the site not be reachable. Unlike most private sector targets, agencies can usually predict these moments from the public meeting calendar.
A web application firewall and denial of service mitigation are two different controls that are normally bought together. Denial of service mitigation keeps the site reachable when someone aims volume at it. A WAF inspects individual requests and blocks the ones that look like attacks on the application itself. The second control has a use agencies tend to discover late: when a vendor application has a disclosed flaw and no patch is available, a WAF rule is often the fastest thing you can put in front of it.
Know which kind of attack you are defending against
The word "DDoS" covers several problems with different answers.
- Volumetric floods. Raw bandwidth aimed at your address space to saturate the circuit. Nothing inside your building can fix a full pipe. Mitigation has to happen upstream, at your carrier or at a provider's distributed edge.
- Protocol and state exhaustion. Connection floods that exhaust the state tables in a firewall or load balancer. The device fails before the bandwidth does.
- Application layer floods. Requests that look legitimate but hit expensive paths: site search, document search, permit lookup, map tiles, agenda archives. These can succeed at modest volume.
- Exploit and abuse traffic. Injection attempts, credential stuffing against resident portals, and scraping. This runs constantly in the background and spikes after a public vulnerability advisory.
Edge service or on-premises appliance
A CDN or cloud-based edge service terminates connections across many locations, absorbs volume before it reaches your network, caches static content, and applies WAF rules at the edge. For a public-facing website this is usually the practical choice, because it is the only option that addresses circuit saturation.
An on-premises appliance inspects traffic after it arrives. That is useful for internal applications, for systems that cannot route through a third party for data handling reasons, and for teams that want full control of rule logic and log retention. It does not protect against a flood large enough to fill the connection.
Many agencies run both. If you use an edge service, close the loop: restrict your origin servers so they only accept traffic from the provider's networks. Otherwise an attacker who finds the origin address can bypass everything you paid for. Confirm that every hostname is covered, including subdomains, legacy sites, and separately hosted vendor portals that share your domain.
Run in monitor mode before you block anything
Turn the ruleset on in detection or logging mode first, and give it a real tuning window. Government traffic produces false positives that commercial defaults do not anticipate: long narrative submissions on planning and code enforcement forms, file attachments in public records requests, older browsers and assistive technology, automated tools used by title companies and news organizations, and internal county or state IP ranges that look like scanners.
Decide in advance who reviews the logs, how often, what the rollback procedure is, and who can authorize it at two in the morning. Move in stages: monitor everything, then block the high confidence rules, then widen. Do not flip a new ruleset into blocking mode during election week or the day before a major hearing.
Virtual patching and vendor applications
When a vendor discloses a flaw in a product you run, the patch may take weeks. A WAF rule that blocks the specific request pattern lets you keep the system online in the meantime. This is a compensating control, not a fix. Record it, track the underlying vulnerability to closure, and remove the rule when the patch lands so the ruleset does not accumulate years of undocumented exceptions.
This only works if you can get a custom rule written quickly. Some managed service tiers restrict customer-authored rules or route them through a change queue. Ask about that before you need it.
Protect APIs and form endpoints, not just the homepage
The homepage caches well and is rarely the weak point. The load and the risk sit elsewhere: login and password reset, payment callbacks, single sign-on endpoints, search, GIS and map tile services, open data APIs, mobile application backends, and every form that accepts a POST.
Build an inventory of these endpoints and apply protection per endpoint rather than site wide. Rate limiting on lookup and login paths, bot controls where credential stuffing is plausible, and request size and content type limits on upload forms do more than a generic ruleset. Prepare a static fallback page for results, closures, and emergency information that can be served from cache if the dynamic application has to be shed.
What to ask vendors and put in the contract
- Attack-time support. A named escalation path and a response commitment during an active incident, not a business hours ticket queue. Ask who answers on a Saturday.
- Emergency rule changes. Who can push a rule, through what channel, and how quickly. Get it in writing, and test the path during onboarding.
- Traffic and overage billing. Ask directly whether attack traffic counts toward committed bandwidth or triggers burst charges. Many providers exclude it, but that belongs in the agreement rather than in a sales conversation.
- Logs. Export format, retention period, and whether you can pull raw request logs into your own SIEM.
- Scope. Every hostname, subdomain, and vendor-hosted portal you expect to be covered, listed explicitly.
- Exit. Configuration and rule export, DNS cutover assistance, and what happens to your logs at termination.
Also confirm how the service will be purchased. Cooperative agreements and state master contracts often cover this category, and requirements for cloud service assessment programs vary by state and change over time, so verify current expectations with your procurement office and security leadership rather than assuming.
HQT works with state and local agencies on cybersecurity and infrastructure engineering, including web protection architecture and the requirements work that precedes it.
Frequently asked questions
Do we still need DDoS protection if our website is hosted by a vendor?
Usually yes, and you need to confirm what the vendor actually provides. Many content management vendors host on a cloud platform that includes basic network protections but not application layer filtering or an attack-time response commitment. Ask the vendor in writing which controls are included, whether a WAF is enabled, and who you call during an active attack. If the answers are thin, the agency may need its own edge service in front of the vendor site.
What is the difference between a CDN-based WAF and an on-premises appliance?
A CDN or cloud edge service filters traffic at distributed locations before it reaches your network, so it can absorb floods large enough to saturate your internet circuit. An on-premises appliance inspects traffic after it arrives at your data center, which gives you more control over rules and logs but cannot help once the circuit is full. Public-facing websites generally need the edge service; appliances are better suited to internal applications. Agencies often run both.
Will a web application firewall block legitimate residents?
It can, which is why you run the ruleset in monitor or detection mode first and tune it against your own traffic before enabling blocking. Government sites generate patterns that commercial default rules flag incorrectly, such as long form submissions, records request attachments, and older browsers or assistive technology. Plan a tuning period, assign someone to review the logs, and have a documented rollback procedure before any rule starts blocking.
Can a WAF substitute for patching a vendor application?
No, but it can buy time. A WAF rule that blocks the specific exploit pattern, sometimes called virtual patching, is a compensating control that lets a system stay online while the vendor prepares a fix. Document the rule and the underlying vulnerability, track the patch to completion, and remove the rule afterward so the ruleset does not fill up with undocumented exceptions.
How do we avoid surprise bandwidth charges during an attack?
Address it in the contract rather than at invoice time. Ask explicitly whether traffic identified as attack traffic counts toward committed bandwidth, triggers burst or overage rates, or is excluded from billing. Many established providers exclude it, but practices differ and verbal assurances are not enforceable. Have your procurement office confirm the billing language before award.