What is a web application firewall (WAF)?

A web application firewall, or WAF, is a security control that inspects HTTP and HTTPS traffic before it reaches an application. Its job is to identify requests that are likely to be malicious, malformed, automated in harmful ways, or outside the policy the application owner expects. Depending on configuration, a WAF can log, block, challenge, rate-limit, or otherwise handle those requests.

A WAF is different from a traditional network firewall. A network firewall usually makes decisions using IP addresses, ports, protocols, and connection properties. A WAF works higher in the stack. It can evaluate URLs, methods, headers, cookies, query strings, request bodies, response codes, and application-specific context. That makes it useful for defending public websites, APIs, login flows, forms, checkout paths, content management systems, and administrative interfaces.

In DDoS planning, a WAF is not a replacement for volumetric mitigation. It is one layer in a broader defensive path, especially for application-layer attacks where request shape and route sensitivity matter.

What a WAF can inspect

WAF policies commonly look for exploit patterns, protocol violations, suspicious payloads, abusive request rates, unexpected methods, unusual headers, known bad automation, or requests to high-risk paths. Managed rule sets can cover common vulnerability classes, while custom rules can express local business expectations.

The local context is important. A request to a search endpoint, login page, cart action, or API mutation may be more expensive than a request for a cached image. The same traffic rate can be harmless on one route and damaging on another. A useful WAF policy understands which parts of the application are sensitive, which clients are expected, and which request shapes should never occur in normal use.

WAFs also produce evidence. Security teams can use matched rules, sampled requests, action outcomes, source networks, route distribution, and response codes to understand whether a spike is an exploit attempt, a bot campaign, a misconfigured integration, or real user demand.

How WAFs help during application-layer DDoS

Application-layer DDoS attacks try to consume expensive application resources through HTTP or API requests. The attack may focus on dynamic pages, login attempts, search, checkout, cache-bypass URLs, or API operations that trigger database work. Unlike simple bandwidth floods, these events can look like normal web traffic until the origin begins to slow down.

A WAF helps by enforcing policy at the request layer. It can block clearly invalid requests, challenge suspicious automation, apply route-specific rate controls, and protect known expensive endpoints. When combined with caching, bot detection, and origin shielding, WAF policy can reduce the amount of hostile or wasteful traffic that reaches the application.

The goal is not to block as much as possible. The goal is to preserve the clean path for legitimate users while suppressing requests that are invalid, abusive, or too risky to pass through during an incident.

Signals that a WAF policy needs attention

WAF tuning is an operational discipline. Warning signs include repeated false positives on legitimate users, high block rates with no matching incident context, attack traffic reaching the origin despite rule matches, or rules that are too broad to explain during an emergency. Another warning sign is a policy that only logs everything; visibility is useful, but it does not reduce risk unless response actions are defined.

During traffic spikes, teams should compare WAF actions with application health. Are protected routes seeing fewer origin requests? Are response times improving? Are block or challenge actions concentrated on the endpoints under pressure? Are legitimate users completing key journeys? These questions keep WAF evaluation tied to service resilience, not just rule counts.

False negatives matter as much as false positives. If logs show repeated expensive requests with no WAF action, the policy may lack route-specific thresholds, bot signals, schema validation, or rules for abnormal request structure.

Designing policy without breaking users

Effective WAF policy starts in observe mode. Teams should understand normal traffic patterns before moving high-impact rules directly into blocking. The observation period should include normal business cycles, known campaigns, partner integrations, search engine crawlers, mobile clients, and administrative workflows.

After baselines are understood, rules can be staged by risk. Low-confidence detections may log or challenge. High-confidence exploit attempts can be blocked. Expensive routes can receive stricter thresholds than static content. Authentication, session, and account context can help separate anonymous abuse from trusted traffic, but privacy and data minimization requirements should be respected.

Change management matters. A WAF rule can affect revenue, support workload, and customer access. Policies should have owners, test cases, rollback paths, and a way to review sampled requests. Emergency changes should be time-bounded and reviewed after the incident.

Common misconceptions

"A WAF stops all DDoS attacks" is not true. A WAF is strongest at the application layer. Large network floods may need upstream mitigation, traffic scrubbing, anycast capacity, or provider-level filtering before HTTP inspection is even possible.

"Managed rules are enough" is also incomplete. Managed rules are valuable for common patterns, but every application has unique routes, state changes, integrations, and business logic. Custom policy usually becomes necessary for high-risk workflows.

"More blocking always means better security" can create harm. Broad blocking may hide the incident briefly while preventing real users, partners, or monitoring systems from reaching the service. Good WAF operations balance protection with availability.

Evaluation checklist

A practical WAF review should answer several questions. Which public applications and APIs are covered? Which routes are considered high risk or high cost? Which rules are in log, challenge, or block mode? How are false positives reported and reviewed? Can responders see WAF actions beside origin health, cache status, bot signals, and rate-limit activity?

The review should also include resilience scenarios. If a login route receives a sudden distributed spike, what action is applied? If a known vulnerability is announced, how quickly can a rule be deployed and verified? If a partner integration is blocked, who can identify the rule and approve a fix?

WAF in a broader defense plan

Peakhour's WAF and WAAP controls form part of that application-security layer. Match rule changes to the routes, request bodies and user outcomes the application needs to protect.

A WAF works best as one part of layered application security. It should sit alongside secure development, patching, authentication hardening, bot management, API validation, rate controls, caching, monitoring, and incident response. For DDoS resilience, it should also be coordinated with network-level mitigation so high-volume traffic does not overwhelm the inspection point.

The strongest WAF programs are evidence-driven. They use rules to express clear security and availability expectations, measure whether those rules improve outcomes, and adjust policy as applications and attack patterns change.

Related learning

• What is Layer 7?
• What is a DDoS attack?
• What is a DDoS botnet?