Web applications are the most common attack surface for cardholder data compromise. SQL injection, cross-site scripting, broken authentication, and JavaScript skimming — all target application-layer vulnerabilities. PCI DSS Requirement 6 addresses web application security through a dual-track approach: securing the development process so vulnerabilities are not introduced, and deploying runtime controls (WAFs) to detect and block exploitation attempts.
The Secure Development Lifecycle for PCI DSS
Security Training for Developers
All developers building or maintaining payment applications must receive annual security training covering: common vulnerability types (OWASP Top 10), secure coding practices relevant to their language and framework, threat modeling for payment features, and how to use security testing tools. Training must be documented with completion records.
Pre-Deployment Security Testing
All payment applications and significant changes must undergo security testing before production deployment. Required testing: code review for security vulnerabilities (manual review, SAST, or both), dynamic application security testing (DAST) on a test instance, and resolution of all high and critical vulnerabilities before go-live. Testing results and remediation evidence must be retained.
| KEY IDEA | The difference between static application security testing (SAST) and dynamic application security testing (DAST) is important for PCI DSS. SAST analyzes source code for vulnerability patterns — effective for catching injection flaws and insecure configurations before the application is running. DAST tests the running application from the outside — effective for catching authentication issues, access control failures, and input validation problems. PCI DSS Requirement 6 requires both types of security testing in the SDL. |
OWASP Top 10 in the PCI DSS Context
| OWASP Risk | PCI DSS Relevance | Key Prevention Controls | Req Ref |
|---|---|---|---|
| Injection (SQL, Command) | Direct cardholder data theft via database access | Parameterized queries; input validation; WAF rules | Req 6.2 |
| Broken Authentication | Session hijacking; unauthorized CDE access | Secure session management; MFA; account lockout | Req 8 |
| Sensitive Data Exposure | PAN in API responses, logs, or URLs | Encryption in transit; output masking; log filtering | Req 3, 4 |
| XML External Entities (XXE) | Server-side request forgery; data exfiltration | Disable external entity processing; WAF protection | Req 6.2 |
| Broken Access Control | Horizontal/vertical privilege escalation to CHD | Server-side access checks; least privilege | Req 7 |
| Security Misconfiguration | Default credentials; unnecessary features; verbose error messages | Hardening standards; configuration review | Req 2, 6 |
| Cross-Site Scripting (XSS) | Cookie theft; form hijacking; skimming injection vector | Output encoding; CSP headers; WAF rules | Req 6.4 |
| Insecure Deserialization | Remote code execution on payment servers | Input validation; integrity checks; WAF rules | Req 6.2 |
| Known Vulnerable Components | Exploitation of unpatched libraries/frameworks | Dependency scanning; patch management | Req 6.3 |
| Insufficient Logging | Undetected compromise; inability to investigate | Application-level audit logging; SIEM integration | Req 10 |
Web Application Firewall (WAF) Requirements
When a WAF Is Required
All public-facing web applications that handle cardholder data must be protected by either: (1) a Web Application Firewall (WAF), or (2) a documented application vulnerability assessment performed by a qualified specialist, with all vulnerabilities resolved. For most organizations, a WAF is the more practical approach.
WAF Configuration for PCI DSS
WAF minimum requirements: OWASP Top 10 rule coverage, PCI DSS-specific rules (injection, XSS, session hijacking, enumeration), configured in block mode (not just detect/log mode), rule updates maintained (vendor-managed or self-managed with defined frequency), and logging of all blocked requests for SIEM correlation.
| WAF Option | Type | Key Features | Indonesian Availability |
|---|---|---|---|
| AWS WAF | Cloud-native WAF | Managed rule groups, rate limiting, custom rules, CloudFront integration | Available in all AWS regions including ap-southeast-3 Jakarta |
| Cloudflare WAF | CDN-integrated WAF | OWASP managed rules, bot management, Indonesian latency advantage via Cloudflare's Jakarta PoP | Global CDN with Jakarta presence |
| ModSecurity + OWASP CRS | Open-source WAF | Highly configurable; OWASP Core Rule Set; NGINX/Apache/IIS integration | Self-hosted — available anywhere |
| Azure Front Door WAF | Cloud-native WAF | Managed rule sets, bot protection, DDoS integration | Azure Southeast Asia region |
| F5 BIG-IP ASM | Hardware/Virtual appliance | Advanced application security, L7 load balancing, mature PCI DSS rulesets | Available through Indonesian F5 partners |
Payment Page Script Security (Requirement 6.4.3)
The Requirement
All scripts loaded on payment pages — including scripts loaded by other scripts — must be: inventoried (maintained list of all authorized scripts), authorized (business justification for each script's presence on the payment page), and verified for integrity (mechanism to detect unauthorized changes or additions).
Implementation Approaches
Subresource Integrity (SRI): add integrity attributes to script tags, containing a cryptographic hash of the expected script content. If the script content changes, the browser blocks execution. Works for scripts loaded from external CDNs. Content Security Policy (CSP): HTTP header that defines which script sources are allowed to execute on the page. Strict CSP blocks inline scripts and limits script loading to approved domains. JavaScript monitoring platforms: commercial solutions (Featurespace, Jscrambler, PerimeterX) that monitor payment page script execution in real-time, alerting on unauthorized additions.
| IMPORTANT | The SRI and CSP approach to Requirement 6.4.3 has a practical limitation: they protect against script changes, but managing the SRI hashes and CSP policy requires a process for updating them when legitimate scripts change (library updates, PSP updates). Build a script update process that tests SRI hashes and CSP policy in a staging environment before production deployment. |
| Indonesian e-commerce merchants who use Google Tag Manager (GTM) on their payment pages face a specific challenge with Requirement 6.4.3: GTM dynamically loads scripts, making it difficult to maintain a static inventory. The recommended approach is to either remove GTM from payment pages and use static script tags, or use a GTM account with restricted access (no external contributors) and document all tags in the script inventory. | |