If your website accepts payment cards — directly or through a hosted payment page — it falls under PCI DSS (Payment Card Industry Data Security Standard). The requirements that apply to your web application depend on how your checkout is implemented, but every merchant with any web-facing component has obligations under PCI DSS 4.0. This guide explains which requirements apply to web applications, what they require technically, and how to meet them.
Which PCI DSS Requirements Apply to Web Applications
Requirement 6: Develop and Maintain Secure Systems and Software
This is the core requirement for web applications. The key sub-requirements:
- 6.2.4: Prevent common software attacks — injection, XSS, improper error handling, weak authentication, unencrypted data. Requires training, secure coding practices, and security testing.
- 6.3.2: Maintain an inventory of bespoke and custom software. Know what you have deployed.
- 6.4.1: Web-facing applications are protected against known attacks. This explicitly requires either: (a) a Web Application Firewall, or (b) a documented vulnerability assessment process with remediation prior to deployment.
- 6.4.2: Payment page scripts are managed — all scripts on your payment page must be authorized and have their integrity verified (Subresource Integrity for third-party scripts).
Requirement 11: Test Security of Systems and Networks Regularly
- 11.3.1: External vulnerability scans are performed quarterly by an Approved Scanning Vendor (ASV). After any significant change, a new scan must be performed and show no HIGH or CRITICAL vulnerabilities.
- 11.3.2: Internal vulnerability scans quarterly.
- 11.4.1–11.4.7: Penetration testing at least annually, plus after any significant change to infrastructure or applications.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission
- 4.2.1: Strong cryptography (TLS 1.2 minimum; TLS 1.3 recommended) on all cardholder data transmissions. TLS 1.0 and 1.1 are explicitly prohibited. HTTPS with a valid certificate is the baseline.
Requirement 8: Identify Users and Authenticate Access
Authentication controls on your web application's admin interfaces and APIs — strong passwords, MFA for administrative access, session timeouts. If your web application has an admin panel, this requirement applies directly.
PCI DSS SAQ Levels: Which Applies to You
| SAQ Type | Who it applies to | Web app requirements |
|---|---|---|
| SAQ A | All payment functions outsourced to a PCI-compliant provider (e.g., Stripe hosted payment page via redirect). Your website never handles card data. | Minimal — but Requirement 6.4.3 still requires you to manage scripts on your payment page. |
| SAQ A-EP | E-commerce merchant using a third-party payment processor but your website delivers the payment page to the customer's browser. | Full Requirements 6, 11.3, and 4 apply. Vulnerability scanning required. |
| SAQ D | All other merchants, including those with their own payment processing infrastructure. | All requirements apply. Full external scan by ASV required quarterly. |
What Auditors Check on Web Applications
A PCI QSA (Qualified Security Assessor) reviewing your web application will typically verify:
- TLS 1.2+ enforced, TLS 1.0/1.1 disabled
- Valid SSL certificate on all payment pages
- Security headers in place (especially CSP on payment pages)
- No sensitive data in error messages or logs
- Input validation on all form fields
- SRI attributes on third-party scripts on payment pages
- Recent vulnerability scan results with no unresolved HIGH/CRITICAL findings
- Evidence of a remediation process for scan findings
How Shieldome Checks This
Shieldome covers the technical scanning requirements in PCI DSS 6 and 11. Here is the mapping:
| PCI DSS Requirement | Shieldome Check |
|---|---|
| 4.2.1 — TLS 1.2+ required | TLS version detection; flags TLS 1.0 and 1.1 as CRITICAL |
| 6.2.4 — Prevent common attacks | SQL injection indicators, XSS reflection, path traversal detection |
| 6.4.1 — WAF or vulnerability assessment | Full 40+ control scan provides documented vulnerability assessment evidence |
| 6.4.2 — Payment page script integrity | SRI attribute detection on external scripts |
| 11.3.1 — External vulnerability scan | External scan with timestamped PDF report; re-scannable after changes |
| 4.2.1 — Strong cryptography | SSL cert validity, expiry, cipher suite warnings |
| 6.2.4 — Sensitive data in errors | Verbose error detection — stack traces and database errors flagged |
Important note: Shieldome is not an Approved Scanning Vendor (ASV) and cannot issue PCI ASV scan reports for formal PCI DSS certification. However, running regular Shieldome scans as your internal vulnerability management process — and fixing findings before your quarterly ASV scan — directly supports your PCI DSS compliance posture and reduces the risk of your formal ASV scan finding issues.
Frequently Asked Questions
Do I need PCI DSS compliance if I use Stripe or PayPal?
Yes, but at a reduced scope. Using a hosted payment page (where the customer is redirected to Stripe or PayPal to enter card data) means you operate under SAQ A — the simplest compliance level. However, you still have obligations: you must ensure your website does not redirect customers to non-PCI-compliant pages, and PCI DSS 4.0 SAQ A v4 now includes requirements for managing scripts on your pages even if they don't handle card data.
What does "no HIGH or CRITICAL findings" mean for ASV scans?
PCI DSS 11.3.1 requires that external ASV scans show no unresolved findings scored at CVSS 4.0 or higher (HIGH and CRITICAL). All such findings must be remediated or formally disputed before the scan result is considered passing. This is why running a pre-scan with Shieldome to find and fix issues before your quarterly ASV scan is valuable.
How often must I scan for PCI DSS?
External vulnerability scans (by an ASV) are required quarterly and after any significant change to your environment. Internal scans are also required quarterly. Additionally, web application penetration testing is required at least annually and after major changes.
What counts as a "significant change" that triggers a new scan?
PCI DSS defines significant changes as: new system components installed, network topology changes, firewall rule changes, new software or product upgrades, and any modification that could affect the security of the cardholder data environment. In practice, any code deployment to your payment flow or checkout pages should trigger a re-scan.
PCI DSS compliance starts with knowing your vulnerabilities. Run a free Shieldome scan to see your current security posture against the technical controls PCI DSS 4.0 requires — and fix them before your next ASV scan.