6.2.4 Engineering techniques against common software attacks

Developers of bespoke and custom software must have defined and actually use software engineering techniques or other methods that prevent or reduce common software attacks and associated vulnerabilities, including at least: injection attacks (SQL, LDAP, XPath, plus command, parameter, object, fault and similar injection flaws); attacks against data structures and data, for example manipulation of pointers, buffers, shared data or input data; attacks on the use of cryptography, such as exploiting weak, insecure or unsuitable implementations, algorithms, cipher suites or operating modes; business logic attacks that abuse or bypass application features through tampering with APIs, protocols, communication channels, client-side functions or other system resources, including XSS and CSRF; attacks on access control mechanisms, such as bypassing or abusing identification, authentication or authorization, or exploiting weak implementations of them; and attacks through any high-risk vulnerability found by the Requirement 6.3.1 process. It applies to all entities. Applicability: covers all software built by or for the entity for its own use, bespoke and custom; third-party software is not covered. Objective under the customized approach: common attacks and related weaknesses cannot be used to exploit bespoke and custom software.

Source: PCI DSS v4.0.1, 6.2.4. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open PCI DSS v4.0.1 in the compliance library.

Version 4.0.1 is the active version; 4.0 has been retired. Appendix A1 applies only to multi-tenant service providers, A2 only to card-present POS POI terminals that still use SSL or early TLS, and A3 only when a payment brand or acquirer requires it. Which requirements apply to you follows your validation type.