In-Flight Security Patches
This page explains RedShield’s in‑flight security patches - what they are, how they work, and how they differ from the “virtual patching” rules found in Web Application Firewalls (WAFs). You will also see practical examples of the kind of flaws an in‑flight patch can fix that a rule‑based WAF cannot.
| In-Flight Patches Go Beyond the Limits of Virtual Patches
Many security products claim to offer virtual patching. In practice, that means a rule or signature in the WAF that blocks requests matching a known pattern, such as a typical SQL‑injection string. Blocking is helpful, yet it leaves the underlying vulnerability in your application untouched and offers little defense against business‑logic abuse that does not match a known pattern. RedShield provides virtual patching as part of its comprehensive security service, but also develops and deploys in-flight security patches to fix application-specific vulnerabilities in real time.
RedShield’s in‑flight security patches take a different approach than virtual patches. They sit inside our proxy and watch traffic flowing in both directions. When a risky transaction is detected, the patch can rewrite the request or response, add missing controls (for example anti‑Cross Site Request Forgery tokens), inject additional logic, or even call out to an external service - all in real time and without needing access to your application’s code.
So:
|
![]() |
A virtual patch blocks bad traffic based on what it looks like. |
An in‑flight patch fixes the vulnerability on the wire, so even attacks that look valid fail. |
And RedShield’s service provides both, to offer the most comprehensive application security.

| In-Flight Patches Go Beyond the Limits of Virtual Patches
The whole cycle completes in milliseconds, so users notice no delay.
| What a WAF rule can’t do - but an in‑flight patch can
Real‑world problem |
Why a generic WAF rule struggles |
How an in‑flight patch fixes it |
CSRF on legacy forms |
The WAF cannot rewrite every form to add tokens |
Injects unique anti‑CSRF tokens and validates them on return. |
Session ID visible in URLs
|
Needs every link rewritten - beyond WAF scope. |
Strips IDs, stores them in secure cookies, reinjects server‑side. |
DOM‑based XSS in /js/app.js
|
Requires serving a clean JavaScript file. |
Replaces the vulnerable script on the fly. |
Hidden price parameter tampering |
Needs cryptographic signing and checking. |
Signs the field in the response, verifies the signature on submit. |
Out‑of‑date OpenSSL on a legacy server |
Library is still exposed. |
Terminates TLS on RedShield’s hardened stack, removing exposure. |
Idle session not timing out |
Requires per‑session tracking. |
Monitors activity and blocks reuse of logged‑out tokens. |
Server‑side input validation |
Regex blocking is brittle and noisy. |
Parses and sanitises user input before it reaches the app. |
RedShield’s service provides both virtual patching and in-flight security patching. This means we can both block threats and fix your application-specific vulnerabilities without touching the code base - so your developers can spend more of their time working on your organization’s important strategic projects.