Top 10 Secure Coding Practices

Input Validation:

1. Conduct all data validation on a trusted system (e.g., The server) 
2. Identify all data sources and classify them into trusted and untrusted. Validate all data from untrusted sources (e.g., Databases, file streams, etc.)
3. There should be a centralized input validation routine for the application
4. Validate all client provided data before processing, including all parameters, URLs and HTTP header content (e.g. Cookie names and values). Be sure to include automated post backs from JavaScript, Flash or other embedded code
5. Verify that header values in both requests and responses contain only ASCII characters  

Authentication and Password Management:

1. Require authentication for all pages and resources, except those specifically intended to be public.
2. If your application manages a credential store, it should ensure that only cryptographically strong oneway salted hashes of passwords are stored and that the table/file that stores the passwords and keys is write-able only by the application. (Do not use the MD5 algorithm if it can be avoided).
3. Use only HTTP POST requests to transmit authentication credentials 
4. 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.
5. Password reset questions should support sufficiently random answers. (e.g., "favorite book" is a bad question because “The Bible” is a very common answer) 
6. Temporary passwords and links should have a short expiration time
7. Enforce the changing of temporary passwords on the next use
8. Prevent password re-use
9. Disable "remember me" functionality for password fields.
10. If using third party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code 

Session Management:

1. Session identifier creation must always be done on a trusted system 
2. Logout functionality should fully terminate the associated session or connection 
3. Logout functionality should be available from all pages protected by authorization 
4. Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements. In most cases it should be no more than several hours 
5. Do not allow concurrent logins with the same user ID 
6. Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication. Within an application, it is recommended to consistently utilize HTTPS rather than switching between HTTP to HTTPS.

Access Control:

1. Access controls should fail securely.
2. Deny all access if the application cannot access its security configuration information 
3. Enforce authorization controls on every request, including those made by server side scripts, "includes" and requests from rich client-side technologies like AJAX and Flash 
4. Segregate privileged logic from other application code 
5. Restrict access to files or other resources, including those outside the application's direct control, to only authorized users 
6. Restrict access to protected URLs to only authorized users 
7. Restrict access to protected functions to only authorized users 
8. Restrict direct object references to only authorized users 
9. Restrict access to services to only authorized users 
10. Restrict access to application data to only authorized users 
11. Restrict access to user and data attributes and policy information used by access controls 
12. Restrict access security-relevant configuration information to only authorized users 

Cryptographic Practices:

1. All random numbers, random file names, random GUIDs, and random strings should be generated using the cryptographic module’s approved random number generator when these random values are intended to be un-guessable
2. 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  Properly free allocated memory when error conditions occur 
5. Error handling logic associated with security controls should deny access by default 
6. All logging controls should be implemented on a trusted system (e.g., The server) 
7. Logging controls should support both success and failure of specified security events.
8. Log all input validation failures 
9. Log all authentication attempts, especially failures 
10. Log all access control failures 
11. Log all apparent tampering events, including unexpected changes to state data 
12. Log attempts to connect with invalid or expired session tokens 
13. Log all system exceptions 
14. Log all administrative functions, including changes to the security configuration settings 
15. Log all backend TLS connection failures  Log cryptographic module failures 
16. 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, like authentication verification data, even on the server side. Always use well vetted algorithms, see "Cryptographic Practices" for additional guidance 
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 noncryptographically secure manner on the client side. This includes embedding in insecure formats like: MS viewstate, Adobe flash or compiled code 
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 

Memory Management:

1. Utilize input and output control for un-trusted data
2. Double check that the buffer is as large as specified 
3. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string
4. Check buffer boundaries if calling the function in a loop and make sure there is no danger of writing past the allocated space 
5. Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions 
6. Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.)  Use non-executable stacks when available 
7. Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.) 
8. Properly free allocated memory upon the completion of functions and at all exit points

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. Checking for file type by extension alone is not sufficient 
5. Do not save files in the same web context as the application. Files should either go to the content server or in the database. 
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 a white list of allowed file names and types. Validate the value of the parameter being passed and if it does not match one of the expected values, either reject it or use a hard coded default file value for the content instead 
10. Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs 
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

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. Utilize strong passwords/phrases or implement multi-factor authentication