What is a web application firewall (WAF)?

Every site or API exposed to the internet receives requests that do not come from users: bots probing forms, scanners hunting for known flaws, attempts to inject code into a parameter. A regular firewall sees none of this, because the traffic is valid HTTP, from ordinary IPs, to port 443.

A WAF exists to fill that gap. It looks at the content of the request and decides whether it looks like an attack. Knowing what it does (and does not do) avoids two common mistakes: thinking it fixes everything, or thinking it is just a fancy name for a firewall.

What is a WAF?#

WAF stands for Web Application Firewall. It is a filter placed between the client and the web application that inspects HTTP and HTTPS traffic. If a request matches an attack rule, the WAF blocks it, logs it or challenges it (for example with a CAPTCHA). If it does not match, the request goes through to the application.

It protects against attacks that exploit the application itself, such as SQL injection, XSS (cross-site scripting) and local file inclusion. These examples appear in the description of the OWASP Core Rule Set (CRS), the best-known set of generic rules for ModSecurity-compatible WAFs.

How does a WAF work internally?#

The basic flow has three steps:

1. The request reaches the WAF, which decodes it (URL, headers, cookies, parameters, JSON or form body).
2. The WAF compares each part against its rules. A rule can be a regular expression, a list of patterns or a format check.
3. Depending on the result, it lets the request through, blocks it (usually with a 403 response) or only logs it.

Many WAFs use anomaly scoring. Instead of blocking on the first rule that matches, each rule adds points, and the request is blocked when the total passes a threshold. The CRS documentation recommends aiming for a threshold of 5. This reduces blocks caused by a single weak signal.

There are two rule models:

• Blocklist (negative model): blocks what looks bad. Easy to turn on, but it only catches what the rules know about.
• Allowlist (positive model): only accepts what is described as valid (routes, methods, field types). Stronger, but harder to maintain.

What are paranoia levels?#

The CRS has four paranoia levels. Level 1 is the baseline for any HTTP server, with few false alarms. Level 2 suits sites that handle real user data, such as a shop. Levels 3 and 4 detect more, but you must write rule exclusions because they block legitimate traffic. Raising the level without testing is the fastest way to break a form that used to work.

A concrete example#

Imagine a search route that builds its query by concatenating text:

// WRONG: vulnerable to SQL injection
const sql = `SELECT * FROM users WHERE name = '${req.query.name}'`;

An attacker sends ?name=' OR '1'='1. A WAF recognizes the injection pattern and returns 403 before the request touches your code. But the real fix lives in the application:

// RIGHT: parameterized query (mysql2)
const [rows] = await db.execute("SELECT * FROM users WHERE name = ?", [req.query.name]);

With a parameterized query, the value never becomes part of the SQL. The WAF is a second layer, not the first.

To get a feel for how a rule is written, here is a minimal ModSecurity rule that blocks the request if any parameter contains <script:

SecRule ARGS "@rx (?i)<script" \
    "id:1001,phase:2,deny,status:403,msg:'Possible XSS'"

In practice you rarely write rules like this from scratch: you use a ready-made set such as the CRS and tune the exceptions.

What is the difference between a WAF, a network firewall and DDoS protection?#

They complement each other. A WAF is not built to absorb a volumetric attack: for that, read what a DDoS attack is. It is also common for a WAF to run inside a reverse proxy or a CDN, because that is where the traffic already passes.

What are the limits of a WAF?#

• False positives: a badly tuned rule blocks real users, for example someone pasting a code snippet into a text field.
• False negatives: an attacker can obfuscate the payload or use a flaw no rule knows about.
• Logic flaws: a WAF does not know that user A should not see user B's order. Broken access control is a code problem.
• Operational cost: someone has to read the logs, tune exceptions and update rules.

That is why a WAF is one item on a longer list. See the deploy security checklist for what to do beyond it.

When does it make sense to use a WAF?#

It makes sense when the application is public and takes user input: forms, APIs with parameters, login pages. It also helps when you cannot fix a flaw right now, because a temporary rule (a virtual patch) blocks the exploit until the code is fixed.

It matters less for a bot that only opens an outbound connection to the Discord Gateway and receives no inbound HTTP requests. With no public entry point, there is nothing to filter.

How to do this on Square Cloud#

On Square Cloud, every plan includes a WAF and DDoS mitigation at layers 3, 4 and 7. The infrastructure uses isolated containers and an Anycast CDN with HTTP/3 and WebSockets.

This does not replace good practice in your code. Keep secrets in environment variables, use parameterized queries and validate input. Treat the WAF as an extra layer, not as your main defense.

See the Square Cloud network page for details on the CDN, WAF and DDoS mitigation.