Server-Side Request Forgery in axios
https://github.com/advisories/GHSA-8hc4-vh64-cxmjPCI DSS v4.0.1 · 6.4.3 & 11.6.1
Payment page
protection.
Full coverage for script management and continuous change & tamper detection on payment pages, sourced from real browser traffic, ready for assessment.
Reports Received
589
Script Origins
2
Script URLs
101
Script Hashes
109
Scripts OriginsScripts Loaded
Search by origin...
Search by hash...
Search by script...
| Origin | Hash↕ | Scripts |
|---|---|---|
https://shop.example.com | sha256-IILQsqZos8ItNdYf3zggyJ… | https://shop.example.com/_next/static/chunks/2096-2c0e4f5a8c5b9009.js |
https://shop.example.com | sha256-NgIxfP0u3MjMOfcK7ljLaH… | https://shop.example.com/_next/static/chunks/9852-af759da6a70add43.js |
https://shop.example.com | sha256-WGSgDDfQVjp1h/BrNUOVmF… | https://shop.example.com/_next/static/chunks/7843-e74f32f2c2ac53a8.js |
https://shop.example.com | sha256-iicX4/KO89QRW1jWfrvW0d… | https://shop.example.com/_next/static/chunks/checkout/page-d8a1.js |
https://shop.example.com | sha256-jVOyzgvva5CtyqOuAt9zw4… | https://shop.example.com/_next/static/chunks/7707-a8ccd6f48812bb53.js |
https://analytics.example.io | sha256-dmJ8eoAj/fzwaXDGetK/E5… | https://analytics.example.io/static/surveys.js?v=1.336.4 |
https://shop.example.com | sha256-tymInNRGEDTeIx0x5Ftp0V… | https://shop.example.com/_next/static/chunks/4882-dde4ec12b9538d98.js |
https://shop.example.com | sha256-BwZYfr1X8AxxCM+6eVou11… | https://shop.example.com/_next/static/chunks/3726-42d93c1ed3fba149.js |
https://shop.example.com | sha256-hSgLk65Rzx8cIeN/jqohVU… | https://shop.example.com/_next/static/chunks/webpack-12fb88693568036f.js |
https://shop.example.com | sha256-+gGkRdXLZoTh50a92ynAky… | https://shop.example.com/_next/static/chunks/app/(checkout)/page-00d157.js |
https://shop.example.com | sha256-i42TNdtcBbjgJGmmFVCyXH… | https://shop.example.com/_next/static/chunks/app/(dashboard)/layout-bbe14f9.js |
https://shop.example.com | sha256-PmMsbSq33f9Ax2ngHGj11s… | https://shop.example.com/_next/static/chunks/9664-bbf55e28a0306eec.js |
https://shop.example.com | sha256-VLWAjHrr7D9HovZaaIbpTv… | https://shop.example.com/_next/static/chunks/8141-a042cd5a4ae178b0.js |
The problem
Payment pages run code you did not ship. PCI DSS v4.0.1 makes that your problem.
Magecart attacks, formjacking, and silent vendor updates all happen inside the customer's browser, not on your servers. The 6.4.3 and 11.6.1 sub-requirements exist because that script-loading layer is the actual attack surface, and assessors will ask you to prove you have controlled it.
- 01Visibility
Your edge stack cannot see what runs on /checkout.
WAFs and CDNs inspect requests and responses. They do not read, hash, or attribute the JavaScript that ends up executing in the customer's browser on the payment page. That is where every script-loading attack lands. - 02Security
Skimmers do not touch your server.
Magecart-style attacks compromise a third-party script the browser was already trusted to load. Card data is exfiltrated from inside the browser, often through tag managers and marketing pixels, while your server logs stay clean. - 03Compliance
QSAs ask for evidence per page, per script.
PCI DSS v4.0.1 6.4.3 wants an authorized inventory with integrity hashes. 11.6.1 wants change detection. Both have been enforceable since 31 March 2025, and "we have a CSP" is no longer the answer.
Coverage at a glance
What v4.0.1 asks for. What we deliver.
6.4.3
Fully covered. Script authorization, SHA-256/384/512 integrity, per-page inventory, vendor identification with CVEs.
11.6.1
Script-loading layer fully covered with real-time tamper detection. HTTP header / DOM diff is out of scope.
10 min
From signup to first browser-sourced evidence in your dashboard. No agent to deploy, no crawler to schedule.
PCI DSS v4.0.1
6.4.3
Authorize, assure integrity, and inventory every script that loads on a payment page.
- 01 / 046.4.3
Script authorization workflow
Every script observed by a real browser surfaces in the inventory as the source of truth. Your team reviews, approves, or rejects each one, backed by exportable evidence your QSA can audit. - 02 / 046.4.3
SHA-256 / 384 / 512 integrity hashes
Hashes captured directly from the browser via CSP report-sha* directives. Any change on a known script is recorded with a timestamp and version diff. - 03 / 046.4.3
Always-current script inventory
Per payment page: every script, its origin, full URL, hash, and last-seen timestamp. Justification fields integrate with your change-management process; the inventory exports as audit evidence. - 04 / 046.4.3
Vendor & third-party identification
Technology fingerprinting against a corpus of around 5 million known signatures identifies what powers each script, and links to associated CVEs with severity and advisory.
PCI DSS v4.0.1
11.6.1
The Magecart / skimmer / formjacking attack surface, detected in real time.
- 01 / 0311.6.1
Four detection signals, real time
Per-page alerts fire on four specific events: a new origin loading a script, a new script URL under a known origin, an integrity-hash change on a known URL, or an unseen hash on a versioned URL pattern. Delivered to Slack or by webhook. - 02 / 0311.6.1
Continuous evaluation, not weekly
The requirement allows weekly checks. CentralCSP evaluates every real-user page load, recomputing and comparing hashes on each observation. - 03 / 0311.6.1
Audit evidence
Per-page change timelines, exportable logs of every detection event, and 90-day data retention. Everything an assessor needs to verify ongoing review.
Why this can't be your WAF
The layer your WAF
can't see.
The PCI Council wrote 6.4.3 and 11.6.1 because the script-loading layer in the user's browser is the actual attack surface for Magecart, skimmers, and formjacking. Your edge stack cannot see it. That is the gap CentralCSP closes.
Edge & request-layer tools
What WAFs can't tell you.
- The exact script bytes that ran in a real customer's browser on /checkout.
- Whether a vendor pushed a new bundle without telling anyone.
- Per-page attribution for every loaded origin and URL.
- Cryptographic hashes captured by the browser at delivery time.
Browser-sourced CSP reporting
What CentralCSP captures.
- SHA-256 / 384 / 512 integrity hashes from real user sessions.
- Per-payment-page inventory with origin, URL, technology, and CVEs.
- A timeline of every change, exportable as QSA evidence.
- Real-time alerts on new origins, new scripts, and hash drift.
Alerting
Real-time alerts
delivered to
your team.
11.6.1 is a continuous-evaluation requirement. CentralCSP runs four rule types against every real-user page load and delivers the result to Slack or any webhook. Scope each rule to the payment pages that matter, so marketing and staging traffic never pages your on-call.
- 01
New origin
A domain you weren't tracking starts loading scripts on a registered payment page.
- 02
New script
A new script URL appears under an origin you already track.
- 03
Hash change
An existing script URL serves new content. The classic tamper-detection signal.
- 04
Hash pattern
For versioned CDN URLs, an unseen hash appears anywhere under the pattern.
payment-page-alerts
CentralCSP AlertingApp22 h 18
CentralCSP: Script hash changes for Demo Alerting (Rule: Checkout bundle integrity)
The following script(s) now serve different content (hash changed):
----------
- https://example.com/scripts/external.js
Previous:sha256-dOmdAH/SGVB0D20KuZ8tWhZ5+CWvCUCpHCc00GYoOQE=New:sha256-RldjDaPfakAnS4ESGUtUjGLTW0G1NYhYFIbsJ/SgLpA=- https://cdn.example.com/vendor/bundle.min.js
Previous:sha256-7xK8k2pQ3mN4vB9cD1eF2gH3iJ5kL6mN8oP9qR0sT1uV=New:sha256-AbCdEfGhIjKlMnOpQrStUvWxYz0123456789AbCdEfG=
----------
Review in your dashboard under "Script Inventory".
Technology fingerprinting
Every common script.
Identified.
Around 5 million known library and vendor signatures resolve each script back to the technology behind it. CVEs surface with severity and advisory links, no hunting, no spreadsheet. Fingerprints feed straight into the script inventory so vendors and versions are searchable from day one.
Reports Received
66
Script Origins
3
Script URLs
4
Script Hashes
4
Scripts OriginsScripts Loaded
Search by origin...
Search by hash...
Search by script...
| Origin | Hash↕ | Scripts | Techno | CVE | Last seen↕ |
|---|---|---|---|---|---|
https://code.jquery.com | sha256-xNzN2a4ltkB44Mc/Jz3pT4… | https://code.jquery.com/jquery-3.5.0.min.js | jQuery | 1 day ago | |
https://cdn.jsdelivr.net | sha256-En0MPdwwIwYfsdUUIhvKhD… | https://cdn.jsdelivr.net/npm/axios@1.6.6/dist/axios.min.js | Axios | 4 CVEs | 1 day ago |
https://cdn.jsdelivr.net | sha256-GRJrh0cydT1Cw536bBeJK/… | https://cdn.jsdelivr.net/npm/bootstrap@4.6.2/dist/js/bootstrap.bundle.min.js | Bootstrap | 1 day ago | |
https://reportingendpoint.com | sha256-dOmdAH/SGVB0D20KuZ8tWh… | https://reportingendpoint.com/scripts/external.js | 1 day ago |
Page 1 of 1. Showing 4 of 4 results
15 ↕
CVE detail
Severity.
Explanation. Link.
Every CVE on a loaded script comes with a severity, a one-paragraph explanation, and a direct advisory link. Every finding is actionable from the dashboard.
Script details
axios
sha256-En0MPdwwIwYfsdUUIhvKhDP95uNuDN14HdreMQuE2mo=
4Known CVEsURLs that served this scriptReports details
Axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL
https://github.com/advisories/GHSA-jr5f-v2jv-69x6When Axios runs on Node.js and is given a URL with the data: scheme, it does not perform HTTP. Instead, its Node http adapter decodes the entire payload into memory (Buffer / Blob) and returns a synthetic 200 response. This path ignores maxContentLength / maxBodyLength (which only protect HTTP responses), so an attacker can supply a very large data: URI and cause the process to allocate unbounded memory and crash (DoS), even if the caller requested responseType: stream.
https://github.com/axios/axios/security/advisories/GHSA-4hjh-wcwx-xvwjVersions before 1.6.8 depends on follow-redirects before 1.15.6 which could leak the proxy authentication credentials.
https://github.com/axios/axios/pull/6300Lifecycle
From CSP directive
to assessor evidence.
One small CSP change starts a feedback loop that runs from every real browser session straight into the evidence pack you hand to your QSA.
- 01
Configure
Add report-to and a Reporting-Endpoints header pointing at CentralCSP, enable one report-sha* keyword under script-src, and register your payment page URLs.
- 02
Collect
Real browser sessions send integrity reports as users hit checkout. Each one is attributed to the page that loaded it.
- 03
Review
Triage new scripts, new origins, and hash changes from the dashboard or your alerting channel.
- 04
Assess
Export the per-page inventory and event timeline as evidence your QSA can sign off on.
Setup
Fast setup.
Ten minutes.
Set a
Reporting-Endpoints header and report-to in your CSP, then enable one of 'report-sha256', 'report-sha384', or 'report-sha512' under script-src. Browsers send integrity reports through that endpoint. The Chrome extension lets you author and test the header in the browser before shipping.HTTP response headers
Content-Security-Policy:
default-src 'self';
script-src 'self' 'report-sha256';
....
report-to csp-endpoint;
Reporting-Endpoints: csp-endpoint="https://report.centralcsp.com/<your-endpoint>"Frequently asked
Questions buyers ask.
Direct answers about coverage, scope, and where this product stops. Missing yours? Reach out and we'll add it.
If you can't show the assessor what loaded on the payment page in real time, you don't have an answer.
Effective now, v4.0.1 in force since 31 March 2025
Close the 6.4.3 + 11.6.1 gap.
Connect CSP reporting, register your payment pages, and walk into your next assessment with continuously-collected, exportable evidence your QSA can sign off on.