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 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

\newpage