Latest Secure Software Coding Checklist

Secure Software Coding Checklist

The Secure Software Coding Checklist is an essential resource for developers and engineers committed to creating secure, high-quality software. This checklist provides clear, actionable guidelines for embedding security directly into your code, ensuring it is resilient against vulnerabilities and compliant with industry standards.

Secure Software Coding Checklist
General coding practices
	1. Use tested and approved managed code rather than creating new unmanaged code for common tasks 2. Utilize task specific built-in APIs to conduct operating system tasks. Do not allow the application to issue commands directly to the Operating System, especially through the use of application initiated command shells 3. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files 4. Utilize locking to prevent multiple simultaneous requests or use a synchronization mechanism to prevent race conditions 5. Protect shared variables and resources from inappropriate concurrent access 6. Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage 7. In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as soon as possible 8. Avoid calculation errors by understanding your programming language's underlying representation 9. Do not pass user supplied data to any dynamic execution function 10. Restrict users from generating new code or altering existing code 11. Review all secondary applications, third party code and libraries to determine business necessity and validate safe functionality 12. Implement safe updating using encrypted channels
Input Validation
	1. Conduct all input validation on a trusted system (server side not client side) 2. Identify all data sources and classify them into trusted and untrusted 3. Validate all data from untrusted sources (databases, file streams, etc) 4. Use a centralized input validation routine for the whole application 5. Specify character sets, such as UTF-8, for all input sources (canonicalization) 6. Encode input to a common character set before validating 7. All validation failures should result in input rejection 8. If the system supports UTF-8 extended character sets and validate after UTF-8 decoding is completed 9. Validate all client provided data before processing 10. Verify that protocol header values in both requests and responses contain only ASCII characters 11. Validate data from redirects 12. Validate for expected data types using an "allow" list rather than a "deny" list 13. Validate data range 14. Validate data length 15. If any potentially hazardous input must be allowed then implement additional controls 16. If the standard validation routine cannot address some inputs then use extra discrete checks 17. Utilize canonicalization to address obfuscation attacks
Output Encoding
	1. Conduct all output encoding on a trusted system (server side not client side) 2. Utilize a standard, tested routine for each type of outbound encoding 3. Specify character sets, such as UTF-8, for all outputs 4. Contextually output encode all data returned to the client from untrusted sources 5. Ensure the output encoding is safe for all target systems 6. Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP 7. Sanitize all output of untrusted data to operating system commands
Authentication and Password Management
	1. Require authentication for all pages and resources, except those specifically intended to be public 2. All authentication controls must be enforced on a trusted system 3. Establish and utilize standard, tested, authentication services whenever possible 4. Use a centralized implementation for all authentication controls, including libraries that call external authentication services 5. Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control 6. All authentication controls should fail securely 7. All administrative and account management functions must be at least as secure as the primary authentication mechanism 8. If your application manages a credential store, use cryptographically strong one-way salted hashes 9. Password hashing must be implemented on a trusted system server side not client side) 10. Validate the authentication data only on completion of all data input 11. Authentication failure responses should not indicate which part of the authentication data was incorrect 12. Utilize authentication for connections to external systems that involve sensitive information or functions 13. Authentication credentials for accessing services external to the application should be stored in a secure store 14. Use only HTTP POST requests to transmit authentication credentials 15. Only send non-temporary passwords over an encrypted connection or as encrypted data 16. Enforce password complexity requirements established by policy or regulation 17. Enforce password length requirements established by policy or regulation 18. Password entry should be obscured on the user's screen 19. Enforce account disabling after an established number of invalid login attempts 20. Password reset and changing operations require the same level of controls as account creation and authentication 21. Password reset questions should support sufficiently random answers 22. If using email based resets, only send email to a pre-registered address with a temporary link/password 23. Temporary passwords and links should have a short expiration time 24. Enforce the changing of temporary passwords on the next use 25. Notify users when a password reset occurs 26. Prevent password re-use 27. Passwords should be at least one day old before they can be changed, to prevent attacks on password re-use 28. Enforce password changes based on requirements established in policy or regulation, with the time between resets administratively controlled 29. Disable "remember me" functionality for password fields
Session Management
	1. Use the server or framework’s session management controls. The application should recognize only these session identifiers as valid 2. Session identifier creation must always be done on a trusted system (server side not client side) 3. Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers 4. Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site 5. Logout functionality should fully terminate the associated session or connection 6. Logout functionality should be available from all pages protected by authorization 7. Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements 8. Disallow persistent logins and enforce periodic session terminations, even when the session is active 9. If a session was established before login, close that session and establish a new session after a successful login 10. Generate a new session identifier on any re-authentication 11. Do not allow concurrent logins with the same user ID 12. Do not expose session identifiers in URLs, error messages or logs 13. Implement appropriate access controls to protect server side session data from unauthorized access from other users of the server 14. Generate a new session identifier and deactivate the old one periodically 15. Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication 16. Consistently utilize HTTPS rather than switching between HTTP to HTTPS 17. Supplement standard session management for sensitive server-side operations, like account management, by utilizing per-session strong random tokens or parameters 18. Supplement standard session management for highly sensitive or critical operations by utilizing per-request, as opposed to per-session, strong random tokens or parameters 19. Set the "secure" attribute for cookies transmitted over an TLS connection 20. Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read or set a cookie's value
Access Control
	1. Use only trusted system objects, e.g. server side session objects, for making access authorization decisions 2. Use a single site-wide component to check access authorization. This includes libraries that call external authorization services 3. Access controls should fail securely 4. Deny all access if the application cannot access its security configuration information 5. Enforce authorization controls on every request, including those made by server side scripts 6. Segregate privileged logic from other application code 7. Restrict access to files or other resources, including those outside the application's direct control, to only authorized users 8. Restrict access to protected URLs to only authorized users 9. Restrict access to protected functions to only authorized users 10. Restrict direct object references to only authorized users 11. Restrict access to services to only authorized users 12. Restrict access to application data to only authorized users 13. Restrict access to user and data attributes and policy information used by access controls 14. Restrict access security-relevant configuration information to only authorized users 15. Server side implementation and presentation layer representations of access control rules must match 16. If state data must be stored on the client, use encryption and integrity checking on the server side to detect state tampering 17. Enforce application logic flows to comply with business rules 18. Limit the number of transactions a single user or device can perform in a given period of time, low enough to deter automated attacks but above the actual business requirement 19. Use the "referer" header as a supplemental check only, it should never be the sole authorization check as it is can be spoofed 20. If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate 21. Implement account auditing and enforce the disabling of unused accounts 22. The application must support disabling of accounts and terminating sessions when authorization ceases 23. Service accounts or accounts supporting connections to or from external systems should have the least privilege possible 24. Create an Access Control Policy to document an application's business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources
Cryptographic practices
	1. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system 2. Protect secrets from unauthorized access 3. Cryptographic modules should fail securely 4. All random numbers, random file names, random GUIDs, and random strings should be generated using the cryptographic module’s approved random number generator 5. Cryptographic modules used by the application should be compliant to FIPS 140-2 or an equivalent standard 6. Establish and utilize a policy and process for how cryptographic keys will be managed
Error Handling and Logging
	1. Do not disclose sensitive information in error responses, including system details, session identifiers or account information 2. Use error handlers that do not display debugging or stack trace information 3. Implement generic error messages and use custom error pages 4. The application should handle application errors and not rely on the server configuration 5. Properly free allocated memory when error conditions occur 6. Error handling logic associated with security controls should deny access by default 7. All logging controls should be implemented on a trusted system 8. Logging controls should support both success and failure of specified security events 9. Ensure logs contain important log event data 10. Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software 11. Restrict access to logs to only authorized individuals 12. Utilize a central routine for all logging operations 13. Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords 14. Ensure that a mechanism exists to conduct log analysis 15. Log all input validation failures 16. Log all authentication attempts, especially failures 17. Log all access control failures 18. Log all apparent tampering events, including unexpected changes to state data 19. Log attempts to connect with invalid or expired session tokens 20. Log all system exceptions 21. Log all administrative functions, including changes to the security configuration settings 22. Log all backend TLS connection failures 23. Log cryptographic module failures 24. Use a cryptographic hash function to validate log entry integrity
Data Protection
	1. Implement least privilege, restrict users to only the functionality, data and system information that is required to perform their tasks 2. Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those temporary working files a soon as they are no longer required. 3. Encrypt highly sensitive stored information, such as authentication verification data, even if on the server side 4. Protect server-side source-code from being downloaded by a user 5. Do not store passwords, connection strings or other sensitive information in clear text or in any non-cryptographically secure manner on the client side 6. Remove comments in user accessible production code that may reveal backend system or other sensitive information 7. Remove unnecessary application and system documentation as this can reveal useful information to attackers 8. Do not include sensitive information in HTTP GET request parameters 9. Disable auto complete features on forms expected to contain sensitive information, including authentication 10. Disable client side caching on pages containing sensitive information 11. The application should support the removal of sensitive data when that data is no longer required 12. Implement appropriate access controls for sensitive data stored on the server. This includes cached data, temporary files and data that should be accessible only by specific system users
Communication Security
	1. Implement encryption for the transmission of all sensitive information. This should include TLS for protecting the connection and may be supplemented by discrete encryption of sensitive files or non-HTTP based connections 2. TLS certificates should be valid and have the correct domain name, not be expired, and be installed with intermediate certificates when required 3. Failed TLS connections should not fall back to an insecure connection 4. Utilize TLS connections for all content requiring authenticated access and for all other sensitive information 5. Utilize TLS for connections to external systems that involve sensitive information or functions 6. Utilize a single standard TLS implementation that is configured appropriately 7. Specify character encodings for all connections 8. Filter parameters containing sensitive information from the HTTP referer, when linking to external sites
System configuration
	1. Ensure servers, frameworks and system components are running the latest approved version 2. Ensure servers, frameworks and system components have all patches issued for the version in use 3. Turn off directory listings 4. Restrict the web server, process and service accounts to the least privileges possible 5. When exceptions occur, fail securely 6. Remove all unnecessary functionality and files 7. Remove test code or any functionality not intended for production, prior to deployment 8. Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory 9. Define which HTTP methods, Get or Post, the application will support and whether it will be handled differently in different pages in the application 10. Disable unnecessary HTTP methods 11. If the web server handles different versions of HTTP ensure that they are configured in a similar manner and ensure any differences are understood 12. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks 13. The security configuration store for the application should be able to be output in human readable form to support auditing 14. Implement an asset management system and register system components and software in it 15. Isolate development environments from the production network and provide access only to authorized development and test groups 16. Implement a software change control system to manage and record changes to the code both in development and production
Database Security
	1. Use strongly typed parameterized queries 2. Utilize input validation and output encoding and be sure to address meta characters. If these fail, do not run the database command 3. Ensure that variables are strongly typed 4. The application should use the lowest possible level of privilege when accessing the database 5. Use secure credentials for database access 6. Connection strings should not be hard coded within the application. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted. 7. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database 8. Close the connection as soon as possible 9. Remove or change all default database administrative passwords 10. Turn off all unnecessary database functionality 11. Remove unnecessary default vendor content (for example sample schemas) 12. Disable any default accounts that are not required to support business requirements 13. The application should connect to the database with different credentials for every trust distinction (for example user, read-only user, guest, administrators)
File Management
	1. Do not pass user supplied data directly to any dynamic include function 2. Require authentication before allowing a file to be uploaded 3. Limit the type of files that can be uploaded to only those types that are needed for business purposes 4. Validate uploaded files are the expected type by checking file headers rather than by file extension 5. Do not save files in the same web context as the application 6. Prevent or restrict the uploading of any file that may be interpreted by the web server. 7. Turn off execution privileges on file upload directories 8. Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive using the associated path or the chrooted environment 9. When referencing existing files, use an allow-list of allowed file names and types 10. Do not pass user supplied data into a dynamic redirect 11. Do not pass directory or file paths, use index values mapped to pre-defined list of paths 12. Never send the absolute file path to the client 13. Ensure application files and resources are read-only 14. Scan user uploaded files for viruses and malware
Memory Management
	1. Utilize input and output controls for untrusted data 2. Check that the buffer is as large as specified 3. When using functions that accept a number of bytes ensure that NULL termination is handled correctly 4. Check buffer boundaries if calling the function in a loop and protect against overflow 5. Truncate all input strings to a reasonable length before passing them to other functions 6. Specifically close resources, don’t rely on garbage collection 7. Use non-executable stacks when available 8. Avoid the use of known vulnerable functions 9. Properly free allocated memory upon the completion of functions and at all exit points 10. Overwrite any sensitive information stored in allocated memory at all exit points from the function

Secure Software Development Checklist
Awareness and Training
	Are the developers skilled in secure coding, certified and aware of the application specific security requirements?
Security guidelines
	1. Whether the design document provides a detail security information and guidance about the application security? 2. Whether the developers are using the recommended tools, components, encryption and hashing algorithms, frameworks, environment and practices specified by the security analyst and the solution architect.
Code Analysis/Review
	1. Do project teams utilize automation (IDE Plugins) to check code against application-specific coding standards? 2. Is Static Code Analysis integrated into the build process (each automated build spawns Static Code Analysis)? 3. Is the source code scanned and reviewed by popular static code analyzer tools like IBM App Scan, VeraCode etc? 4. Are the vulnerabilities identified by the Code Analyzer tools identified and fixed? 5. Does the stakeholders consistently review results from code reviews? 6. Whether the developers are aware of the deprecated application framework functions and not using during development? 7. Verify that the source code control system is in use, with procedures to ensure that check-ins are accompanied by issues or change tickets. The source code control system should have access control and identifiable users to allow traceability of any changes. 8. Whether final source code is reviewed manually by security experts?

Suggested Exercises: Secure Coding and Testing Tests