This is an illustrative scenario built from patterns we see repeatedly, not a named customer. The mechanisms are exactly how Nemesis Shield behaves.
The situation
A mid-market fintech processes card payments through a checkout built years ago on Django. It works, it's certified, and it is behind. Upgrading the framework means a regression-test cycle across a dozen integrations, so patches land on a quarterly schedule. Their security team knows the uncomfortable truth: when a critical framework CVE drops, they are exposed for weeks — and their WAF, tuned to generic signatures, doesn't understand their checkout well enough to help.
They have two specific fears:
- A server-side framework exploit (the React2Shell / Spring4Shell class) landing before they can patch.
- A browser-side card skimmer — the thing PCI DSS 4.0.1 now explicitly requires them to detect.
What they did
They didn't rewrite anything. In an afternoon they added two things.
1. Application Shield on the Django app — one line of middleware. For two days it ran in observe mode, learning the checkout's normal request shapes. Then they approved the baseline and flipped to enforce.
2. Client-Side Shield on the payment page — one <script> tag. It learned the page's real dependencies (their CDN, their payment processor, their analytics), which they approved.
flowchart TB
subgraph Browser
P["Payment page<br/>+ Client-Side Shield"]
end
subgraph Server
D["Legacy Django<br/>+ Application Shield"]
end
P -->|"card → your PSP only"| PSP["Payment processor"]
P -->|"page requests"| D
X["Skimmer script<br/>(rogue origin)"] -. blocked in browser .-> P
Y["Exploit request<br/>(off-baseline)"] -. blocked in-process .-> D
What changed
When the next framework CVE arrived, the exploit request — an unauthenticated POST with a malformed body to an endpoint — didn't match any shape the checkout normally serves. Application Shield blocked it, and raised a finding, while the framework was still unpatched. The security team patched on their own schedule instead of a panic timeline.
On the browser side, a penetration test injected a test skimmer from an unapproved origin and tried to beacon card data out via an image request. Client-Side Shield removed the script and blocked the exfiltration — the card never left the approved set of origins. That's the §11.6.1 tamper-detection and §6.4.3 script-authorization evidence their QSA wanted, produced automatically.
Why it fit their business
- No re-platforming. The shield sits in front of the code they already run, including the old parts.
- Proof, not noise. Every block is a finding with the shape that triggered it — audit-ready, not another alert to triage.
- It started free. One app, learn-and-alert, so a developer proved the value before procurement was involved.
The lesson generalizes: if your protection depends on being fully patched, you are exposed for exactly as long as patching takes. A shield that enforces your app's own normal protects the code you have today.