PCI DSS 6.4.1: For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing

Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.4

For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:
  • At least once every 12 months and after significant changes.
  • By an entity that specializes in application security.
  • Including, at a minimum, all common software attacks in Requirement 6.2.4.
  • All vulnerabilities are ranked in accordance with requirement 6.3.1.
  • All vulnerabilities are corrected.
  • The application is re-evaluated after the corrections. OR
• Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
  • Installed in front of public-facing web applications to detect and prevent web-based attacks.
  • Actively running and up to date as applicable.
  • Generating audit logs.
  • Configured to either block web-based attacks or generate an alert that is immediately investigated.

Summary

Public-facing web applications are either assessed regularly by application security specialists, or sit behind something that continually detects and prevents web attacks.

What the assessor will examine

These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.

Procedure

6.4.1

For public-facing web applications, ensure that either one of the required methods is in place as follows: • If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed in accordance with all elements of this requirement specific to the tool/method. OR • If an automated technical solution(s) is installed that continually detects and prevents web-based attacks, examine the system configuration settings and audit logs, and interview responsible personnel to verify that the automated technical solution(s) is installed in accordance with all elements of this requirement specific to the solution(s).

Read this together with 6.4.2, because the choice is less open than it looks. 6.4.1 offers two routes: periodic assessment, or an automated technical solution in front of the application. 6.4.2 then requires that automated solution outright. So an entity meeting 6.4.2 has satisfied the second branch of 6.4.1 as a consequence, and the assessment branch becomes something you do because it is worth doing rather than because you must choose it. Where the assessment route is taken, its conditions are demanding and each is separately checkable: at least every 12 months and after significant changes, by an entity that specializes in application security, covering at minimum the attacks named in 6.2.4, ranked under 6.3.1, all vulnerabilities corrected, and the application re-evaluated afterwards.

What to prepare

• The inventory of public-facing web applications.
• Which route each is covered by, stated deliberately.
• For assessed applications: the report, the assessor's specialism, the ranking, the corrections and the re-evaluation.
• For protected applications: the evidence 6.4.2 requires.

How to implement it

1. Start from 6.4.2, since it is required anyway. Meeting it answers the second branch here and makes the assessment a choice rather than an obligation.

2. Check the specialism if you assess. "By an entity that specializes in application security" excludes a general vulnerability scan and excludes your own team unless application security is what they do.

3. Note that "all vulnerabilities are corrected" has no severity threshold, unlike the scanning controls in Requirement 11. On this route, everything found is fixed.

4. Keep the application inventory current. A public-facing application nobody listed is covered by neither route.

Where this commonly fails

• A general vulnerability scan offered as an application security assessment.
• Assessment performed annually with nothing after significant changes.
• Findings ranked and only the high ones fixed, when this route says all are corrected.
• An application exposed publicly that never reached the inventory.

Related controls

This control refers to 6.2.4.

Others in section 6.4:

Control	What it requires
6.4.2	For public-facing web applications, an automated technical solution is deployed…
6.4.3	All payment page scripts that are loaded and executed in the consumer’s browser…

---

← 6.3.3 · All controls · 6.4.2 →

Source

The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.

The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.