The Content Security Policy (CSP) header is a critical component for achieving PCI DSS compliance, particularly for payment pages, as it helps meet requirements for authorizing and ensuring the integrity of scripts. In modern e-commerce environments, especially when using Drupal Commerce, implementing robust CSP rules is not just a best practice. It’s a requirement for maintaining customer trust and meeting security standards.
What is PCI DSS?
PCI DSS (Payment Card Industry Data Security Standard) is a global set of security requirements designed to ensure that all organizations handling credit card data maintain a secure environment. Version 4.0 strengthens requirements around web application security, emphasizing measures to protect against client-side attacks like cross-site scripting (XSS) and unauthorized script execution.
What is CSP?
A Content Security Policy is an HTTP response header that controls which resources (such as JavaScript, CSS, images, or fonts) a web page is allowed to load. By defining strict rules for where scripts and other assets can originate, CSP reduces the risk of malicious content execution in browsers.
Why CSP Matters for Drupal Commerce and PCI DSS?
In a Drupal Commerce site handling online payments, attackers can target checkout or payment pages with injected scripts to capture sensitive payment details. PCI DSS specifically addresses this risk, requiring site owners to: Authorize all scripts running on payment pages. Ensure the integrity of these scripts through mechanisms like nonces or hashes. Implement policies that prevent unauthorized script execution. A properly configured CSP header ensures only trusted scripts are executed, blocking any unauthorized or tampered scripts. This directly supports PCI DSS requirements for protecting payment page integrity.
Implementing CSP in Drupal with the Security Kit Module
Drupal provides the Security Kit module, which offers a simple way to configure CSP headers directly within your site’s admin interface or via custom module code. This module supports: Adding nonces automatically to scripts. Defining CSP rules (script-src, script-src-elem, etc.). Sending violation reports to a specified endpoint.
Most Important CSP Directives for PCI DSS
-
script-src: (Critical for PCI DSS)
-
default-src: (Important baseline)
-
frame-ancestors: (Anti-clickjacking, PCI DSS requirement)
-
Purpose: Controls which sites can embed your pages in <iframe>, <frame>, <object>, etc.
-
PCI DSS relevance: Protects payment pages from being embedded into malicious overlays.
-
Best practice:
frame-ancestors 'self' https://trusted-partner.example.com;
-
object-src: (Legacy attack prevention)
-
Purpose: Restricts sources for <object>, <embed>, and <applet> elements.
-
PCI DSS relevance: Prevents the execution of untrusted plugins, which are a high-risk vector.
-
Best practice:
object-src 'none';
-
connect-src: (Protects data transfer)
-
Purpose: Controls where scripts can connect via XHR, WebSocket, EventSource.
-
PCI DSS relevance: Prevents exfiltration of sensitive cardholder data to untrusted servers.
-
Best practice:
connect-src 'self' https://api.trusted-payments.example.com;
-
report-uri: (Monitoring & incident response)
-
Purpose: Sends CSP violation reports to a specified endpoint.
-
PCI DSS relevance: Enables detection of policy violations and possible attacks.
-
Best practice:
report-uri /report-csp-violation;
- In Drupal, the Security Kit module can log these automatically.
Best Practices for Implementing CSP in Drupal Commerce
- Enable CSP Headers
Explanation: The CSP header should be sent with every page request, particularly on sensitive pages like checkout or payment.
Example:
script-src 'self' 'nonce-{nonce-value}'; object-src 'none';
- Use Nonces or Hashes for Inline Scripts
Explanation: PCI DSS requires verifying script integrity. Nonces are random values generated per request, while hashes verify fixed script content. Example:
Content-Security-Policy: script-src 'self' 'nonce-xYz123';
- Whitelist Trusted Domains
Explanation: Explicitly allow only the domains you trust for loading external scripts. Example:
Content-Security-Policy: script-src 'self' 'nonce-{nonce}' https://secure.paymentgateway.com https://www.googletagmanager.com;
- Use strict-dynamic for Modern Browsers
Explanation: strict-dynamic lets scripts that are loaded by trusted nonce’d scripts run without needing their nonce.
Example:
Content-Security-Policy: script-src 'nonce-{nonce}' 'strict-dynamic' https:;
- Apply Stricter Policies on Payment Pages
Explanation: Checkout and payment pages should have tighter CSP restrictions.
Example:
Content-Security-Policy: script-src 'self' 'nonce-{nonce}' https://secure.paymentgateway.com; object-src 'none';
- Monitor CSP Violation Reports
Explanation: Use CSP’s reporting feature to track violations in real time.
Example:
Content-Security-Policy: script-src 'nonce-{nonce}' 'self'; report-uri /csp-report-endpoint;
Example CSP Header for a Drupal Commerce Payment Page
Content-Security-Policy: script-src 'nonce-{generated-nonce}' 'strict-dynamic' https://secure.paymentgateway.com https://www.googletagmanager.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none';
Conclusion
Implementing CSP headers in Drupal Commerce is an essential step toward meeting PCI DSS compliance. Using Drupal’s Security Kit module, site owners can configure robust CSP rules, add nonces automatically, and protect payment pages against unauthorized scripts. By combining nonces, trusted domain whitelisting, and modern CSP directives like strict-dynamic, you can achieve strong client-side security without sacrificing site functionality.
