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.

Inflight patch

| 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.

 

 

Learn how RedShield can safeguard your web applications and APIs. 

Start your free trial or schedule a discussion with one of our experts today.