Source Code Security Review Checklist

This checklist provides a structured foundation for conducting and documenting secure code reviews as part of technical security assessments. It is used by binsec to evaluate software projects in line with recognized standards such as PCI DSS, OWASP Top 10. The checklist can be applied both in standalone code reviews and as an addition to web or API penetration tests.

Test Object 1 - Communication

▢ T1-1: Are incoming and outgoing sensitive data (e.g. credentials) transmitted only over encrypted channels?

▢ T1-2: Are secure, state-of-the-art cryptographic algorithms used ?

▢ T1-3: Are X.509 certificates of outgoing connections validated for authenticity and validity?

Test Object 2 - Authentication

▢ T2-1: Are users required to confirm their email address during registration?

▢ T2-2: Are only strong passwords (≥ 12 characters, letters and numbers) accepted (registration and password reset)?

▢ T2-3: Are users prevented from reusing their last four passwords?

▢ T2-4: Is a one-time password reset link sent via email?

▢ T2-5: Can passwords only be changed when the old password is provided?

▢ T2-6: Are user accounts locked for 30 minutes after six failed login attempts?

Test Object 3 - Session Management

▢ T3-1: Does the session ID consist of at least 128 bits (16 bytes)?

▢ T3-2: Does the session ID contain no statistical information about the user?

▢ T3-3: Is the session ID transmitted only in an HTTP cookie?

▢ T3-4: Are HttpOnly and Secure flags set?

▢ T3-5: Must users re-authenticate after 15 minutes of inactivity?

▢ T3-6: Is a random token included and verified with each authorized request (CSRF protection)?

▢ T3-7: Is the session ID deleted upon logout?

Test Object 4 - Authorization

▢ T4-1: Are different user roles defined according to business logic?

▢ T4-2: Are permissions implemented according to “Need-to-Know” and “Least Privilege”?

▢ T4-3: Is Cross-Origin Resource Sharing (CORS) enabled only for selected domains?

Test Object 5 - Error Handling

▢ T5-1: Are all potentially exception-throwing code blocks surrounded by try-catch statements?

▢ T5-2: Are only generic error messages displayed (no technical details)?

Test Object 6 - Data Validation

▢ T6-1: Is only business-valid input (e.g. valid credit card expiry dates) processed?

▢ T6-2: Is all input – even within trusted boundaries – validated on the server side?

▢ T6-3: Are special characters properly escaped or masked?

▢ T6-4: Are prepared statements used to prevent SQL injections?

Test Object 7 - Data Storage

▢ T7-1: Is only data necessary for operation stored or processed?

▢ T7-2: Are PCI DSS requirements for storing card data met (e.g. no CVV storage)?

▢ T7-3: Are user passwords stored exclusively in hashed form?

▢ T7-4: Are cryptographically strong hash functions and unique salts used?

Test Object 8 - Logging

▢ T8-1: Are user actions logged (audit trails)?

▢ T8-2: Are failed input validations logged?

▢ T8-3: Are successful and failed authentication attempts logged?

▢ T8-4: Are authorization errors logged?

▢ T8-5: Are session management errors (e.g. failed CSRF checks) logged?

▢ T8-6: Are legal consent processes (e.g. opt-ins, age verification) logged?

▢ T8-7: Are exception details logged?

▢ T8-8: Are sensitive data masked in logs?

Test Object 9 - Software Components

▢ T9-1: Are software components (e.g. libraries or frameworks) up-to-date?

▢ T9-2: Are package sources trustworthy and software integrity verified?

Test Object 10 - API Security

▢ T10-1: Are all API endpoints strictly authenticated and authorized, including both read and write operations?

▢ T10-2: Are server-side abuse protections in place (rate limiting, anti-automation measures, request size limits)?

Test Object 11 - Cryptography

▢ T11-1: Are only modern and secure cryptographic algorithms used (e.g. AES-GCM, ChaCha20-Poly1305, SHA-256/512, bcrypt/argon2)?

▢ T11-2: Are initialization vectors (IVs) generated securely, never reused, and handled correctly?

▢ T11-3: Are cryptographic keys, tokens and secrets not stored in the source code, but managed through secure mechanisms (e.g. Key Vault, KMS)?

▢ T11-4: Are cryptographically secure random number generators used (CSPRNG instead of predictable PRNGs)?