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