For years, Web Application Firewalls (WAFs) have taken a detect-and-block stance: inspect each request, decide whether it looks hostile, and drop it if it matches a rule set. That approach worked tolerably well because creating a viable bypass demanded skill and time, and vendors kept pace by refining signatures and anomaly models. Filtering was never perfect - OWASP notes that input filtering alone “is an incomplete defence” for injection issues such as for SQLi and XSS - but the residual risk was often acceptable to businesses.
Over the past two years that margin has disappeared. Generative-AI tooling can mutate a single payload into hundreds of obfuscated variants in seconds, test them against public demo sites, and share the winners across underground forums. Academic work such as the April 2025 GenXSS study shows 80% of AI-generated XSS strings sailing straight past a WAF equipped with an industry standard security rule set developed by the Open Web Application Security Project (OWASP) to protect against web vulnerabilities. Attackers no longer pay a research tax to discover bypasses; machines do it for them.
When detection is this unreliable, the safe path is to neutralize the payload instead of predicting its intent. OWASP’s Cross-Site Scripting Prevention guidance is clear: after validating input, parameterise or escape it so that even if an attacker smuggles payload characters, they are neutralized.
Escaping rewrites dangerous metacharacters (<, ', \, $, etc.) into safe representations before the interpreter sees them. A string such as <script>alert(1)</script> ends up as <script>alert(1)</
As OWASP says, doing this delivers “perfect injection resistance”, because even if hostile characters are present they are rendered inert text.
A WAF sits at the edge of the network and has two basic actions: block the request or let it through. Escaping, by contrast, actually rewrites the request - and the exact rewrite depends on where the data will be used. HTML entity encoding, SQL bind-variable escaping, LDAP escaping, and shell quoting all follow different rules. Only the application itself (or a RedShield-developed in-flight security patch) knows which rule set to apply at each sink. Because a WAF cannot perform those context-specific rewrites, it falls back on pattern-matching to guess whether the data is dangerous - an approach that generative-AI tools are now exceptionally good at evading.
RedShield’s position
RedShield focuses on removing the vulnerability first. Our in-flight security patches escape or parameterise untrusted input before it reaches HTML, SQL, XML, or shell contexts, while leaving the upstream WAF in place as a secondary net. That combination delivers provable coverage with a measured false-positive rate below 0.0002 %, even under AI-driven probing. In-flight patches do not require modifying the application code in any way, so they can be quickly applied with low risk, to address application-specific vulnerabilities.
The industry has moved past the era where “good enough” blocking covers the risk. "Character escaping is the dependable way to protect from SQLi and XSS attacks, and it is one that WAFs simply cannot deliver.
