Skip to content

CSP and Magento

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.

Covering Content Security Policies completely is beyond the scope of the Hyvä documentation.
Please refer to our blog post What is CSP and why should I care? for a brief introduction.

From a Hyvä developers point of view, of most consequence is that the CSP policies unsafe-eval and unsafe-inline have to be disallowed on specific pages, starting 1. April 2025 (no April Fools' joke).

Why is PCI-DSS becoming more strict?

Most online credit card skimming no longer happens on forms served by a hacked server since merchants use payment service providers that redirect the customer to their site during the payment process or serve forms from the provider's servers in an iframe.

Nowadays customers are redirected by injected code to a fake phishing site, that looks just like the selected payment service provider, and then, after they enter the payment credentials, they are forwarded to the real site, without the customers noticing.

To protect customers against this attack, PCI-DSS will require online shops to be more secure than before, even if the payment forms are served from a payment service provider server via redirect or an iframe.

It is not clear exactly which pages require strict CSP. The specification states:

6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser

It is not clear if this applies only to the checkout or whether it also applies to pages with in-context payment buttons like PayPal Express.

The PCI DSS 4.0.1 Self Assessment Questionnaire (SAQ-A) does not clarify either. It contains no questions in paragraph 6.4.3.
However, it does note:

For SAQ A, Requirement 6 applies to merchant server(s) with a webpage that either 1) redirects customers from the merchant webpage to a TPSP/payment processor for payment processing (for example, with a URL redirect) or 2) includes a TPSP’s/payment processor’s embedded payment page/form (for example, one or more inline frames or iframes).

Likely other factors will also play a role, but which ones we can only guess.
Possible candidates are

  • the country the merchant is based in
  • the goods they are selling
  • the security history track record of the merchant and the host
  • the payment service provider

Every merchant is responsible for evaluating which measures they need to implement, and then following the appropriate PCI-DSS protocol in order to be compliant.

This can not be done by Hyvä.
However, we will release a version of Hyvä Theme and of Hyvä Checkout that are strict CSP-compatible, but probably not every merchant has to use strict CSP for their whole site.

Merchants may decide to implement only a redirect payment option, or only a strict CSP checkout, or a strict CSP checkout with redirect in-context payment buttons, or full theme compatibility.