Blog > PCI DSS Web Application Security Requirements

PCI DSS Web Application Security Requirements: What You Need to Test

Published: June 2026 · 11 min read

If your application handles payment card data, PCI DSS sets specific requirements for how you must test its security. PCI DSS 4.0, which became fully effective in 2024, strengthened the web application security requirements considerably compared to earlier versions.

This guide explains what PCI DSS actually requires for web application security, which requirements apply to application-layer testing, and how to structure your testing program to satisfy both the letter of compliance and the spirit of it.

Scope: What PCI DSS Covers

PCI DSS applies to any system that stores, processes, or transmits cardholder data (CHD) or is connected to the cardholder data environment (CDE). Web applications that:

...are all in scope. If you use a third-party payment processor with iframes or redirects, your scope may be narrower — but the application that hosts the checkout page still has requirements to meet.

The Core Requirements for Web Application Security

Requirement 6.2 — Bespoke and Custom Software Security

Requirement 6.2 mandates secure development practices. For AppSec teams, the relevant sub-requirements are:

Sub-req What it requires
6.2.4 Software engineering techniques or other methods defined to prevent or mitigate common software attacks — injection attacks, attacks on data and data structures, attacks on cryptography
6.2.4.a Processes must be defined to address attacks including: injection flaws (SQL, LDAP, XPath, other), broken authentication, cryptographic failures, injection via parameter manipulation, improper error handling, cross-site scripting

In practice, 6.2.4 requires that your development process includes controls addressing the OWASP Top 10 categories — code review, SAST, developer training, or equivalent.

Requirement 6.3 — Security Vulnerabilities Are Identified and Addressed

This is the vulnerability management requirement. 6.3.2 mandates an inventory of all bespoke software and third-party software. The critical sub-requirement for testing:

Sub-req What it requires Frequency
6.3.3 All software components are protected from known vulnerabilities Ongoing
6.3.3.b Security patches installed within one month of release for critical vulnerabilities Within 1 month

Requirement 6.4 — Public-Facing Web Applications Are Protected

This is where the testing requirements become most specific. For any web application in the CDE that is publicly accessible:

Sub-req Requirement
6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis via automated technical solutions (DAST tools, vulnerability scanners) OR a web application firewall
6.4.2 Automated technical solution (DAST) performs the scanning
6.4.3 All payment page scripts that are loaded and executed in the consumer's browser are managed per specific requirements (inventory, authorization, integrity)

6.4.1 gives you a choice: continuous automated scanning OR a WAF. In practice, most organizations implement both — a WAF for runtime protection and DAST scanning to find vulnerabilities before they're exploited.

Requirement 11.3 — Penetration Testing

Requirement 11.3 is the explicit penetration testing requirement. It specifies:

Sub-req Requirement Frequency
11.3.1 External and internal penetration testing is performed at least once every 12 months and after significant changes Annual + after changes
11.3.1.1 Penetration testing of network segmentation is performed at least every 6 months Semi-annual
11.3.1.2 Penetration testing covers the CDE perimeter and critical systems Annual
11.3.2 All exploitable vulnerabilities found are corrected and testing repeated to verify correction After findings

What PCI DSS Penetration Testing Must Cover

Requirement 11.3.1 specifies that penetration testing must include:

The Penetration Testing Guidance published by the PCI SSC provides additional specifics on methodology. It recommends testing against OWASP categories as a minimum baseline for application-layer testing.

Requirement 11.3 "After Significant Changes" — What Counts?

The "after significant changes" clause is where organizations frequently fall short. PCI DSS defines significant changes to include:

For most active development teams, "after significant changes" effectively means continuous testing. An annual pentest followed by 11 months of untested deployments does not satisfy the intent of 11.3.1 for organizations deploying code frequently.

This is why the PCI SSC updated 6.4.1 in PCI DSS 4.0 to explicitly require automated technical solutions for ongoing scanning — recognizing that annual manual testing is insufficient for modern development cycles.

Requirement 6.4.3 — Payment Page Script Integrity

6.4.3 is new in PCI DSS 4.0 and specifically targets supply chain attacks on payment pages (Magecart-style attacks). It requires:

<!-- SRI example: verify script has not been modified -->
<script src="https://cdn.payment-provider.com/v3/checkout.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxXhSCFEkWooo8WDLQ9fo5Gl3ZDz"
        crossorigin="anonymous"></script>

<!-- CSP header to restrict which scripts can load -->
Content-Security-Policy: script-src 'self' 'sha384-...' https://cdn.payment-provider.com;
                          default-src 'none';

Testing for 6.4.3 compliance:

  1. Load the payment page and inspect all scripts that execute (browser DevTools → Network → JS)
  2. Compare to the authorized script inventory
  3. Verify SRI hashes are present on external scripts
  4. Check Content-Security-Policy headers restrict script loading
  5. Look for inline scripts that could be injection vectors

Vulnerability Scanning Requirements (Requirement 11.2)

Requirement 11.2 covers vulnerability scanning (distinct from penetration testing):

Requirement Scope Frequency
11.2.1 Internal vulnerability scans At least quarterly + after significant changes
11.2.2 External vulnerability scans via ASV (Approved Scanning Vendor) Quarterly

External scans must be conducted by a PCI SSC Approved Scanning Vendor (ASV). Internal scans can be conducted with your own tooling. Neither replaces penetration testing — they are additive requirements.

Mapping Testing Activities to Requirements

Activity Satisfies Frequency
Annual penetration test (application layer) 11.3.1, 11.3.1.2 Annual
Penetration test after major releases 11.3.1 (significant changes clause) Per release
Segmentation test 11.3.1.1 Semi-annual
Internal vulnerability scan 11.2.1 Quarterly
External ASV scan 11.2.2 Quarterly
Automated DAST scanning 6.4.1, 6.4.2 Continuous
Payment page script audit 6.4.3 Continuous + per change
Third-party component inventory 6.3.2, 6.3.3 Continuous

Common PCI DSS Testing Program Gaps

In practice, PCI audits commonly find these gaps in web application security testing programs:

Automated Scanning and PCI DSS Compliance

Requirement 6.4.1 explicitly references "automated technical solutions" for ongoing protection of public-facing web applications. DAST tools that scan continuously or on each deployment satisfy this requirement and provide evidence for auditors.

The practical argument for continuous DAST over a single annual scan is straightforward: PCI DSS requires testing after significant changes. If you deploy weekly and each deployment is a significant change, you need weekly testing — or continuous scanning that catches new vulnerabilities as they're introduced.

Meet PCI DSS 6.4 with continuous automated scanning. Ironimo provides DAST scanning using real Kali Linux tools on schedule or on demand — building the evidence trail auditors need and catching vulnerabilities before your next QSA assessment. No pentester invoice for every deployment.

Start free scan

Key Takeaways

Related guides

← Back to Blog