Secure Software Testing Checklist

The Secure Software Testing Checklist is a vital tool for QA engineers, developers, and security professionals focused on verifying the security and resilience of applications before deployment. This comprehensive guide outlines best practices for testing software to uncover vulnerabilities, ensure compliance, and validate that security requirements have been met.

Secure Software Testing Checklist
Secure Software Development Lifecycle
	1. Verify the use of a secure software development lifecycle that addresses security in all stages of development. 2. Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing. 3. Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile" 4. Verify documentation and justification of all the application's trust boundaries, components, and significant data flows. 5. Verify definition and security analysis of the application's high-level architecture and all connected remote services. 6. Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. 7. Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.
Business Logic Testing
	1. Ensure that the application will only handle business logic flows for the same user in a step-by-step, sequential manner without skipping any steps. 2. Test if the application process only business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly. 3. Ensure that the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis. 4. Ensure that the application/WAFs has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks. 5. Ensure that the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies. 6. Ensure that the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations. 7. Verify whether the application monitors unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. 8. Verify whether the application has configurable alerting mechanisms when automated attacks or unusual activity is detected. 9. Ensure that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state. 10. Ensure that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions. 11. Test for feature misuse 12. Test for lack of non-repudiation 13. Test for trust relationships 14. Test for integrity of data during all CRUD (create, read, update and delete) operations. 15. Test segregation of duties for all the roles in the application
Data Protection Testing
	1. Ensure the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers. 2. Ensure that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data. 3. Ensure that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. 4. Ensure the application protects sensitive data from being cached in server components such as load balancers and application caches. 5. Ensure that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data. 6. Ensure the application minimizes the number of sensitive data parameters in a request, such as hidden fields, Ajax variables, cookies and header values. 7. Ensure the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application. 8. Ensure that regular backups of important data are performed and that test restoration of data is performed. 9. Ensure that backups are stored securely to prevent data from being stolen or corrupted. 10. Ensure that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data. 11. Ensure that users have a method to remove or export their data on demand (to comply with laws if required). 12. Ensure that users are provided in a clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way. 13. Ensure that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. 14. Ensure accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required. 15. Ensure that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data. 16. Ensure that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity. 17. Ensure that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires.
General Web Security
	1. Test for Reflected Cross Site Scripting 2. Test for Stored Cross Site Scripting Test 3. Test for DOM based Cross Site Scripting Test 4. Test for Cross Site Flashing 5. Test for HTML Injection 6. Test for SQL Injection 7. Test for LDAP Injection 8. Test for ORM Injection 9. Test for XML Injection 10. Test for XXE Injection 11. Test for SSI Injection 12. Test for XPath Injection 13. Test for XQuery Injection 14. Test for IMAP/SMTP Injection 15. Test for Code Injection 16. Test for Expression Language Injection 17. Test for Command Injection 18. Test for Overflow (Stack, Heap and Integer) 19. Test for incubated vulnerabilities 20. Test for HTTP Splitting/Smuggling 21. Test for HTTP Verb Tampering 22. Test for Open Redirection 23. Test for Local File Inclusion 24. Test for Remote File Inclusion 25. Compare client-side and server-side validation rules 26. Test for NoSQL injection 27. Test for HTTP parameter pollution 28. Test for auto-binding 29. Test for Mass Assignment 30. Test for NULL/Invalid Session Cookie 31. Test Web Messaging 32. Test for Web Storage SQL injection 33. Check CORS implementation. 34. Check Offline Web Application
Input and Outputs Testing
	Input Testing 1. Ensure that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). 2. Ensure that sign, range, and input validation techniques are used to prevent integer overflows. 3. Ensure that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). 4. Ensure that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables). 5. Ensure that input format strings do not take potentially hostile input, and are constant. 6. Ensure that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. 7. Ensure that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. 8. Ensure that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed. 9. Ensure that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports. 10. Ensure that unstructured data is sanitized to enforce safety measures such as allowed characters and length. 11. Ensure that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. 12. Ensure that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. 13. Ensure that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content. 14. Ensure that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. 15. Ensure that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. 16. Ensure that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers). 17. Ensure that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON. 18. Ensure that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. 19. Ensure that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. 20. Ensure that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks. 21. Ensure that the application protects against XPath injection or XML injection attacks. 22. Ensure that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. 23. Ensure that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. 24. Ensure that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreign Object. 25. Ensure that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. Output Testing 1. Ensure that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). 2. Ensure that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. 3. Ensure that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. 4. Ensure that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
File IO Testing
	1. Ensure that the application will not accept large files that could fill up storage or cause a denial of service. 2. Ensure that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. 3. Ensure that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files. 4. Test that file size limits, upload frequency and total file counts are defined and are enforced. 5. Test that file contents match the defined file type. 6. Test that all file uploads have Anti-Virus scanning in-place. 7. Test that unsafe filenames are sanitized. 8. Test that uploaded files are not directly accessible within the web root. 9. Ensure that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required. 10. Ensure that direct requests to uploaded files will never be executed as HTML/JavaScript content. 11. Ensure that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal. 12. Ensure that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI). 13. Ensure that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. 14. Ensure that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename. 15. Ensure that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection. 16. Ensure that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs. 17. Ensure that files obtained from untrusted sources are validated to be of the expected type based on the file's content. 18. Ensure that files obtained from untrusted sources are stored outside of the web root/static content area, with limited permissions. 19. Ensure that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. 20. Ensure that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from. 21. Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.
Authentication Testing
	1. Test for user enumeration 2. Test for authentication bypass 3. Test for brute force protection 4. Test password quality rules 5. Test remember me functionality. 6. Test for autocomplete on password forms/input. 7. Test password reset and/or recovery. 8. Test password change process 9. Test CAPTCHA 10. Test multi factor authentication 11. Test for logout functionality presence 12. Test for cache management on HTTP (eg Pragma, Expires, Max-age) 13. Test for default logins 14. Test for user-accessible authentication history 15. Test for out-of channel notification of account lockouts and successful password changes 16. Test for consistent authentication across applications with shared authentication schema / SSO
Session Management Testing
	1. Ensure that cookie-based session tokens have the 'Secure' and 'HttpOnly' attributes set. 2. Ensure that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. 3. Ensure that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie. 4. Ensure that if the application is published under a domain name with other applications that set or use session cookies that might disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. 5. Ensure the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications. 6. Ensure the application never reveals session tokens in URL parameters. 7. Ensure the application generates a new session token on user authentication. 8. Ensure that session tokens possess at least 64 bits of entropy. 9. Ensure the application only stores session tokens in the browser using secure methods such as appropriately secured cookies or HTML 5 session storage. 10. Ensure that session tokens are generated using approved cryptographic algorithms. 11. Ensure that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. 12. If authenticators permit users to remain logged in, ensure that re-authentication occurs periodically both when actively used or after an idle period. 30 days12 hours or 30 minutes of inactivity, 2FA optional12 hours or 15 minutes of inactivity, with 2FA 13. Ensure that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties. 14. Ensure that users can view and (having re-entered login credentials) log out of any or all currently active sessions and devices. 15. Ensure the application allows users to revoke OAuth tokens that form trust relationships with linked applications. 16. Ensure the application uses session tokens rather than static API secrets and keys, except with legacy implementations. 17. Ensure that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks. 18. Establish how session management is handled in the application (eg, tokens in cookies, token in URL) 19. Check session tokens for cookie flags (httpOnly and secure) 20. Check session cookie scope (path and domain) 21. Check session cookie duration (expires and max-age) 22. Check session termination after a maximum lifetime. 23. Check session termination after relative timeout. 24. Check session termination after logout. 25. Test to see if users can have multiple simultaneous sessions. 26. Test session cookies for randomness 27. Confirm that new session tokens are issued on login, role change and logout. 28. Test for consistent session management across applications with shared session management 29. Test for session puzzling 30. Test for CSRF and clickjacking 31. Ensure that Relying Parties (RPs) specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the user if they haven't used a session within that period. 32. Ensure that Credential Service Providers (CSPs) inform Relying Parties (RPs) of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.
Passwords security Testing
	1. Ensure that user set passwords are at least 12 characters in length (after multiple spaces are combined). 2. Ensure that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. 3. Ensure that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. 4. Ensure that users can change their password via MFA. 5. Ensure that password change functionality requires the user's current and new password. 6. Ensure that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password. 7. Ensure that a password strength meter is provided to help users set a stronger password. 8. Ensure that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. 9. Ensure that there are no periodic credential rotation or password history requirements. 10. Ensure that "paste" functionality, browser password helpers, and external password managers are permitted. 11. Ensure that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as built-in functionality.
General Authenticator Security Testing
	1. Ensure that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account. 2. Ensure that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise. 3. Ensure that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations. The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification. 4. Ensure impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates. 5. Ensure that where a Credential Service Provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints. 6. Ensure replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes. 7. Ensure intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key.
Authenticator Lifecycle Testing
	1. Ensure that the system generated initial passwords or activation codes are secure & randomly generated, they should be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long-term password. 2. Ensure that the enrollment and use of user-provided authentication devices are supported, such as U2F or FIDO tokens. 3. Ensure that the renewal instructions are sent with sufficient time to renew time bound authenticators. 4. Ensure that a system generated initial activation or recovery secret is not sent in clear text to the user. 5. Ensure that password hints or knowledge-based authentication (so-called "secret questions") are not present. 6. Ensure that password credential recovery does not reveal the current password in any way. 7. Ensure that shared or default accounts are not present (e.g. "root", "admin", or "sa"). 8. Ensure that if an authentication factor is changed or replaced, that the user is notified of this event. 9. Ensure that forgotten passwords, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. 10. Ensure that if any OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment.
Credential Storage & Cryptographic Testing
	1. Ensure that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash. 2. Ensure that the salt used is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each credential, a unique salt value and the resulting hash SHALL be stored. 3. Ensure that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,000 iterations. 4. Ensure that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10. 5. Ensure that an additional iteration of a key derivation function is performed, using a salt value that is secret and known only to the verifier. Generate the salt value using an approved random bit generator and provide at least the minimum-security strength specified in the latest revision of SP 800-131A. The secret salt value SHALL be stored separately from the hashed passwords (e.g., in a specialized device like a hardware security module). 6. Ensure that the cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage. 7. Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. 8. Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
One Time Verifier Testing
	1. Ensure that time-based OTPs have a defined lifetime before expiring. 2. Ensure that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage. 3. Ensure that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs. 4. Ensure that time-based OTP can be used only once within the validity period. 5. Ensure that if a time-based multi-factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device. 6. Ensure physical single-factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location. 7. Ensure that biometric authenticators are limited to use only as secondary factors in conjunction with something you have and something you know. 8. Ensure that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first. 9. Ensure that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes. 10. Ensure that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request. 11. Ensure that the out of band authenticator and verifier communicates over a secure independent channel. 12. Ensure that the out of band verifier retains only a hashed version of the authentication code. 13. Ensure that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient).
Service Authentication Testing
	1. Ensure that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access. 2. Ensure that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation). 3. Ensure that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access. 4. Ensure passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.
Access Controls Testing
	1. Ensure that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed. 2. Ensure that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized. 3. Ensure that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. 4. Ensure that access controls fail securely including when an exception occurs. 5. Ensure that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records. 6. Ensure that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality. 7. Ensure administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use. 8. Ensure that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders. 9. Ensure the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.
Cryptographic Testing
	1. Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks. 2. Verify that industry proven, or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. 3. Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice. 4. Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. 5. Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility. 6. Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used. 7. Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party. 8. Verify that all cryptographic operations are constant time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. 9. Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR. 10. Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records. 11. Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records. 12. Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker. 13. Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable. 14. Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances. 15. Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. 16. Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. 17. Check if data which should be encrypted is not. 18. Check for wrong algorithms usage depending on context. 19. Check for weak algorithms usage. 20. Check for proper use of salting. 21. Check for randomness functions
Configuration Testing
	1. Check for commonly used application and administrative URLs. 2. Check for old, backup and unreferenced files. 3. Check HTTP methods supported and Cross Site Tracing (XST) 4. Test file extensions handling 5. Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS) 6. Test for policies (e.g. Flash, Silverlight, robots) 7. Test for non-production data in live environment, and vice-versa 8. Check for sensitive data in client-side code (e.g. API keys, credentials)
Communication Security Testing
	1. Ensure that the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. 2. Ensure that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains. 3. Ensure that TLS is used for all client connectivity and does not fall back to insecure or unencrypted communications. 4. Ensure using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred. 5. Ensure that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option. 6. Ensure that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected. 7. Ensure that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols. 8. Ensure that all encrypted connections to external systems that involve sensitive information or functions are authenticated. 9. Ensure that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. 10. Ensure that backend TLS connection failures are logged. 11. Check SSL Version, Algorithms, Key length. 12. Check for Digital Certificate Validity (Duration, Signature and CN) 13. Check credentials only delivered over HTTPS. 14. Check that the login form is delivered over HTTPS. 15. Check session tokens only delivered over HTTPS. 16. Check if HTTP Strict Transport Security (HSTS) in use
API and Web Services Security Testing
	1. Ensure that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks. 2. Ensure API URLs do not expose sensitive information, such as the API key, session tokens etc. 3. Ensure that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions. 4. Ensure that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type). 5. Ensure that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources. 6. Ensure that JSON schema validation is in place and verified before accepting input. 7. Ensure that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks. 8. Ensure that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. 9. Ensure that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits. 10. Ensure that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place. 11. Ensure that the message payload is signed using WS-Security to ensure reliable transport between client and service.
Authorization Testing
	1. Test for path traversal 2. Test for bypassing authorization schema 3. Test for vertical Access control problems (a.k.a. Privilege Escalation) 4. Test for horizontal Access control problems (between two users at the same privilege level) 5. Test for missing authorization
Error Handling and Logging Testing
	1. Ensure that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. 2. Ensure that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. 3. Ensure that a "last resort" error handler is defined which will catch all unhandled exceptions. 4. Ensure that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. 5. Ensure that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. 6. Ensure that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. 7. Ensure that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. 8. Ensure that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. 9. Ensure that all access control decisions can be logged, and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations. 10. Ensure that all logging components appropriately encode data to prevent log injection. 11. Ensure that security logs are protected from unauthorized access and modification. 12. Ensure that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis.
Source Code Analysis
	1. Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections. 2. Verify that the application source code and third-party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data. 3. Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location. 4. Verify that the application source code and third-party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered. 5. Verify that the application source code and third-party libraries do not contain time bombs by searching for date and time related functions. 6. Verify that the application source code and third-party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. 7. Verify that the application source code and third-party libraries do not contain Easter eggs or any other potentially unwanted functionality.
Availability Testing
	1. Test for anti-automation 2. Test for account lockout 3. Test for HTTP protocol DoS 4. Test for SQL wildcard DoS
Cryptographic Architecture
	1. Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57. 2. Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives. 3. Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data. 4. Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.
Source: owasp.org

Read More Checklists for : Secure Software Design, Secure Coding, Secure Software Requirements, Secure Software Deployment, Database Security, Secure SDLC

Suggested Exercises: Secure Coding and Testing Tests