CSP is used by browsers to minimize certain security attacks. It uses HTTP headers to identify a certain policy (reporting mode or restrictive mode) and values that identify certain browser resources that could or could not be used. If you are implementing CSP, security gets tighter but it might also be that specific scripts you are using are no longer usable.
Read more: developer.mozilla.org/en-US/docs/Web/HTTP/CSP
Magento could be tuned to facilitate compliance with PCI DSS v4.4 . This involves two things (to the least):
nonce or if their SHA hash is added to the HTTP headers. This policy requires that unsafe-inline is not present in the CSP headers.eval function - which is used by various libraries like KnockoutJS, jQuery UI, AlpineJS and LivewireJS - is no longer allowed. This policy requires that unsafe-eval is not present in the CSP headers.As you can read, the second point poses a problem, because both Luma and Hyvä do use some of the libraries mentioned above. Because of this, action is required.
Within Magento 2.4.7 checkout pages, CSP is by default in the restrictive mode. You could disable this again by enabling the reporting mode:
magerun2 config:store:set csp/mode/storefront_checkout_index_index/report_only 1
In this document, we assume that the reporting mode is disabled, so that the restrictive mode is enabled:
magerun2 config:store:set csp/mode/storefront_checkout_index_index/report_only 0
By default in Magento, the CSP policies unsafe-inline and unsafe-eval are added, allowing inline scripts without hashes or nonces, allowing the evil eval() function. Because any module is able to override these settings, it is the duty of the webshop maintainer to double-check the current policies. You can inspect the HTTP headers manually in the browser. Or, if you find this harder to read, you might also opt for the Yireo_CspInspector module.
bin/magento csp:inspect:policy script-src
The good news is that Loki Checkout and its sub-extensions (with a few exceptions - see the known issues below) are compliant with PCI DSS v4, meaning that the code does not depend on unsafe-inline or unsafe-eval.
Removing the policy unsafe-inline is enforced by implementing the additional module Yireo_CspUtilities which is then used by the Loki Checkout extensions to add either a SHA hash to the headers or add a nonce to the script tag (whatever you configure in the Yireo_CspUtilities module).
Removing the policy unsafe-eval is implemented by simply not writing any eval code. With vanilla JavaScript, this is pretty evident. Loki Components and Loki Checkout use AlpineJS. To make sure AlpineJS doesn't use eval anymore, you need to be using the AlpineJS CSP Build. One way to do this is to enable the Yireo_LokiCheckoutCsp module (see below).
Having a checkout extension that is CSP-compiant is not enough. First of all, the checkout extension lives within your theme (Luma or Hyvä) which also needs to be CSP-compliant. Second, you need to enable the right CSP policies.
Adding the right policies could be done manually or by adding the Yireo_LokiCheckoutCsp module (see below).
For the theme, the responsibility lies with the theme creator or the agency implementing it - not us, we are merely just an extension vendor.
With Hyvä, there is going to be a CSP-compliant build of Hyvä (which ships with the AlpineJS CSP Build and upgrades all scripts). Contact Hyvä for the status. One workaround in the mean time is to just use the unsafe-eval policy anyway (which is less secure and not PCI compliant) and protect inline scripts with the Yireo_CspWhitelistInlineJs module.
With Luma, the status is unknown. While there is a plugin for KnockoutJS to become CSP-compliant, it is not supported by Adobe. The easiest thing to do here is to remove actually any dependency with KnockoutJS, RequireJS and jQuery on the checkout page. (This is something that will be documented as an experiment by us.)
Yireo_LokiCheckoutCsp modulecomposer require yireo/magento2-loki-checkout-csp
bin/magento module:enable Yireo_LokiCheckoutCsp
When you have enabled this module, there are big chances that in the checkout you are going to see a lot of errors. There is a big chance that these errors actually relate to the theme, not our extension. Normally, you can inspect from which HTML part a specific error originated from. We do this analysis ourselves a lot, to make sure that CSP errors don't occur because of our own extensions.
The Yireo_LokiComponentsDebugge module makes use of an expression that is using the eval expression underneath. Because of this, the specific feature of the module (listing details of a specific registered Alpine Component) is not fully functional when you are using either the CSP restrictive mode and/or the