WAF Functionality: What a Web Application Firewall Does and Does Not Do

A web application firewall inspects HTTP and HTTPS requests before they reach your application and blocks the ones that match known attack patterns, covering things like SQL injection, cross-site scripting, abusive bots and traffic floods, and it does that by rules, not by understanding your code.

A WAF is a useful layer and a poor substitute for secure code. The way to use one well is to know exactly what it can see.

What a WAF sits in front of
How the inspection works
The functions you get
False positives and tuning
What a WAF will not do
Where hosting fits in
Logging and incident response
How this fits the rest of the stack
FAQ

What a WAF sits in front of

A traditional network firewall decides which connections may reach which ports. It understands addresses and protocols but not the contents of a web request. A web application firewall works one level higher, at the application layer. It reads the HTTP request: the path, the query string, the headers, the cookies and the body, and decides whether it looks legitimate.

It sits in front of your application, as a reverse proxy, a cloud service in front of your domain, a module inside your web server or an appliance in your network. Traffic passes through it, gets inspected and is either forwarded, challenged or dropped.

The vendors’ glossary pages describe the same picture: filtering and monitoring HTTP traffic between an application and the internet, defending the application layer, and in some designs also inspecting responses to stop sensitive data leaving. The usual shorthand for what it defends against is the list of common web attack classes.

It is important to see what it is not. It does not fix a vulnerable application. It is a shield that blocks known-bad patterns. If your code has a flaw the WAF’s rules do not recognise, the request passes straight through. Think of it as one layer in defence in depth, not the defence.

The existing posts on firewalls in cloud computing and the OWASP firewall rules cover the surrounding ideas.

How the inspection works

WAFs make a decision for each request in a few common ways.

Signature and rule matching. The core approach. A rule is a pattern, such as a regular expression that matches typical SQL injection syntax in a parameter. Rule sets maintained by the community cover the most common attack classes, and vendors maintain proprietary sets on top.

Anomaly scoring. Instead of blocking on one match, each suspicious element adds to a score. When the total crosses a threshold, the request is blocked. This reduces false positives because a single odd character does not block a legitimate user.

Positive security models. Instead of listing what is bad, the WAF is told what is good: these paths, these parameters, these value formats. Everything else is rejected. Strong and laborious to maintain, so it is mostly used for high-value endpoints.

Reputation and behaviour. Blocking by source address reputation, known bad automation fingerprints and request rates.

Most deployments combine them: a managed rule set for broad coverage, custom rules for your application, and rate limits for abusive patterns.

A WAF runs in modes. Detection mode logs what it would block without blocking. Prevention mode blocks. Always start in detection mode, review what it flags and only then switch to prevention.

The functions you get

The feature list is longer than it first appears, and each item addresses a specific problem.

Injection protection. Blocks SQL, command and similar injection patterns in request data.
Cross-site scripting protection. Blocks script content in places where it should not appear.
Rate limiting. Caps requests per client per time window, which slows credential stuffing and scraping and blunts small floods.
Bot management. Distinguishes people from automation, with challenges for suspicious clients and allowlists for the good crawlers.
Geo and IP controls. Allow or deny by country or address range.
Virtual patching. A temporary rule that blocks exploitation of a known vulnerability while you fix the code, which buys time after a disclosure.
File upload and size limits. Rejects oversized or dangerous uploads.
Protocol enforcement. Rejects malformed requests and unexpected methods.
API protection. Validates schemas, tokens and request shapes for API traffic, including GraphQL and JSON.
Logging and alerting. A record of what was blocked and why, which is useful for investigation and tuning.

Layer seven denial of service defence overlaps here. Volumetric floods are usually absorbed upstream by network-level protection, while a WAF handles expensive-request floods aimed at your application, such as hammering a search endpoint.

False positives and tuning

The usual complaint about a WAF is that it blocks legitimate users. A rule written to catch injection can trigger on a real comment containing SQL-looking text, a rich text editor’s HTML or an API payload with unusual characters.

The remedy is tuning, and it is ongoing work.

Start in detection mode and collect logs for a week or two.
Group the flagged requests by rule. Identify which are real attacks and which are legitimate.
For legitimate patterns, write exceptions scoped as narrowly as possible: this rule, this path, this parameter.
Switch to prevention gradually, perhaps starting with the most reliable rule categories.
Keep monitoring after changes, since application updates bring new request shapes.

The symptom of an unexpected block is often a generic error page for a form submission or an admin action. If a vendor or hosting error says a transfer triggered a firewall, the matching rule is in the log. The post on the transfer has triggered a web application firewall explains how to read that message.

Do not disable a whole rule category because one rule misfired. An exception for one parameter is cheap, and a disabled category is a hole.

What a WAF will not do

Knowing the limits prevents false confidence.

It will not fix logic flaws. A broken access check that lets user A read user B’s data is a valid request in the WAF’s eyes.
It will not stop stolen credentials. A login with a correct password looks like a normal login.
It will not secure the origin if the origin is reachable directly. If attackers can reach your server’s address, they can skip the WAF. Restrict the origin to accept traffic only from the proxy.
It cannot inspect what it cannot decrypt. It must terminate TLS to read the traffic, so certificates and key handling become part of the design.
It adds latency and a point of failure. Usually small, still real.
It does not replace patching and secure coding. Virtual patching buys time, and it is not a cure.

The best security programme treats the WAF as a net under good practices: parameterised queries, output encoding, least-privilege access, dependency updates and tested backups. When something does slip past, the logs from the WAF and your own application are what let you understand it.

Test your own setup. Run a scanner against a staging copy and see what is blocked, and check that blocked requests are logged where you will look.

Where hosting fits in

Some of the benefits people seek from a WAF are really properties of a well-configured platform: TLS everywhere, databases on private networks, no direct access to internals and sensible limits.

On RunxBuild, services and static sites get custom domains with certificates handled, managed databases are reachable over private networking so they are not exposed to the open internet, and you can add application-level protections such as rate limiting in your own code. RunxBuild does not provide a configurable WAF product, so if you need managed rule sets and bot management, you would place a WAF service in front of your domain. The database network security docs describe how database access is restricted.

A practical layered plan for a small team: keep dependencies patched, use parameterised queries, put the database on a private network, add rate limits on login and API routes, and consider a WAF in front for rules and bot filtering as the site becomes a target.

Logging and incident response

Treat WAF logs as evidence, not noise. Ship them somewhere you will actually look, keep them long enough to investigate an incident from last month and include the rule that fired, the request path and the source address. A spike in blocked requests against one endpoint tells you what attackers are interested in.

Decide in advance what you will do when you see a real attack: who is alerted, how to tighten rules temporarily, and how to loosen them again afterwards. Rehearse it once, because an incident is a bad time to learn the interface.

How this fits the rest of the stack

Security layers are cheaper than incidents, and every layer is a line on the monthly bill. See what the hosting side costs, and where a database can stay private, in the RunxBuild hosting calculator. When you are ready to deploy with certificates and private database networking in place, the RunxBuild dashboard is where to start.

Useful related references:

FAQ

What does a WAF do?

It inspects HTTP and HTTPS requests to your application and blocks those matching attack patterns such as injection and cross-site scripting, while also offering rate limiting, bot controls and logging.

Is a WAF the same as a normal firewall?

No. A network firewall controls which connections reach which ports. A WAF reads the content of web requests at the application layer.

Will a WAF fix my vulnerable code?

No. It blocks known attack patterns and can virtually patch a disclosed flaw for a while, but logic errors and unknown vulnerabilities pass through. Fix the code.

Why does my WAF block legitimate requests?

Rules can match harmless content that resembles an attack. Run in detection mode, review the logs and add narrow exceptions for the specific rule, path or parameter involved.

Do I need a WAF for a small site?

Not always. Good patching, parameterised queries, private databases and rate limits go a long way. A WAF becomes valuable as the site draws attacks or handles sensitive data.