EU AI Act Article 50 Transparency Audit for Your Codebase

Five scripts nobody authorised sit on one ordinary checkout page - e-commerce developers in the US and the EU, on markup that already renders and takes money.

checkout.html
   5  error  The CSP is in a <meta> tag - meta ignores report-uri and report-to, so 11.6.1 can never alert you.
   5  error  script-src allows bare https: - every host on the internet is an authorised script source.
   7  error  googletagmanager.com/gtag/js - a container can add a script after the inventory was signed.
   9  error  jquery@latest - a moving version, so no integrity hash stays true until the next audit.
  10  error  static.hotjar.com - a session recorder on a page that has a card field.

That is the audit output, not a summary. Twenty findings come back from that page in total; those five are the top of the list. Not one is a bug - the page renders and payments go through. They are a requirement mandatory since 2025-03-31 that nobody put on the sprint board.

PCI DSS 4.0.1 requirement 6.4.3 says every script executed in the customer's browser on a payment page needs three things: a method confirming it is authorised, a method assuring its integrity, and an inventory entry with a written justification. Requirement 11.6.1 adds that you must be alerted when that page's scripts or security headers change.

The markup behind them:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline' https:">
<script src="https://www.googletagmanager.com/gtag/js?id=G-8QK2M1RS"></script>
<script src="https://cdn.jsdelivr.net/npm/jquery@latest/dist/jquery.min.js"></script>
<script src="https://static.hotjar.com/c/hotjar-2914455.js?sv=6"></script>
<script src="https://js.stripe.com/v3/"></script>

The last line is fine, and naive tooling flags it anyway: js.stripe.com must load with no Subresource Integrity hash, because Stripe rotates that file. It still needs an inventory row - justification: renders the hosted card fields.

What changed this year

Merchants with a fully outsourced checkout used to have a way out: if the processor delivered the whole payment page, a QSA could agree that 6.4.3 and 11.6.1 were not applicable, and that was enough for the report.

On 2026-08-04 the PCI Security Standards Council published a revised FAQ 1331: QSA agreement alone is no longer sufficient, and merchants must consult their Compliance Accepting Entity - the acquirer or payment brand. The requirements did not change; the escape route narrowed, inside an assessment cycle many teams are in.

Why your existing tools miss it

A CSP evaluator grades the policy string and never opens your page, so it misses a script injected at runtime by document.createElement('script'). ESLint reads JavaScript, not <script> attributes, so integrity= with no crossorigin= - which browsers ignore, leaving you unprotected while the markup claims otherwise - goes straight past it. And an assistant trained before this year will tell you Subresource Integrity is sufficient for 6.4.3. It is the most common wrong answer here: SRI inventories nothing, skips dynamically injected scripts, and never notices an authorised script behaving differently.

The audit reads the page as markup, line by line, against 26 rules written for payment pages: each finding names the line, the requirement it fails and the fix. The free version audits the page you have open, completely - all 26 rules, no key, no watermark, nothing locked.

What a licence adds is not more rules - it is the artifact. An assessor does not accept a findings panel; they accept a dated inventory. The full version exports it as CSV, JSON or HTML across every payment page in the repository, and fails a CI build when an unauthorised script appears. A PCI consultant bills about $76 an hour in the US in 2026, and a QSA-assisted self-assessment runs $5,000 to $20,000. Building this inventory by hand is billed inside that, and it has to be rebuilt every time marketing adds a tag.