Hi Hackers 🧑💻,
Yesterday, I was testing an application from one of the well-known e-commerce websites — {redacted.com}.
I approached it from multiple angles, exploring various functionalities and attack surfaces. To my surprise, the application was quite secure. They had implemented proper input sanitization, avoided version disclosures, and followed secure coding practices quite well.
One of the key defenses in place was a Web Application Firewall (WAF) — specifically, Akamai’s WAF.
🔐 What is a WAF?
A WAF, or Web Application Firewall, is a security solution that protects web applications from external threats such as DDoS attacks, rate limiting abuse, and injection attacks like SQLi, XSS, SSTI, and more.
It works by analyzing incoming HTTP requests — including headers, body, and parameters — and detecting patterns that match known malicious behavior. If a request is flagged as suspicious or malicious, the WAF can block the request or temporarily block the source IP address.
🧠 Understanding the Functionality
As I mentioned earlier, WAFs inspect the body of incoming requests, and if anything looks suspicious, the request gets blocked.
But but but… here’s the twist!
Modern WAFs are designed to support full request body inspection, but only if configured properly.
If the WAF is running with default settings or is misconfigured (intentionally or not), it often inspects only the first 128KB of data in the request body. This means — if your payload is pushed beyond that limit, the WAF might simply ignore it!
You can even find this behavior documented in Cloudflare’s WAF documentation, as well as in others like Akamai.
link : https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/http.request.body.raw/ | you can click here and read the full documentation.
🚪 How to Bypass It?
There are plenty of tricks we can use to fill up the request body with random data before inserting our payload.
Why?
Because if the WAF only inspects a limited amount of data (e.g., first 8KB or 128KB), then the actual payload can be pushed beyond that limit — causing the WAF to miss it completely, while the server still processes and renders the full request as usual.
You can use arbitrary junk data to fill up space, like this:
{
"random_data": "IEFJ823JFNMOI2FIOEWNFFJ029EIHF0H203F0ICN0PIFJ32C320FCJ20PFCJ32F0CJ23FCJ320FJ320FIJ320JF320J3Q2FJC0P3FCI32JFC32F30FCJ320F32JF",
"payload": "<img src=x onerror=alert(1)>"
}
And then — try sending the request. In most cases, it’ll work!
But of course, there are always exceptions — situations where traditional techniques fail or don’t give the expected result.
Trust me, it has happened to me more times than I’d like to admit… LOL. 😄
I first tried adding junk data to push the real payload beyond the WAF’s inspection limit — but the site responded with a 400 Bad Request. Turns out, it was analyzing the headers and parameters strictly, causing the request to break.
But c’mon, what does OffSec always teach us?
Try Harder! 💪
Different Logic to bypass it !
So, I tried going blank😄
Means,I added blank lines in the request body and placed the actual data along with the payload starting from line 166.
The idea? Push the payload out of reach of the WAF’s inspection window.
You can add as many blank lines as you want — just make sure your payload lands beyond the limit the WAF is configured to inspect.
As you can see in the Burp Suite requests:
- In the first payload, the actual data starts from line 32.
- In the second payload, it starts from line 167.
Now take a look at the responses — in the first one, the WAF blocks the request. But in the second one, the request goes through successfully, and I’m able to enter and submit an XSS payload.” Boom it worked !!
✅ WAF bypassed! 🎊🚀
This is a simple yet effective technique you can try while testing web applications — especially when dealing with WAFs that have shallow inspection limits.
🔑 Key Takeaways
- Never underestimate documentation.
I had read about this WAF limitation a while back — when I was hosting a CTF in my university, I used it in one of the challenges. That same knowledge helped me today in the real world.
➤ Always go through the documentation whenever you’re working with a new tool or service. It can seriously increase your chances of finding unique bugs. - Always Try Harder.
Just because a defense mechanism is in place doesn’t mean the site is truly secure. With the right approach, even the most “secured” applications might contain critical vulnerabilities. - Don’t lose hope.
This was one of the well-known e-commerce brands — and I’m sure it has been tested by tons of security researchers.
And still, this bypass worked. So yeah, never doubt your effort — the next big vuln might just be one payload away.
That’s all from my side today.
Happy Hacking 🙂
Stay tuned for more content 🙂
Likes my technique? : https://coff.ee/rghacker
Youtube : https://www.youtube.com/@theunixverse77