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.

| What a WAF rule can’t do - but an in‑flight patch can

Real‑world problem	Why a generic WAF still leaves risk	What the RedShield in-flight security patch does on‑the‑wire
Broken object‑level authorization (IDOR) - e.g. /api/user/1234 returns any user’s record	Authorization depends on who is logged in; a WAF lacks session‑aware entitlement logic	Looks up the authenticated user, compares it to the requested object ID (or calls an external entitlement API), and rewrites or blocks unauthorized calls
Context‑specific escaping for SQLi/XSS - the same input is used in SQL, HTML and shell contexts	Signature rules miss polymorphic payloads; a WAF can’t decide the correct escaping for each sink	Rewrites each parameter with the correct quoting/encoding per context so every variant is rendered harmless
DOM‑based XSS in /js/app.js	Requires serving a clean JavaScript file; blocking alone breaks functionality	Replaces the vulnerable script on the fly with a hardened version before it reaches browsers
Session fixation / insecure Set‑Cookie attributes - predictable IDs, no HttpOnly/SameSite	A WAF can’t mint a fresh ID and track it across both directions; it sees only opaque header strings	Generates a new random session ID, rewrites the Set‑Cookie header and subsequent requests, and adds modern flags such as Secure, SameSite=Strict, and HttpOnly
Step‑up MFA injection for high‑risk actions - e.g. wire transfer above $1000	Insufficient authentication can be detected, but a WAF can only block or pass and cannot challenge the user	Intercepts the request, pauses the flow, calls an MFA service, and forwards or blocks based on the result - transparent to the legacy app
Prompt‑injection attempts against an LLM endpoint	Dangerous tokens live deep inside a JSON body; regex blocking causes large false‑positive/negative rates	Parses the JSON, sanitizes or strips risky prompt fragments before the LLM sees them, and logs the original for forensic review
Rolling CSP nonces for dozens of inline <script> tags	A WAF can add a static CSP header but can’t rewrite every tag with a matching per‑response nonce	Generates a unique nonce per page, inserts it into every inline element, and appends the correct Content‑Security‑Policy header on the fly
Retiring a vulnerable third‑party JS library (e.g. jQuery 1.x) embedded in hundreds of templates	A WAF cannot serve files; if it blocks the request the page breaks	Rewrites references to the vulnerable library, serves a safe version from RedShield’s cache, and strips the unsafe file from client cache control headers
Server‑side input validation weaknesses	Regex blocking is brittle and noisy; a WAF struggles to understand complex parameter structures	Parses and sanitizes user input server‑side before it reaches the application, applying context‑aware validation rules
Idle session not timing out	Requires per‑session tracking, which is beyond basic WAF capabilities	Monitors activity across the session and blocks reuse of tokens once inactivity exceeds the configured timeout

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.

In-Flight Security Patches

| In-Flight Patches Go Beyond the Limits of Virtual Patches

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.

| How in‐flight patches work

| What a WAF rule can’t do - but an in‑flight patch can

Real‑world problem

Why a generic WAF still leaves risk

What the RedShield in-flight security patch does on‑the‑wire

Learn how RedShield can safeguard your web applications and APIs.