Secure Coding Practices Checklist

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 validates 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 encodes 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 the 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 such 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 before 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 a 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 to 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 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 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 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 the 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 as 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 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, before 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 on different pages in the application.

• Disable unnecessary HTTP methods.

• If the web server handles different versions of HTTP ensure that they are configured similarly 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. (Ex:- 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. (Ex:- read-only user, guest, administrator)

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 a 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 several bytes ensure that NULL termination 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 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 avoid 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 the business necessity and validate safe functionality.

• Implement safe updating using encrypted channels.

Reference

• OWASP Secure Coding Practices