Last updated 3 months ago
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
