Skip to content

Alpine CSP

Currently Hyvä CSP is unreleased

This is a documentation preview.
Please watch the #update-notifications channel in Slack to be notified when it is available.

What is Alpine CSP

Up until release 1.3.10, Hyvä did not work with strict Content Security Policy (CSP) enabled, because Alpine requires unsafe-eval to evaluate JavaScript expressions in Alpine HTML attributes like :class="{'hidden': !open}".

There is a CSP compliant build of Alpine, however, it only supports a subset of the features regular Alpine offers. Mostly, it requires forgoing dynamic JS expressions in HTML attributes, and also some other features.
Only read access to component properties is possible. If the component property is a function, it will be executed.

This is less convenient for developers, as it requires writing many short methods, usually written as inline expressions.
On the other hand, it allows a site to be used without unsafe-eval, greatly reducing the attack surface for hackers.

Writing code compatible with Alpine and Alpine CSP

Alpine CSP offers a subset of regular Alpine. All Alpine CSP-compatible components also work in regular Alpine.

Will Hyvä switch to Alpine CSP?

Because of more strict requirements in upcoming versions of the PCI-DSS standard, Hyvä will offer an Alpine CSP-compatible version.
The deadline is 1. April 2025, at which point enabling CSP without unsave-eval on payment-related pages will be a requirement.

Hardening CSP rules in general increases a website's security. This is why Hyvä will support strict CSP policies.

Hyvä is striving to release an Alpine CSP version as soon as possible and maintain both the regular and the CSP version for the foreseeable future, to give merchants and extension vendors time to migrate their code.

This will require backward incompatible changes. Migrating components to be Alpine CSP-compatible is not hard, but it can be tedious.
We strive to make this process as pleasant as we can.

Do all pages have to use Alpine CSP?

This question can not be answered at the time of writing. The phrasing of the PCI-DSS standard is somewhat ambiguous. Time will tell how the phrase "payment-related pages" will be interpreted by QSA (Qualified Security Assessors).
We expect this to depend on many factors, for example, the payment service provider a merchant uses, the type of goods, and the country the merchant is based in.
Using in-context payment buttons like PayPal Express and similar ones may also play a role. All checkout pages will surely need to use Alpine CSP.

Will Hyvä Checkout be Alpine CSP-compatible?

Yes, Hyvä Checkout will support CSP strict mode.

Hyvä Checkout specific documentation

There is decicated documentation page for specific Hyvä Checkout changes

Writing Alpine CSP-compatible code

Writing Alpine CSP code is similar as writing regular Alpine components.

The list of differences is short:

  • Reading property values is possible, but all transformations require using a method (even negation like x-if="!open").
  • Mutations (for example open = false) are only possible in methods.
  • Calling methods is possible, but arguments have to be passed via dataset attributes (for example <div x-data="initMyComponent" data-config='{"sku":"foo-123"}'>).
  • The x-model directive does not work.

Everything else, including iteration with x-for, works the same as regular Alpine, except that the value reference in x-for must not be a method call with arguments.