Drupal PCI Compliance

Building a PCI-compliant Drupal site requires careful configuration of your CMS, strategic module selection, and integration with compliant payment gateways. Whether you’re running a small e-commerce site or managing a multi-site enterprise deployment, your Drupal PCI compliance approach directly impacts both your SAQ type and the complexity of your annual assessment.

Technical Overview

Drupal’s modular architecture creates unique challenges and opportunities for PCI compliance. The CMS itself doesn’t store or process cardholder data by default, but your implementation choices determine whether you maintain SAQ A eligibility or expand into more complex compliance territory.

Your Drupal architecture typically involves multiple layers: the web server, application server, database, and third-party integrations. Each layer requires specific security controls to maintain compliance. Most importantly, your payment integration method determines your PCI scope — iframe tokenization keeps you at SAQ A, while server-side API calls expand you to SAQ A-EP or D.

From a defense-in-depth perspective, Drupal sits at your application layer. You’ll need complementary controls at the network layer (firewalls, segmentation), transport layer (TLS configuration), and data layer (database encryption). Your WAF rules must understand Drupal’s URL patterns, and your monitoring must track Drupal-specific security events.

Industry best practices extend beyond PCI requirements. The OWASP Top 10 maps directly to Drupal vulnerabilities — SQL injection through contributed modules, authentication bypass in custom code, and cross-site scripting in user-generated content. Following Drupal Security Team advisories becomes as critical as PCI compliance itself.

PCI DSS Requirements Addressed

Your Drupal implementation touches multiple PCI requirements, even in the simplest deployments. Requirement 2 mandates changing default passwords — this includes your Drupal admin account, database credentials, and any default accounts created by contributed modules.

Requirement 6 drives your development and patching processes. You must apply Drupal core updates within 30 days of security releases. Contributed modules need the same attention, though the standard acknowledges risk-based prioritization for lower-severity issues. Your custom code requires secure coding practices and regular reviews.

Requirement 8 shapes your user management. Drupal’s built-in authentication meets basic requirements, but you’ll need contributed modules or custom development for multi-factor authentication. Password policies require configuration through modules like Password Policy, enforcing complexity, history, and expiration rules the standard mandates.

Requirement 10 demands comprehensive logging. Drupal’s watchdog system provides application-level logging, but you need additional configuration to capture all required events. Failed login attempts, privilege changes, and access to sensitive data all require tracking.

Different SAQ types require different Drupal configurations. SAQ A merchants using hosted payment pages need minimal Drupal hardening — basically following security best practices. SAQ A-EP merchants using direct post or JavaScript tokenization must implement all application security requirements. SAQ D merchants processing cards through Drupal need the full control set.

Implementation Guide

Start your Drupal PCI implementation with a clean, minimal installation. Avoid distributions with unnecessary modules that expand your attack surface. Choose Drupal’s standard installation profile rather than demo-heavy alternatives.

Core Security Configuration

Enable Drupal’s built-in security features immediately:

“`php
// settings.php security hardening
$settings[‘trusted_host_patterns’] = [
‘^www.yourdomain.com$’,
‘^yourdomain.com$’,
];
$settings[‘file_private_path’] = ‘/var/www/private’;
$settings[‘allow_authorize_operations’] = FALSE;
“`

Configure your web server to protect sensitive files:

“`apache

Apache .htaccess additions

Payment Gateway Integration

Your payment integration method determines your compliance scope. For SAQ A eligibility, use hosted payment pages that completely redirect users away from your site:

“`php
// Example redirect to hosted payment page
function mymodule_payment_redirect($order) {
$gateway_url = ‘https://gateway.example.com/hosted-pay’;
$params = [
‘amount’ => $order->getTotal(),
‘order_id’ => $order->id(),
‘return_url’ => Url::fromRoute(‘mymodule.payment.return’)->toString(),
];
return new RedirectResponse($gateway_url . ‘?’ . http_build_query($params));
}
“`

For SAQ A-EP implementations using tokenization:

“`javascript
// Client-side tokenization example
PaymentGateway.tokenize({
number: document.getElementById(‘card-number’).value,
exp_month: document.getElementById(‘exp-month’).value,
exp_year: document.getElementById(‘exp-year’).value,
cvc: document.getElementById(‘cvc’).value
}, function(status, response) {
if (response.error) {
// Handle error
} else {
// Submit token to Drupal
document.getElementById(‘payment-token’).value = response.token;
document.getElementById(‘payment-form’).submit();
}
});
“`

Security Modules

Install and configure essential security modules:

Security Kit (seckit) provides CSRF protection, clickjacking defense, and XSS mitigation:
“`bash
composer require drupal/seckit
drush en seckit -y
drush config-set seckit.settings x_frame allow_from “https://paymentgateway.com”
“`

Password Policy enforces PCI-compliant password requirements:
“`bash
composer require drupal/password_policy
drush en password_policy -y

Configure through UI: /admin/config/security/password-policy

“`

Two-factor Authentication (TFA) adds required MFA:
“`bash
composer require drupal/tfa
drush en tfa -y

Configure per-role requirements

“`

Database Security

Implement database-level encryption for any locally stored sensitive data:

“`sql
— MySQL transparent data encryption
ALTER TABLE sensitive_data ENCRYPTION=’Y’;

— PostgreSQL column encryption
CREATE EXTENSION IF NOT EXISTS pgcrypto;
UPDATE sensitive_data SET field = pgp_sym_encrypt(field, ‘encryption-key’);
“`

Cloud Deployment Considerations

AWS deployments benefit from native security services:

Use RDS encryption at rest
Enable VPC flow logs for network monitoring
Configure Security Groups as host-based firewalls
Implement AWS WAF rules for Drupal-specific threats

Container deployments require additional hardening:
“`dockerfile

Dockerfile security additions

USER www-data
COPY –chown=www-data:www-data . /var/www/html
RUN find /var/www/html -type d -exec chmod 750 {} ; &&
find /var/www/html -type f -exec chmod 640 {} ;
“`

Testing and Validation

Validate your Drupal PCI implementation through systematic testing that mirrors QSA assessment methodology. Start with configuration reviews to ensure all security settings match documented standards.

Security Scanning

Configure your ASV scans to properly assess Drupal:

Exclude false positives from Drupal’s normal behavior
Include all public-facing components
Test both authenticated and unauthenticated perspectives

Run Drupal-specific security scans:
“`bash

Using Drupal Security Review module

drush secrev

Custom security audit

drush sqlq “SELECT name, mail FROM users WHERE status = 1 AND access = 0”
drush sqlq “SELECT filename FROM file_managed WHERE uri LIKE ‘%private://%'”
“`

Penetration Testing

Your penetration tests must include Drupal-specific attack vectors:

SQL injection through Views exposed filters
Privilege escalation through misconfigured permissions
File upload vulnerabilities in custom modules
Session hijacking through insecure cookies

Document remediation steps for common findings:
“`php
// Fix SQL injection in custom queries
$query = Drupal::database()->select(‘orders’, ‘o’)
->fields(‘o’, [‘order_id’, ‘total’])
->condition(‘user_id’, $user_id)
->condition(‘status’, $status)
->execute();
// Never use db_query() with concatenated user input
“`

Evidence Collection

Maintain these artifacts for your compliance file:

Drupal security update logs showing timely patching
Module inventory with security review dates
User access reviews demonstrating least privilege
Configuration exports showing security settings
Custom code review reports

Operational Maintenance

Maintaining PCI compliance requires ongoing Drupal management beyond initial implementation. Establish weekly routines for security update reviews — Drupal Security Advisories publish on Wednesdays.

Monitoring and Alerting

Configure comprehensive logging through Drupal’s database logging and syslog modules:

“`php
// Custom logging for PCI events
Drupal::logger(‘pci_audit’)->notice(‘Payment processed’, [
‘user’ => Drupal::currentUser()->getEmail(),
‘amount’ => $payment->getAmount(),
‘timestamp’ => time(),
‘ip’ => Drupal::request()->getClientIp(),
]);
“`

Set up alerts for critical events:

Failed login attempts exceeding thresholds
Administrative permission changes
File system modifications in core directories
Database structure alterations

Change Management

Every Drupal change impacts your PCI compliance. Document module additions, configuration changes, and custom development in your change control system. Test security impacts in development environments before production deployment.

Your annual review tasks include:

Reviewing and removing unnecessary modules
Auditing user permissions and roles
Validating payment gateway configurations
Testing disaster recovery procedures
Updating network diagrams with Drupal infrastructure

Troubleshooting

Common Drupal PCI compliance issues require systematic resolution. Performance degradation from security modules affects many implementations — start by profiling database queries and adjusting caching strategies.

Module conflicts create compliance gaps. When security modules interfere with payment processing, implement custom middleware to maintain both security and functionality. Document any compensating controls required for your specific configuration.

Legacy integration challenges arise with older payment modules. Rather than maintaining outdated code, implement API proxies that provide modern security while maintaining backward compatibility. Your proxy can add tokenization, logging, and encryption without modifying legacy code.

Browser compatibility issues with payment forms often trace to Content Security Policy headers. Adjust your policies to allow necessary payment gateway resources while maintaining XSS protection:

“`php
// Selective CSP relaxation for payment pages
if (Drupal::routeMatch()->getRouteName() === ‘commerce.checkout’) {
$response->headers->set(‘Content-Security-Policy’,
“default-src ‘self’ https://paymentgateway.com; ” .
“script-src ‘self’ ‘unsafe-inline’ https://paymentgateway.com; ” .
“frame-src ‘self’ https://paymentgateway.com”
);
}
“`

FAQ

Does Drupal Commerce automatically make my site PCI compliant?

No, Drupal Commerce provides e-commerce functionality but doesn’t guarantee PCI compliance. Your payment gateway integration method, security configuration, and operational procedures determine compliance. Using hosted payment pages with Commerce keeps you in SAQ A scope, while storing card data locally requires full SAQ D compliance.

How often should I update Drupal core and modules for PCI compliance?

Apply security updates within 30 days of release to meet PCI requirements. Drupal Security Advisories publish Wednesdays — establish a weekly review process. Critical vulnerabilities may require faster response based on your risk assessment.

Can I use contributed payment modules and maintain PCI compliance?

Yes, but evaluate each module’s security posture and integration method. Modules using hosted payment pages or client-side tokenization support simpler compliance. Avoid modules that process card data server-side unless you’re prepared for SAQ D requirements. Always review module code before trusting it with payment data.

What logging must I enable in Drupal for PCI compliance?

Enable logging for all user access, authentication events, administrative actions, and payment-related activities. Use Drupal’s database logging for application events and syslog for system-level activities. Store logs securely and retain them according to PCI requirements — typically one year with three months immediately available.

Do I need a WAF in front of my Drupal site?

While not explicitly required for all SAQ types, a properly configured WAF significantly strengthens your security posture. Configure rules specific to Drupal’s URL patterns and common attack vectors. Many QSAs view WAF implementation as a best practice that demonstrates security maturity.

Conclusion

Drupal PCI compliance requires thoughtful architecture decisions, careful module selection, and ongoing security management. Your payment integration method drives your compliance scope — choose hosted payment pages for simplicity or implement proper controls for more integrated approaches. Regular patching, comprehensive logging, and systematic testing keep your Drupal deployment secure and compliant year-round.

Remember that PCI compliance extends beyond technical implementation. PCICompliance.com gives you everything you need to achieve and maintain PCI compliance — our free SAQ Wizard identifies exactly which questionnaire you need, our ASV scanning service handles your quarterly vulnerability scans, and our compliance dashboard tracks your progress year-round. Whether you’re building your first Drupal e-commerce site or securing a multi-site deployment, having the right tools and guidance makes compliance achievable.