Performing Code Reviews to PCI Requirements
We were asked by a customer about performing code review based on the PCI requirements. The questions they asked were:
- Is there a checklist that exists that covers all of the PCI requirements?
- Are there requirements such as not storing PAN un-encrypted?
- What about not storing full track data or other restricted data?
- Are there considerations outside of OWASP?
- Can you recommend a simple resource for all PCI-related requirements?
At this point in time, there does not seem to be a single source of reference that answers all of these questions. Since there is no definitive source, this document covers some of the PCI requirements in relation to code reviews. A code review includes reviewing all of the code for the OWASP Top 10 Web Application Security Risks for 2010. The OWASP Top 10 is inclusive of the PCI requirements and answers most if not all of the above questions. The OWASP Top 10 Web Application Security Risks for 2010:
- Injection flaws – such as SQL, OS and LDAP
- Cross-Site Scripting (XSS)
- Broken Authentication and Session Management
- Insecure Direct Object References – exposing a file, directory or database key
- Cross-Site Request Forgery (CSRF)
- Security Misconfiguration
- Insecure Cryptographic Storage
- Failure to Restrict URL Access
- Insufficient Transport Layer Protection
- Unvalidated Redirects and Forwards
Risk number 7 specifically covers the question about storing PANs unencrypted. As for storing track data, this is partially covered by risk number 7. Track data is sensitive and needs to be encrypted while stored, but it can only be stored pre-authorization. Once the transaction has been authorized, the data must be securely deleted. This requirement is not covered by the OWASP Top 10. Here is a complete list of the PCI requirements as they relate to the OWASP Top 10 (see the list above):
Requirement 1: Install and maintain a firewall configuration to protect cardholder data – this requirement is not typically covered in a code review
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters – this requirement is covered under risk number 6
Requirement 3: Protect stored cardholder data – this requirement is covered under risk number 7
Requirement 4: Encrypt transmission of cardholder data across open, public networks – this requirement is risk number 9
Requirement 5: Use and regularly update anti-virus software or programs – This requirement is not typically covered in a code review
Requirement 6: Develop and maintain secure systems and applications – this is fully encompassed in the OWASP Top 10 (both 2007 and 2010 versions)
Requirement 7: Restrict access to cardholder data by business need to know – this requirement is partially covered by risk number 4
Requirement 8: Assign a unique ID to each person with computer access – this requirement is not typically covered in a code review
Requirement 9: Restrict physical access to cardholder data access – this requirement is not typically covered in a code review
Requirement 10: Track and monitor all access to network resources and cardholder data – this requirement is not covered in the OWASP Top 10
Requirement 11: Regularly test security systems and processes access – this requirement is not typically covered in a code review
Requirement 12: Maintain a policy that addresses information security for employee’s and contractor’s access – this requirement is not typically covered in a code review Start your code review checklist with the OWASP Code Review Guide and add to it for those requirements that are not covered by this guide. This includes securely deleting sensitive data (PANs, track data, keys, etc.) and application logging. Another place to start or append to your checklist, if you develop .Net applications, would be Microsoft’s Index of Checklists .
Explore More Blog Posts
Legacy Meets Modern: Breaking AD Through NIS & MFA Infrastructure
Walk through the path of an internal network test: from a constrained foothold to full domain compromise, and how an overlooked integration point became the weakest link.
Phishing with Misfortune Cookies
Phishing is about creativity. The less likely your target is to think about a link being potentially malicious, the more likely you are to have success. Read how our creative Social Engineering experts ruined free cookies in the break room.
CVE-2026-9082 Drupal Core PostgreSQL SQL Injection Overview and Takeaways
A critical vulnerability in Drupal Core, tracked as CVE-2026-9082, affects Drupal deployments using a PostgreSQL database. The issue allows unauthenticated attackers to perform arbitrary SQL queries via crafted JSON:API or search queries. Successful exploitation may result in full database compromise or remote code execution.