Magento Open Source PCI DSS compliance

A Content Security Policy (CSP) is a set of instructions sent with a page that tells the browser which sources of scripts, frames and outbound connections are allowed to run or load. Anything not on the list is blocked, and the browser can report the attempt. On a Magento Open Source payment page, this matters because the most damaging attack against a self-hosted store is card skimming through injected JavaScript. A script added by a compromised extension, a tampered theme file or a rogue tag can read card data typed into the checkout form, and the store's server logs will show nothing unusual. A CSP is one of the few controls that limits which scripts a browser will execute on the page, regardless of how the script got into the HTML.

The practical work starts with an inventory. List every legitimate script, frame and connection source on the checkout and payment pages: the payment provider's hosted fields or script, the theme's own assets, analytics and tag manager containers, fraud or device-profiling services, and any chat or review widgets. Ask the payment provider for the exact domains it requires, and confirm whether its scripts load further resources from other hosts. Each extension that renders on checkout should also be traced to its script origins. Keep this list in the change record, because the assessor will ask how the policy was derived and who approved each source.

Build the policy in report-only mode first. In this mode the browser reports violations to an endpoint but does not block anything, so the team can see what the storefront actually loads before enforcement can break checkout. Review the violation reports for several full checkout cycles, including guest checkout, saved cards, coupon use and any multi-step payment flow. Each report should be classed as a missing legitimate source (add it with an owner and reason), an unexpected source (investigate it as a possible compromise or unapproved extension) or noise from browser extensions. Only move to enforcement once the unexpected sources are explained and the legitimate list is stable.

Inline scripts from extensions are the usual obstacle. Many extensions print inline JavaScript into checkout templates, which a strict policy blocks unless the script carries an approved nonce or hash. Do not respond by allowing all inline script, because that removes most of the protection. Instead, list each extension that injects inline code on payment pages, ask the vendor whether it supports nonce-based output, and decide whether to replace it, move the code into a reviewed module file or accept a documented exception. Magento Open Source supports CSP headers from version 2.3.5, and Adobe's developer documentation states that from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. Verify these defaults on the installed version and check how your configuration overrides them before relying on them.

For the payment page script requirements in PCI DSS, the relevant control concerns managing scripts that run on payment pages so that unauthorized script changes are detected or prevented. Confirm the requirement identifiers, the scope of the pages covered and the evidence the assessor expects, such as the approved script inventory, the policy configuration, change records and violation review logs, before you finalize the approach. The assessor's expectations decide what must be retained, so raise this with them early rather than after the policy is live.

Before an assessor arrives, the store team should run its own checks against the claims the evidence will make. The first check is the payment page itself. In a clean browser session with no cached assets or leftover extensions, load the checkout and the admin payment pages and confirm that card fields are served from the payment provider's domain, not from the store's own host or a third-party script domain. Then review the Content Security Policy violation reports for those same pages. Magento Open Source supports CSP headers from 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages, so a violation during testing usually means a script or frame source was never added to the allowlist. Each violation should be either fixed or explained in writing before the assessment. Next, test the transaction paths end to end on a non-production environment with the payment provider's test cards. Run a successful payment, a declined payment, a timeout, and a redirect back from a hosted payment page for each payment method you accept. For each path, confirm the order status, the customer message and the admin view match what you expect. Then search for card data where it should never appear. Check application logs, web server access and error logs, database tables that store quotes, orders and payment additional information, and the rendered error pages. A test card number that shows up in any of those places is a finding you need to fix before the assessor sees it. Keep the test scripts and their results, since they become part of the evidence. The evidence package is where most stores lose time. Assessors typically ask for network and data flow diagrams that show where card data enters, moves and stops, a scope inventory that lists every system in the cardholder data environment and every system connected to it, configuration exports for the web server, PHP, Magento and the payment integration, and change records for each patch, customization and script change. They also ask for the admin access list with roles, a vulnerability scan and penetration test report where the scope requires one, and a written responsibility matrix for any hosting provider. Confirm that the patched Magento version matches a supported combination of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx on the vendor's system requirements page, because a patched store running an unsupported combination is hard to defend. DeployOpen can run the security testing described above, and it can prepare the diagrams, scope inventory, configuration exports, change records and responsibility matrix as part of a written scope. Scope, deliverables and timelines are agreed in writing before work starts. The assessor, not DeployOpen, reviews this evidence, issues the findings and any attestation. Ask your assessor early which artifacts they want in which format, and confirm with them whether a penetration test or scan is required for your scope, so the testing you commission matches what they will accept.

Scope stays small only if the store team repeats a short set of checks every time the store changes. The most important is re-running the scope inventory after each extension install, theme change, payment configuration edit or new third-party script. Each of those can add a system that touches cardholder data, a new script on the checkout or payment pages, or a new route for data to leave the store. Record which components were checked, who checked them and what the result was, so the assessor sees a current picture rather than the one from go-live. Content Security Policy needs the same discipline. Adobe's developer documentation says CSP headers are supported from 2.3.5 and that from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. Any change to a payment provider, analytics tag, tag manager or chat widget can break checkout or open a hole in the policy. Review the allowed sources after each such change, test the checkout in a staging environment, and keep the policy file under version control alongside the change ticket that justified it. Patching is the other recurring duty. Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant, and its release schedule says a full patch for the 2.4.x LTS line ships annually in May with security patches at least annually for supported lines. Each patch cycle should be followed by a retest of the checkout flow, including the hosted payment fields, the 3-D Secure step and the order confirmation email, because a core patch can change JavaScript loading order even when no custom code changed. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the drivers of upgrade effort. Each extension and each custom change on the payment path adds code that must be retested after every patch. Keeping payment logic in isolated custom modules that follow the PSR-4 structure Adobe describes limits what has to be retested, because changes to catalog, theme or marketing modules do not touch the payment code path. Ask the implementation partner to document which modules are in scope and which are not, and review that list at each release. Finally, the store team should review admin accounts and access on a quarterly cycle, remove accounts that are no longer needed, confirm two-factor authentication is enforced for every administrator, and review logs for card data leakage such as full primary account numbers appearing in error messages, debug output or support tickets. Hand the routine items (scope inventory updates, access reviews, log sampling and change records) to the internal operations team with a written runbook. Retain a retainer for patch application, upgrade testing, CSP rework and assessor evidence preparation, since these need specialist review and recur on a schedule the team should confirm in its own contract.