SQL Injection
This is a classic security challenge where an app uses a SQL database and does not use parametrised query or ORM.
PCI-DSS · 4.0 edition
PCI-DSS Secure Coding Challenges
PCI-DSS v4.0 Requirement 6.2.2 requires annual, role- and language-specific secure coding training for every developer who touches cardholder data systems. Every SecDim challenge below is a real vulnerability in a real app, mapped to the vulnerability classes Requirement 6.2.4 names by name.
Ready when the auditor asks
Generate Your PCI-DSS Training Report
Every completed challenge rolls up into a PCI-DSS training report. Point and click to generate it, then hand it straight to your auditor, customer or partner the moment they ask for evidence.
Capability, not checkbox compliance
Hands-On Challenges for Every Category
PCI-DSS v4.0 Requirement 6.2.2 is explicit: software development personnel must be trained at least once every 12 months on secure coding techniques relevant to their job function and the languages they use. Requirement 6.2.4 goes further and names the vulnerability classes that training and code review must cover. Every challenge below is a real application with a real vulnerability in that class. Developers fix it without breaking functionality, and every verified fix becomes reportable evidence for your QSA or acquiring bank, not an attendance sheet.
Satisfying Requirement 6.2.2
Start the CourseOWASP Top 10 Course
A structured secure-coding course covering the same vulnerability classes PCI-DSS Requirement 6.2.4 names, taught through real breaches. Run it once a year per developer and you have a documented, dated training record for your assessor.
Req 6.2.4 · Injection Attacks
Injection Attacks
SQL, command and log injection are the first vulnerability class Requirement 6.2.4 names explicitly.
Req 6.2.4 · Cross-Site Scripting & CSRF
Cross-Site Scripting & CSRF
Output injection and forged cross-origin requests are both named explicitly in Requirement 6.2.4's vulnerability list.
Req 6.2.4 · Broken Authentication & Session Management
Broken Authentication & Session Management
Weak login, token and session handling are named directly in Requirement 6.2.4's vulnerability list.
Req 6.2.4 · Insecure Cryptographic Storage
Insecure Cryptographic Storage
Predictable randomness and weak key handling. Cardholder data protection lives or dies on this.
Req 6.2.4 · Insecure Communications
Insecure Communications
Weak TLS configuration exposing cardholder data in transit.
Req 6.2.4 · Improper Access Control
Improper Access Control
Insecure direct object references and missing function-level checks fall under Requirement 6.2.4's "improper access control" bucket.
Req 6.2.4 · Improper Error Handling
Improper Error Handling
Fail-open logic and unhandled exceptional conditions that crash or expose payment systems under attack.
Req 6.3 · Vulnerable & Malicious Components
Software Supply Chain & Vulnerable Components
Requirement 6.3 requires an inventory and remediation process for vulnerable components, including the CI/CD pipeline that builds your payment systems.
Roll it out
Turn the Standard Into a Training Program
Assign these challenges to your team as learning pathways, track verified fixes, and report PCI-DSS coverage to auditors, customers and the board, with evidence, not attendance sheets.