PCI-DSS 4.0 Req 6.4.3is now mandatory.
Every script on your checkout page needs authorization, inventory, and SRI integrity verification. Magecart averages 200 days on a checkout page before detection.
- Source: PCI Security Standards Council, PCI-DSS v4.0, Requirement 6.4.3 (PCI SSC, 2022).
Checkout page security, where PCI-DSS 4.0 meets real attack vectors
A compromised analytics script runs with full payment page access.
Magecart attacks compromise a third-party JavaScript file - analytics, chat widget, recommendation engine - loaded on the checkout page. Once served from an attacker-controlled CDN, it executes with full access to payment form fields. Average dwell time before detection: 200-300 days.
Req 6.4.3: PCI-DSS v4.0 (PCI SSC, 2022). Dwell time: Recorded Future, 2023.An order API with no ownership check exposes every customer.
IDOR on order APIs is the most common access control failure in e-commerce. An authenticated customer increments the order ID and retrieves another customer's order history, shipping address, and stored payment method. OWASP A01:2021 Broken Access Control is the top web application security risk.
OWASP Top 10 2021, A01:2021 Broken Access ControlXSS in a product review field can capture payment form data.
Stored XSS in user-generated content - product reviews, Q&A, wish list names - executes in the browser on any page where that content is rendered. On a combined product/checkout page, an attacker posts a review containing a script that reads payment form fields.
OWASP Top 10 2021, A03:2021 InjectionCheckout security at the code level, not just the WAF level
Third-party script authorization
- Scanner patterns enforce Subresource Integrity hashes on external script tags in payment page templates
- Scanner detects scripts loaded without integrity attributes or without whitelisted src domains
- New scripts added without SRI and CSP authorization surface as issues immediately
IDOR on order and account APIs
- Audit workflow detects API endpoints that access order or account resources by ID without visible ownership validation
- Changes enforce ownership checks: requesting user's account ID must match the resource's account ID
- UUID migration for sequential integer IDs is flagged and executed as part of the change
XSS in user-generated content
- Deterministic scanner patterns detect unescaped user content rendered directly into HTML templates
- Changes apply the correct output encoding for the rendering context
- Continuous scanning catches the pattern every time it recurs in new template additions
What PCI-DSS 4.0 requires for your checkout code
| Requirement | What it mandates | Hyrax |
|---|---|---|
| Req 6.2 | Secure coding practices including SAST | Continuous scanning with autonomous upgrade execution |
| Req 6.3.3 | All software protected from known vulnerabilities | Deterministic vulnerability scanner with PR-based remediation |
| Req 6.4 | Critical vulnerabilities remediated within 1 month | Issues surface immediately and arrive as pull requests without a sprint queue |
| Req 6.4.3 | All payment page scripts authorized, inventoried, SRI-verified | Continuous scanning verifies SRI and CSP requirements per change |
| Req 6.5 | Change and tamper-detection on payment pages | Continuous scanning; every change produces an audit-linked PR |
Source: PCI Security Standards Council, PCI-DSS v4.0, March 2022.
Common questions
from e-commerce engineering teams
PCI-DSS 4.0 Req 6.4.3 is new. What does our team need to do?
Req 6.4.3 requires you to maintain an inventory of all scripts loaded on payment pages, document a business justification for each, and verify their integrity with SRI hashes. Hyrax's scanner enforces SRI on external script tags and continuously verifies it on every change.
We use a hosted payment page (iframe from Stripe/Braintree). Are we still in scope?
Partially. The iframe is the processor's scope. But your checkout page HTML, the scripts you load on that page, and your checkout APIs are still in scope. Req 6.4.3 applies to your checkout page.
How does Hyrax protect against Magecart specifically?
Two layers: SRI verification means a modified script won't execute (browser checks the hash). CSP headers whitelist which domains can load scripts. Hyrax enforces both at the code level.
We already have a WAF. Does that cover IDOR?
WAFs can't see application-level authorization logic. A WAF cannot tell whether the request is being made by the owner of the resource. Authorization checks require application-level code. Hyrax detects and resolves the missing check.