WAF versus a network firewall
A network firewall decides which connections may reach a server, usually by IP address and port. It lets web traffic on ports 80 and 443 through, because that is the point of a website. A WAF looks inside those web requests: the URL, query string, headers and sometimes the body, and decides whether each request is safe to pass to your application.
Three places a WAF can run
At the edge (cloud or reverse-proxy WAF)
You point your domain's DNS at the WAF provider. Visitors connect to the provider, which filters requests and forwards clean ones to your server (the origin). Attacks are stopped before they use your server's resources, and the same network can cache static files and absorb traffic floods. The trade-off: traffic passes through a third party, and if attackers find your origin's real IP address they can bypass the WAF unless the origin only accepts traffic from it.
On the server (host or module WAF)
A module in the web server, such as ModSecurity with the OWASP Core Rule Set, inspects requests on your own machine. You keep full control, but it uses your server's resources and needs someone to tune and maintain it.
Inside the application (plugin or endpoint WAF)
A CMS plugin inspects requests as the application starts handling them. It understands the application, for example which WordPress user is logged in, but it runs only after the request has reached your server and PHP has started.
These are not mutually exclusive. An edge WAF plus login protection inside the CMS is a common, sensible combination.
What a WAF typically blocks
- Common injection patterns: SQL injection, cross-site scripting (XSS), path traversal and command injection attempts.
- Requests for sensitive files such as
.env,.gitor database backups. - Password guessing, through rate limits on login pages.
- Abusive bots and vulnerability scanners, by behaviour or known signatures.
- Traffic you choose to block: specific IP ranges, countries or paths.
- Floods of requests, by challenging or rate-limiting visitors.
- Some providers also ship "virtual patches": rules that block exploitation of a specific known vulnerability before you have updated.
What a WAF cannot do
- Fix vulnerable code. It can make exploitation harder; the fix is still the update.
- Stop attacks that look like normal use: a stolen password, a business logic flaw, an abused coupon code.
- Clean a site that is already infected. A backdoor already on the server does not need to pass the WAF again in an obvious way.
- Protect traffic that bypasses it, such as requests sent straight to the origin IP.
- Catch everything. Signature rules can be evaded, and tighter rules mean more false positives.
Rolling out a WAF without breaking your site
- Start in a log-only or monitor mode, so rules record what they would block without blocking it.
- Watch the log for a few days. Look for legitimate requests that would be blocked: payment provider callbacks, page builder saves, API clients.
- Add exceptions for those specific paths or rules, rather than turning protection off globally.
- Switch to enforcement, and keep an eye on the log and your support inbox for the first week.
- Lock down the origin so it only accepts traffic from the WAF, where your hosting allows it, and check that your origin IP is not leaked in DNS records such as mail or FTP hostnames.
How Webforta Shield works
Webforta Shield is an edge, reverse-proxy WAF built on Cloudflare for SaaS, included in Pro and Business. You connect a verified website, add the DNS records Shield shows, and it starts in monitor mode. You do not need a Cloudflare account of your own. It offers IP, CIDR and country rules, path rules, per-IP rate limiting, login brute-force protection, WordPress-specific protections (XML-RPC, login check, user enumeration), sensitive-file protection, edge security headers, caching and an under attack mode that puts a short browser check in front of every page visit.
To be clear about its limits: Shield's managed attack filter is a small, conservative signature set applied to the decoded URL and query string. It does not inspect request bodies, and its browser check is a proof-of-work check, not a CAPTCHA. For Shield websites, Webforta Scan also checks public DNS for records that reveal your origin's address.