Most attacks on websites are not handcrafted. They are automated scans, bots and scripts that probe millions of sites for the same known weaknesses: injectable forms, outdated plug-ins, exposed login pages and overloaded endpoints. A web application firewall (WAF) placed at the network edge, in front of your server, can stop the large majority of that traffic before it ever reaches your application.
You will often see the claim that up to 90 percent of common web attacks could be blocked this way. We could not trace that exact figure to a rigorous published study, so treat it as a vendor rule of thumb rather than a measured fact. The underlying point holds, though: because so much hostile traffic is automated and targets well-known flaws, an edge WAF is one of the most cost-effective controls a business can add. This article explains how it works, what it does and does not stop, and how to deploy it properly.
Why most web attacks are preventable
Automated traffic now dominates the web. Imperva’s 2025 Bad Bot Report found that automated traffic made up about 51 percent of all web traffic in 2024, surpassing human activity for the first time in a decade, with malicious bots alone accounting for roughly 37 percent. Much of that bad-bot traffic is doing predictable work: credential stuffing against login pages, scraping, vulnerability scanning and application-layer denial of service.
The attacks themselves are also well catalogued. The OWASP Top 10 lists the most common classes of web application weakness, including injection flaws such as SQL injection, cross-site scripting and broken access control. Because these patterns are known, they can be recognized and filtered, which is exactly what a WAF’s managed rule sets do.
How an edge WAF works (and where DNS fits)
What is often called a “DNS-level WAF” is more precisely a cloud-based reverse proxy that you enable through DNS. You point your domain’s DNS records to the provider, such as Cloudflare, Akamai, AWS or Imperva. From then on, visitors resolve your domain to the provider’s network rather than to your own server. Every request passes through the provider’s edge, where it is inspected, and only clean traffic is forwarded to your origin.
That position at the front door delivers several benefits at once:
- Attack surface reduction. Layer 7 DDoS floods, OWASP Top 10 exploit attempts and malicious bots are dropped at the edge, before they consume your server’s bandwidth, CPU and memory.
- Hidden origin. Attackers see the provider’s IP addresses, not yours, which makes direct attacks on your server harder.
- Better performance. Most edge WAFs sit on content delivery networks that cache static content close to users, so legitimate visitors often see faster load times while your server handles less load.
- Fast virtual patching. When a new vulnerability in a popular platform is disclosed, providers can push rules that block exploit attempts within hours, buying time until you patch.
We look at one widely used implementation in Why Cloudflare WAF Is Essential for Modern Web Security.
What an edge WAF does not stop
A WAF is a filter, not a cure. It is weakest against attacks that look like legitimate use. Business logic abuse, such as manipulating prices in a checkout flow, account takeover with valid stolen credentials, and flaws in how your application authorizes users, often pass through untouched. A WAF also does nothing about compromised admin accounts, vulnerable server software reachable by other paths, or malicious code already inside your site.
The most common deployment mistake is leaving the origin exposed. If attackers can find your server’s real IP address, through old DNS records, email headers or certificate logs, they can bypass the WAF entirely. The origin must be configured to accept web traffic only from the provider’s network. Finally, rules need tuning: overly aggressive settings block real customers, while unchanged defaults may miss attacks specific to your application.
Economics and compliance
The business case is straightforward. A successful web attack brings incident response costs, possible breach notification and regulatory exposure, downtime and lost sales, and damage to customer trust. Edge WAF services are typically priced as a subscription and are available at every tier, from free and low-cost plans suitable for small sites to enterprise contracts. Compared with the cost of an incident, that is one of the better returns in security spending.
Compliance points the same way. PCI DSS has long required protection for public-facing web applications handling card data; in version 4.0, Requirement 6.4.2, mandatory since March 31, 2025, calls for an automated technical solution, such as a WAF, that continually detects and prevents web-based attacks. HIPAA and SOC 2 do not name WAFs specifically, but a WAF supports the access control, integrity and monitoring safeguards those frameworks expect auditors to see.
Deploying an edge WAF properly
- Inventory your web properties. List every public site, API and subdomain, including marketing microsites and legacy portals.
- Route traffic through the provider. Update DNS so all public hostnames resolve to the WAF provider, and enable HTTPS end to end.
- Lock down the origin. Restrict inbound web traffic to the provider’s IP ranges or use an authenticated tunnel, and rotate any origin IPs that were previously public.
- Enable managed rules in log mode first. Watch what would be blocked for a short period, fix false positives, then switch to blocking.
- Add rate limiting and bot management. Protect login, search and checkout endpoints against credential stuffing and scraping.
- Keep patching and monitoring. Treat the WAF as a layer in front of good application security, not a replacement for it. Review WAF logs regularly and feed alerts into your security monitoring.
The trade-off is dependency on a third party that sees all your traffic, so choose a reputable provider and understand its data handling. Our cybersecurity and compliance services include WAF deployment, tuning and PCI DSS alignment. For the kind of large-scale automated attacks an edge WAF absorbs, see Next-Gen DDoS-as-a-Service: ShadowV2.
Frequently asked questions
Is a WAF the same as a network firewall?
No. A network firewall controls which ports and addresses can connect. A WAF inspects the content of web requests, such as form inputs, URLs and headers, to block application-layer attacks that a network firewall would allow through.
Does a small business website need a WAF?
Usually yes. Automated attacks do not discriminate by size, and small sites running common platforms such as WordPress are frequent targets. Entry-level edge WAF plans are inexpensive and quick to set up.
Will a WAF slow down our website?
Typically not. Inspection adds very little delay, and because most edge WAFs are part of a content delivery network, caching often makes sites faster overall for legitimate visitors.
Securing your front door
Delana Technologies helps organizations deploy and tune edge WAFs, lock down origin servers and align web security with PCI DSS and other frameworks, so the bulk of automated attacks never reach your application. To review your web security, call 239.414.5126 or contact us.
Sources: Imperva, 2025 Bad Bot Report (April 2025); OWASP Top 10 (2021); PCI Security Standards Council, PCI DSS v4.0 Requirements 6.4.1 and 6.4.2; provider documentation from Cloudflare, Akamai and AWS on WAF deployment and origin protection.