How to Test Whether Your WAF Is Working (Beginner’s Guide)

The installation of a web application firewall (WAF) is not something that you do once and then forget about. Over time, rule sets can change, TLS/SSL certificate inspection may stop working altogether, new bypass mechanisms are introduced, and even a configuration modification made months ago may block your WAF.

A WAF that passes the first audit may not stay effective long-term without regular testing, regardless of its initial configuration. This thorough MilesWeb‘s guide shows how you can ensure that a WAF is still working and fulfilling its purpose.

Remember to test only the systems that belong to you or that you were allowed to test. Testing an attack pattern on a site you do not own can lead to breaking the law. Testing should always be carried out on staging first when applicable.

Why “Configured” Doesn’t Mean “Operational”?

A web application firewall (WAF) may show correct configuration on its user interface but still fail to do its job because of factors like:

• Fail-open: Some WAFs let traffic through if they can’t inspect it entirely; in this case, security is less of a priority in favor of accessibility. Other WAFs enjoy fail-secure behavior, meaning they block without exception when unable to inspect.
• Routing issues: Traffic can be routed away from the WAF by means of DNS or load balancer modification, because of which it doesn’t get filtered.
• Issues with SSL inspection: The unit should decrypt traffic in a secure protocol like HTTPS, or it won’t be able to conduct an inspection.
• Rule deviations: Rules disabled during maintenance may remain switched off forever.
• Unresponsive to updates: If WAF fails to receive information and update rules in a timely manner, it is likely to fail to detect recent attack patterns.

This proves that it is testing, not configuration, which is the only guarantee that a WAF works properly.

Step 1: Verify traffic is routed through the WAF

Before you can start testing your WAF to see what it blocks, you first need to verify whether traffic is reaching it or not.

1. Check your DNS definitions (or load balancer configuration) to see if your domain is pointing to the WAF endpoint and not directly pointing to the origin.
2. Issue a normal request the way users would do it and check header responses. Most WAFs add additional header info (i.e., Ray ID, request ID, etc.) when a request is processed.
3. And check the dashboard/logs of the WAF right after that. You should see your request in the logs.
4. If there are no logs, the traffic is not reaching the WAF, and until that is resolved, there is no point testing any rules.

Step 2: Send a Nonthreatening Test Request that Looks Like an Attack

A basic test involves sending a request that resembles a typical attack but poses no threat and checking that the WAF prevents the test from going through.

Sample Test: Simulated SQL Injection

Add an innocuous yet recognizable attack to a query parameter accepted by your website, for example:

https://yourdomain.com/?id=1' OR '1'='1

The WAF should issue a blocked message, usually an HTTP 403 Forbidden, rather than pass the request along to your application.

Sample Test: Simulated Cross-Site Scripting

https://yourdomain.com/?search=alert(1)

Once again, you should receive a blocked message, rather than seeing the normal, unrestricted page loaded.

How to determine the result?

1. Browser: Paste the URL into the browser’s address bar and find out whether a forbidden/error page appears.
2. Command line (curl): Issue the request and observe the response:

curl -I "https://yourdomain.com/?id=1' OR '1'='1"

1. Look for a 403 (or equivalent blocked status) instead of a 200 OK message.
2. If the requests were not blocked, this means that the relevant rule is not working or misconfigured, or the traffic is not routed through the WAF.

Step 3: Confirm the Log of the Block

A block request is an important factor, but you also need to ensure that the WAF logged this information.

1. Go to the WAF dashboard or the events/logs view.
2. Find the test request you had just made (filter by the time, source IP, or test URL).
3. Make sure that it says blocked, as well as the triggered rule name/ID.

Step 4: Test the Rules Before and After Going Live

Any time a rule is added, removed, or modified, the relevant test requests need to be made:

1. Before implementing any changes, check if everything works as expected (the baseline).
2. After the implementation of the required changes, let the test requests run again to verify whether everything works properly or not.

Many companies use a short and repeatable checklist containing a few attack patterns to test them multiple times after every rule modification, before going live with the new configuration, and on an ongoing basis (e.g., every month, even if no changes are made).

Step 5: Verify That Legitimate Traffic Still Goes Through

Simply testing whether “it prevents harmful traffic” is not sufficient. If WAF is set up too strictly, it can even restrict real visitors, which is an important issue after testing blocking mode:

1. Act as a real visitor (log in to your website, search the site, fill out a web form, etc.). 
2. Confirm whether normal activities are rejected or challenged.
3. View WAF records for false positives, i.e., non-dangerous messages that have been rejected.

Proper settings of WAF block harmful traffic without affecting real visitors. In case you see that real operations are being blocked or challenged, this rule has to be fixed too (not necessarily removed).