Web Application Firewall (WAF)

What is Web Application Firewall (WAF) – In Simple Words

Imagine that your website is the entrance to a building. People come in, fill out questionnaires, leave messages, buy something. Everything is fine… until someone decides to come in with a sledgehammer and start breaking the furniture – that is, hacking forms, getting access to the database or just bringing down the server.

That’s where a guard is needed at the entrance. It is this guard that is WAF – Web Application Firewall.

WAF is a filter between the Internet and your website. It checks every incoming request: who came, what wrote, where clicked, what is transmitted. If something looks suspicious – like the phrase ‘ OR 1=1 in the login field – WAF says: “Stop. You will not pass”.

Unlike conventional network firewalls, which work at the level of IP addresses, ports and protocols, WAF looks deeper – deep into the request itself. It can read the contents of the login form, browser headers, and parameters in the URL, and decide whether this behavior is normal or not.

How WAF Works – The Mechanics of Verification

So, let’s say a person opens a website and enters a login. What does the WAF do at this point? It analyzes everything that is sent to the server. Here’s what it looks at:

• URL and parameters (for example: site.com/login?user=admin&pass=123)
• Request headers (what the person is using, what browser version they’re using, and where they’re coming from)
• Form body (what the person has entered)
• Cookies which can be stolen(small files that the site has left behind).

WAF looks at this and compares it to a set of rules, these rules can be different:

• Signature analysis — based on known attack patterns. For example, SQL injection attacks almost always contain ‘ OR 1=1 or –. Is it recognizable? Very much so.
• Heuristics — an attempt to understand how strange the behavior is, even if it is new.
• Behavioral analysis — the WAF can “remember” normal traffic and then notice a sudden increase in suspicious activity from a single IP or browser.

The results can be as follows:

• Pass (everything looks clean);
• Block (attack);
• Leave in the logs (so that the admin can check it later).

Sometimes, WAF includes a “learning mode”: it doesn’t interfere, but it monitors and remembers what usually happens on the website. This helps to avoid errors when WAF confuses a regular user with a hacker.

What WAF Can Stop – Examples of Attacks

A WAF is not just an observer. It is a shield that can stop specific types of attacks. Here are the most well-known ones:

1.  SQL injections
   •  An attack in which an attacker inserts malicious SQL code into a form or URL.
   • For example, if a user enters ‘ OR 1=1 — in their login, the system assumes that they are an administrator.
   • A WAF can detect such patterns and prevent them from entering the system.
2. XSS (Cross-Site Scripting)
   • When an attacker inserts malicious JavaScript into a comment, and this script is then executed by other users.
   • Example: <script>alert(“hacked”)</script> — and visitors see a pop-up window.
   • WAF knows that this is not allowed, and blocks the code.
3. CSRF (Cross-Site Request Forgery)
   • When a user secretly sends a request on their behalf, without even realizing it.
   • WAF tracks suspicious actions and may not miss such tricks.
4. File inclusion (inclusion of other people’s files)
   • A hacker tries to download or execute a malicious file.
   • WAF can track such attempts by characteristic URLs or headers.

Brute Force and automated attacks, If someone starts trying to guess logins and passwords, WAF will see it — by the number of attempts, time intervalshttps://whoerip.com/glossary/website-address/ and IP. A real-life case: a user logs in 40 times in a minute — the block is permanent.

Different Types of WAF: Hardware, Cloud, Software

WAF is not a single thing. There are several formats, and the choice depends on the tasks and budget. Here are the main options:

On-premise (hardware WAF), this is a hardware device that you have in your data center or office.

• Very flexible configuration, everything is under control.
• But: expensive, requires technical support, does not scale quickly.

Used in banks, large corporations, government agencies.

Cloud-based (cloud-based WAF)

Example: Cloudflare, AWS WAF, Azure Application Gateway.

• Set it up and forget about it. Everything is in the cloud, fast, convenient.
• The downside is that you don’t have full control, and you may be dependent on the provider.

Suitable for websites of any size, especially if you don’t have your own infrastructure.

Software-based (software WAF), installed as a module on a web server, such as NGINX, Apache, or Node.js.

• You can customize it and avoid paying for hardware.
• However, it requires knowledge of configurations and may not be easy to update.

Example: ModSecurity is one of the most popular free WAFs.

When WAF Doesn’t Save You – Limitations and Vulnerabilities

So, you’ve set up a WAF, you’re relaxed, drinking tea and happy – they say, now no attacks are scary. Alas, no. WAF is a defense, but not armor from everything. That’s why.

Smart attacks disguised as ordinary users

Attackers today are not only techies, but also good psychologists. They know how to make their requests look legitimate without being obvious. Example:

• They insert other logical constructs instead of 1=1.
• They write SQL injections in encoding or as URL encoding.
• They spread out the attack in time — 1 request per minute instead of 1000 per second.

This “soft” approach can bypass WAF, especially if it follows a basic set of rules.

False Positives — when the WAF blocks its own. You just entered O’Reilly in the “Last Name” field, and the site kicked you out with an error. Why? Because the ‘ (apostrophe) scared the WAF: what if it’s the beginning of an SQL injection? These are false positives — the WAF mistook a regular user for a hacker.

This also includes:

• Unexpected URL parameters (such as links from other systems)
• Specific search or filtering forms
• Legal scripts that look “suspicious”

If your WAF is set up too strictly, you’re damaging your own UX and losing customers. Risks of poor configuration, the worst-case scenario is when you have a WAF but it’s not properly configured.

• Misses obvious attacks (for example, forms without protection)
• Conflicts with cache, JS scripts, and APIs
• Logs everything, but doesn’t block anything
• Or vice versa — blocks everything and breaks functionality

A simple rule applies here: a poorly configured WAF is worse than no WAF at all. Because it creates an illusion of protection.

Who Uses WAF — And Why

Ask yourself: Who has websites with user input? Who has forms, personal accounts, payment pages, and APIs? The answer is almost everyone. This is why WAF is no longer a toy for the paranoid, but a part of normal web service operation.

E-commerce (online stores)

• Protection of shopping carts, payment forms, and customer accounts
• Preventing fraud (fraudulent actions)
• Blocking bots, price scanners, and parsers

Fintech and banks

• Mandatory requirements for protecting web interfaces (login, transfer, chat)
• PCI DSS requires the use of WAF if you have card transactions

SaaS platforms

• Protecting against API attacks
• Rejecting illegitimate integrations and downloads
• Preventing leaks through web application vulnerabilities

Government agencies and institutions

• Protecting application forms and citizens’ offices
• Blocking DDoS and Tor/Proxy bypasses

Example: a country’s tax system with a WAF at the entrance blocks any attempt to send a script in a declaration. Sounds utopian? But it works.

How to Set Up a WAF and Not Suffocate Your Website

Often, a WAF turns into a boorish “prohibition machine”: anything that doesn’t look like vanilla traffic — ban. But it shouldn’t be like that. The main thing is smart configuration for tasks.

WAF modes of operation

• Monitoring/Log only — just observes, doesn’t block anything.
• Useful at the start to understand: who and for what to ban.
• Active protection — works as a filter. Already blocks suspicious.
• Learning mode — “learns” from the flow of real users to avoid false positives. Used during the first setup.

Basic settings

• Whitelist/Blacklist — allowed and prohibited IPs, regions, browsers
• Rate limiting — limiting the number of requests per time period
• Custom rules — custom templates, for example: “deny any POST requests with an empty User-Agent”

Testing before production, before turning on the WAF in active mode:

1. Run it in monitoring mode.
2. Collect logs for at least a week.
3. See who would be blocked.
4. Set up exceptions (if needed).
5. And only then turn on protection.

Important: test everything. Especially forms, filters, personal accounts, and APIs.