Please find the OWASP(Open Web Application Security Project) Secure Coding Practices Checklist:
1) Input Validation - Conduct all data validation. All validation failures should result in input rejection.Validate for expected data types, data range, data length.
2) Authentication and Password Management - Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code. Enforce password length requirements established by policy or regulation. Eight characters is commonly used, but 16 is better or consider the use of multi-word pass phrases. Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common).
3) Session Management - If a session was established before login, close that session and establish a new session after a successful login .Generate a new session identifier on any re-authentication. Do not allow concurrent logins with the same user ID
4) Access Control - Use a single site-wide component to check access authorization. This includes libraries that call external authorization services. 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.
5) Error Handling and Logging - Do not disclose sensitive information in error responses, including system details, session identifiers or account information. Implement generic error messages and use custom error pages .The application should handle application errors and not rely on the server configuration. Log all input validation failures, authentication attempts, especially failures, access control failures, system exceptions, backend connection failures
6) System Configuration - Ensure servers, frameworks and system components are running the latest approved version and have all patches issued for the version in use. When exceptions occur, fail securely. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks
7) Database Security - Use secure credentials for database access. The application should connect to the database with different credentials for every trust distinction (e.g., user, read-only user, guest, administrators)
8) File Management - Require authentication before allowing a file to be uploaded.Validate uploaded files are the expected type by checking file headers. Checking for file type by extension alone is not sufficient. Do not save files in the same web context as the application. Files should either go to the content server or in the database. Turn off execution privileges on file upload directories. Never send the absolute file path to the client. Scan user uploaded files for viruses and malware
9) Memory Management - Properly free allocated memory upon the completion of functions and at all exit points. Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.) Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.) Double check that the buffer is as large as specified
10) General Coding Practices - Use tested and approved managed code rather than creating new unmanaged code. 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. Do not pass user supplied data to any dynamic execution function
Please find the OWASP(Open Web Application Security Project) Secure Coding Practices Checklist:
1) Input Validation - Conduct all data validation. All validation failures should result in input rejection.Validate for expected data types, data range, data length.
2) Authentication and Password Management - Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code. Enforce password length requirements established by policy or regulation. Eight characters is commonly used, but 16 is better or consider the use of multi-word pass phrases. Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common).
3) Session Management - If a session was established before login, close that session and establish a new session after a successful login .Generate a new session identifier on any re-authentication. Do not allow concurrent logins with the same user ID
4) Access Control - Use a single site-wide component to check access authorization. This includes libraries that call external authorization services. 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.
5) Error Handling and Logging - Do not disclose sensitive information in error responses, including system details, session identifiers or account information. Implement generic error messages and use custom error pages .The application should handle application errors and not rely on the server configuration. Log all input validation failures, authentication attempts, especially failures, access control failures, system exceptions, backend connection failures
6) System Configuration - Ensure servers, frameworks and system components are running the latest approved version and have all patches issued for the version in use. When exceptions occur, fail securely. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks
7) Database Security - Use secure credentials for database access. The application should connect to the database with different credentials for every trust distinction (e.g., user, read-only user, guest, administrators)
8) File Management - Require authentication before allowing a file to be uploaded.Validate uploaded files are the expected type by checking file headers. Checking for file type by extension alone is not sufficient. Do not save files in the same web context as the application. Files should either go to the content server or in the database. Turn off execution privileges on file upload directories. Never send the absolute file path to the client. Scan user uploaded files for viruses and malware
9) Memory Management - Properly free allocated memory upon the completion of functions and at all exit points. Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.) Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.) Double check that the buffer is as large as specified
10) General Coding Practices - Use tested and approved managed code rather than creating new unmanaged code. 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. Do not pass user supplied data to any dynamic execution function