Content Security Policy on a Hyva Magento Storefront: Inline Alpine.js, Nonces, and a Report-Only Rollout

A Content Security Policy on a Hyva Magento storefront tells the browser which scripts and styles may run. Adobe Commerce 2.4.7 and later enforce a strict policy on payment pages by default, and Hyva ships the Alpine CSP build plus a hyvaCsp helper so inline code keeps working. The hard part is the rollout to restrict mode.

Most Magento CSP guides were written for Luma and stop at “add a csp_whitelist.xml entry.” That advice is incomplete on Hyva, because Hyva’s entire frontend is built on inline Alpine.js expressions, and strict CSP is designed to block exactly that. This article covers what changes on a Hyva theme specifically, why standard Alpine breaks, the exact helpers Hyva gives you, and how to roll a policy out without taking down checkout.

What Content Security Policy actually enforces

A Content Security Policy is delivered as an HTTP response header, Content-Security-Policy, that lists allowed sources per resource type through directives like script-src, style-src, and font-src. When a page tries to load or execute something outside those allowances, the browser refuses and logs a violation. The MDN guide to CSP is the canonical reference for the directive syntax.

Two keywords decide how much pain a policy causes on a JavaScript-heavy storefront:

• unsafe-inline allows inline <script> blocks and inline event handlers. A strict policy omits it, so every inline script must instead carry a per-request nonce or match a SHA hash the header already trusts.
• unsafe-eval allows eval() and the Function constructor. A strict policy omits it too. This is the one that quietly breaks Hyva, because standard Alpine.js compiles attribute expressions with the Function constructor at runtime.

The point of dropping both keywords is to make cross-site scripting far harder: an attacker who injects a <script> cannot run it without a nonce your server never issued for it. That protection is why the payment card industry now requires it, and why this stopped being optional.

Why 2026 forced this: PCI DSS 4.0 and the Magento default

Two things changed the timeline. First, PCI DSS 4.0 requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025, and they require merchants to manage and monitor every script that runs on a payment page. A strict CSP with an allowlist and violation reporting is the most direct way to satisfy them. This is the same compliance pressure covered in Bemeir’s Adobe Commerce security and PCI DSS runbook.

Second, Adobe moved first. In Adobe Commerce and Magento Open Source 2.4.7 and later, CSP runs in restrict mode by default on payment pages in both the storefront and the admin, and in report-only mode everywhere else. In practice that means a stock 2.4.7 checkout is already refusing un-nonced inline scripts, which is why merchants who upgrade and skip CSP work suddenly see broken third-party payment scripts from providers like Klarna or Google Pay. The Magento_Csp module is what enforces all of this.

The Hyva problem: your whole frontend is inline Alpine

On Luma, most JavaScript is loaded as external files through RequireJS, so a strict script-src 'self' covers most of it and you mainly whitelist a handful of third-party domains. Hyva is the opposite. Hyva replaced RequireJS, Knockout, and jQuery with inline Alpine.js and native JavaScript, which is why it is fast, and that shift is described in Bemeir’s guide on moving from Knockout to Alpine on Hyva.

That inline model collides with strict CSP in two places:

1. Inline <script> blocks in .phtml templates need a nonce or hash, or the browser drops them.
2. Alpine attribute expressions such as x-data="{ open: false }" and :class="{ 'hidden': !open }" are evaluated with the Function constructor, which unsafe-eval blocks. Without unsafe-eval, standard Alpine simply stops working.

So on Hyva you cannot treat CSP as a whitelist exercise. You have to change how the frontend evaluates expressions.

Hyva’s answer, part one: the Alpine CSP build

Hyva ships an Alpine CSP build, a special build of Alpine.js that runs without the unsafe-eval directive. Per the Hyva CSP compatibility docs, it does not evaluate JavaScript expressions inside HTML attributes at all. Instead, every binding must reference a property or method that a component defined ahead of time.

That means refactoring inline expressions into registered components:

• x-data="{ open: false }" becomes x-data="dropdown", with the state and methods declared through Alpine.data('dropdown', () => ({ open: false, toggle() { this.open = !this.open } })).
• :class="{ 'hidden': !open }" cannot negate inline. It becomes :class="hiddenClass", where hiddenClass is a getter on the component.
• Method calls with arguments and inline mutations move into named methods too.

There is no CSP build of Alpine v2, so any theme still on Alpine v2 has to move to v3 before this is even possible. The Hyva Alpine CSP guide ships a migration checklist and a tool to help find the expressions that need rewriting. This is real work on a heavily customized theme, and it is the part every generic Magento CSP article omits.

Hyva’s answer, part two: the hyvaCsp helper

For the inline <script> blocks that remain, Hyva gives you a template variable, $hyvaCsp, available only inside Hyva theme templates and not on Luma. You authorize an inline script by calling $hyvaCsp->registerInlineScript() immediately after the closing </script> tag, with no HTML between the tag and the call, because the helper hashes the script content that directly precedes it. There is a matching registerInlineStyle() for inline styles.

Under the hood Hyva uses a dual strategy: it issues a nonce on uncached pages and falls back to a SHA-256 hash on pages served from full page cache, where a per-request nonce is impossible because the HTML is shared across visitors. That cache-aware split is the detail that makes CSP survive Varnish, and it connects directly to how full page cache and Varnish behave on Hyva.

Whitelisting the third parties: csp_whitelist.xml

External domains still need to be allowed. You do that with a csp_whitelist.xml file in a custom module’s etc/ folder, adding each host to the relevant policy:

<?xml version="1.0"?>
<csp_whitelist>
  <policies>
    <policy id="script-src">
      <values>
        <value id="google_analytics" type="host">https://www.googletagmanager.com</value>
      </values>
    </policy>
  </policies>
</csp_whitelist>

Each value needs a unique id and a type, usually host. This is where analytics, tag managers, payment SDKs, chat widgets, and personalization scripts get their allowances. Keep the list in your own module rather than editing vendor files, the same discipline covered in Bemeir’s guide to Composer and dependency management on Magento.

The rollout: report-only first, restrict second

The reason CSP takes down storefronts is that teams flip to restrict mode before they know what they are blocking. Do the opposite. Magento’s Magento_Csp module supports a report-only mode per area, controlled through the CSP configuration group under Stores, so you can run a strict policy that reports violations without enforcing them.

The sequence that keeps you live:

Point the policy’s report directive at an endpoint you actually read, whether that is Magento’s own reporting or an external collector, because report-only is worthless if nobody triages the reports. Reserve a full restrict rollout for after checkout has been enforced and stable, since checkout is where a mistake costs orders directly.

What breaks, and the honest cost

Expect three categories of breakage. Un-nonced inline scripts from older extensions fail first, and many still assume unsafe-inline. Visual-editor tools, some A/B testing platforms, and tag managers that inject scripts after load will not run, because strict CSP refuses scripts inserted into the DOM after the initial page load even with a valid nonce. And any customization still using standard Alpine expressions stops working until it is ported to the CSP build.

The realistic scope on a customized Hyva storefront is measured in developer days, not hours: an audit of inline scripts and third-party domains, an Alpine expression migration, gateway and extension testing, and a staged rollout. It is exactly the kind of work a specialist Hyva development team scopes as a defined project rather than a config toggle, and it is worth handling before a PCI assessment rather than during one.

Where this fits with the rest of your stack

CSP is one slice of storefront security and compliance. If you are on Adobe Commerce, it sits alongside the platform hardening in Bemeir’s broader Magento and Adobe Commerce engineering practice. Bemeir is the first US-based Hyva Gold Partner, and you can see the team and its approach on the about Bemeir page and its technology partner ecosystem.

The same CSP and PCI pressure applies no matter the platform. Merchants running Shopify and Shopify Plus handle script governance inside a hosted checkout, while those on BigCommerce or Shopware face their own versions of the same allowlist discipline. On Magento and Hyva you own more of it, which is the tradeoff for owning the frontend.

Frequently asked questions

Does a strict CSP slow down a Hyva storefront?

No. A Content Security Policy is a response header the browser evaluates, and it adds no server rendering cost and no measurable client cost. The Alpine CSP build is a comparable size to standard Alpine. The performance risk is indirect: if a policy breaks a script your storefront depends on, that failure can degrade the experience, which is why the report-only rollout matters.

Do I have to migrate to the Alpine CSP build to be PCI compliant?

Not necessarily for the whole storefront, because PCI DSS 4.0 requirements 6.4.3 and 11.6.1 target payment pages specifically. You can enforce strict CSP on checkout while leaving the rest of the storefront in report-only mode. Hyva also documents a path to make Hyva Checkout CSP-compliant without converting your entire theme, which is a common phased approach.

Will strict CSP break my third-party extensions?

Some of them, yes. Extensions that print un-nonced inline scripts, or that rely on eval, will fail under strict CSP until they are updated or wrapped. This is one more reason to keep a tight extension inventory and to run report-only long enough to catch every violation before enforcing.

What is the difference between report-only and restrict mode?

Report-only mode sends the policy and logs violations but lets everything run, so nothing breaks while you gather data. Restrict mode enforces the policy and blocks anything not allowed. Adobe Commerce 2.4.7 ships restrict mode on payment pages and report-only elsewhere by default, and the correct rollout is to expand restrict mode outward from checkout only after the reports are clean.

Can I add a CSP with a meta tag instead of a header?

CSP can be delivered by a <meta> element, but on Magento the header approach through the Magento_Csp module is the supported path, because it handles nonces, hashes, and the whitelist consistently across cached and uncached pages. Hand-rolling a meta-tag policy on top of Hyva’s inline model tends to fight the framework rather than work with it.