No

1. Input Validation
1.10
1.20
1.30
1.40
1.50
1.60
1.70
1.80
1.90
1.10
1.11
1.12
1.13
1.14
1.15
1.16
2. Output Encoding
2.10
2.20
2.30
2.40
2.50
2.60
3. Authentication and Password Management
3.10
3.20
3.30
3.40
3.50
3.60
3.70
3.80
3.90
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
3.33
3.34
3.35
4. Session Management
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
5. Access Control
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
6. Cryptographic Practices
6.10
6.20
6.30
6.40
6.50
6.60
7. Error Handling and Logging
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
7.22
7.23
7.24
8. Data Protection
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
9. Communication Security
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
10. System Configuration
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
10.11
10.12
10.13
10.14
10.15
10.16
11. Database Security
11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
11.9
11.10
11.11
11.12
11.13
12. File Management
12.1
12.2
12.3
12.4
12.5
12.6
12.7
12.8
12.9
12.10
12.11
12.12
12.13
12.14
13. Memory Management
13.10
13.20
13.30
13.40
13.50
13.60
13.70
13.80
13.90
14. General Coding Practices
14.10
14.20
14.30
14.40
14.50
14.60
14.70
14.80
14.90
14.10
14.11
14.12
Test Case
1. Input Validation
Conduct all data validation on a trusted system
Identify all data sources and classify them
Centralized input validation routine
Specify proper character sets
Encode data to a common character set
All validation failures result in input rejection
Determine system support for UTF-8 extended character sets
Validate all client-provided data
Verify header values contain only ASCII characters
Validate data from redirects
Validate for expected data types
Validate data range
Validate data length
Validate all input against a "white" list
Handle hazardous characters < > " ' % ( ) & + \ \' \"
Check specific inputs
2. Output Encoding
Conduct all encoding on a trusted system
Utilize a standard, tested routine for each type of outbound encoding
Contextually output encode all data returned to the client
Encode all characters unless they are known to be safe
Contextually sanitize output of untrusted data to queries
Sanitize output of untrusted data to operating system commands
3. Authentication and Password Management
Require authentication for all pages and resources
Enforce all authentication controls on a trusted system
Establish and use standard, tested authentication services
Use a centralized implementation for all authentication controls
Segregate authentication logic from requested resources
Ensure secure failure of authentication controls
Secure administrative and account management functions
Secure storage of password hashes
Implement password hashing on a trusted system
Validate authentication data after all data input
Secure authentication failure responses
Use authentication for connections to external systems
Encrypt and store external authentication credentials
Use only HTTP POST requests for authentication credentials
Send non-temporary passwords over encrypted connections
Enforce password complexity requirements
Enforce password length requirements
Obscure password entry on the user's screen
Enforce account disabling after invalid login attempts
Secure password reset and change operations
Use random security questions
Send reset information to pre-registered email addresses
Set short expiration times for temporary passwords
Enforce changing of temporary passwords on first use
Notify users of password resets
Prevent password re-use
Enforce a waiting period for password changes
Enforce periodic password changes
Disable "remember me" functionality for password fields
Report last account activity to users
Implement monitoring for multi-account attacks
Change default passwords and user IDs
Re-authenticate users before critical operations
Implement Multi-Factor Authentication for sensitive accounts
Inspect third-party authentication code
4. Session Management
Use Server or Framework Session Management
Create Session Identifiers on a Trusted System
Use Secure Session Algorithms
Set Domain and Path for Cookies
Properly Terminate Sessions on Logout
Accessible Logout
Session Timeout
Avoid Persistent Logins
Close Old Session on Login
Generate New Session Identifier on Re-authentication
No Concurrent Logins with the Same User ID
Hide Session Identifiers
Protect Server-Side Session Data
Rotate Session Identifiers
Switch to HTTPS
Use Strong Tokens for Sensitive Operations
Use Strong Tokens for Critical Operations
Set "Secure" Attribute for Cookies
Use HttpOnly for Cookies
5. Access Control
Use only trusted system objects for access authorization
Implement a single site-wide component for access authorization
Secure failure of access controls
Deny all access if security configuration information is unavailable
Enforce authorization controls on every request
Segregate privileged logic from other application code
Restrict access to files and resources to authorized users
Restrict access to protected URLs to authorized users
Restrict access to protected functions to authorized users
Restrict direct object references to authorized users
Restrict access to services to authorized users
Restrict access to application data to authorized users
Restrict access to user and data attributes to authorized users
Restrict access to security-relevant configuration information
Ensure consistency between server-side access control rules
Use encryption and integrity checking for client-stored state data
Enforce compliance with business rules in application logic flows
Limit the number of transactions per user or device
Use the "referer" header as a supplemental check
Periodically re-validate user authorization
Implement account auditing and disabling of unused accounts
Support disabling of accounts and session termination
Assign least privilege to service accounts
Create an Access Control Policy to document access criteria
6. Cryptographic Practices
Implement cryptographic functions on a trusted system
Protect master secrets from unauthorized access
Ensure cryptographic modules fail securely
Use approved random number generators for un-guessable values
Comply with cryptographic standards
Implement key management policies and processes
7. Error Handling and Logging
Do not disclose sensitive information in error responses
Use error handlers that do not display debugging or stack trace information
Implement generic error messages and use custom error pages
Handle application errors without relying on server configuration
Free allocated memory properly when error conditions occur
Security controls in error handling logic should deny access by default
Implement logging controls on a trusted system
Support logging for both success and failure of specified security events
Ensure logs contain important log event data
Prevent log entries with un-trusted data from executing as code
Restrict access to logs to authorized individuals
Utilize a master routine for all logging operations
Do not store sensitive information in logs
Ensure mechanisms exist for 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 security configuration settings
Log backend TLS connection failures
Log cryptographic module failures
Use cryptographic hash functions to validate log entry integrity
8. Data Protection
Implement least privilege, restrict users to only the required functionality, data, and system information
Protect cached or temporary copies of sensitive data on the server from unauthorized access and purge them when no longer need
Encrypt highly sensitive stored information, like authentication verification data, even 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 insecure formats on the client side
Remove comments in user-accessible production code that may reveal sensitive information
Remove unnecessary application and system documentation that could reveal information to attackers
Do not include sensitive information in HTTP GET request parameters
Disable auto-complete features on forms with sensitive information, including authentication
Disable client-side caching on pages with sensitive information
Support the removal of sensitive data when no longer required
Implement access controls for sensitive data stored on the server, including cached data, temporary files, and data accessible only
9. Communication Security
Implement encryption for the transmission of all sensitive information, including TLS for protecting the connection
Ensure TLS certificates are valid, have the correct domain name, not expired, and installed with intermediate certificates when req
Prevent failed TLS connections from falling back to an insecure connection
Use TLS connections for all content requiring authenticated access and other sensitive information
Use TLS for connections to external systems involving sensitive information or functions
Use 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
10. 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
Define which HTTP methods (GET or POST) the application will support and whether they will be handled differently
Disable unnecessary HTTP methods, such as WebDAV extensions
Ensure the web server handles HTTP 1.0 and 1.1 in a similar manner or understands any differences
Remove unnecessary information from HTTP response headers related to the OS, web server version, and application framework
The security configuration store for the application should be output in human-readable form to support auditing
Implement an asset management system and register system components and software
Isolate development environments from the production network and provide access only to authorized development and test group
Implement a software change control system to manage and record changes to the code
11. 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 comman
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 configuratio
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. Utilize strong passwords/phrases or implement multi-factor auth
Turn off all unnecessary database functionality (e.g., unnecessary stored procedures or services, utility packages, install only the m
Remove unnecessary default vendor content (e.g., 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 (e.g., user, read-only user, gue
12. 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. Checking for file type by extension alone is not sufficient
Do not save files in the same web context as the application. Files should either go to the content server or in the database.
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 chro
When referencing existing files, use a white list of allowed file names and types. Validate the value of the parameter being passed
Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, rela
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
13. Memory Management
Utilize input and output control for un-trusted data
Double check that the buffer is as large as specified
When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equa
Check buffer boundaries if calling the function in a loop and make sure there is no danger of writing past the allocated space
Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions
Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.)
Use non-executable stacks when available
Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.)
Properly free allocated memory upon the completion of functions and at all exit points
14. 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 t
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 pos
Avoid calculation errors by understanding your programming language's underlying representation and how it interacts with nume
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, a
Implement safe updating. If the application will utilize automatic updates, then use cryptographic signatures for your code and en
Scenario

Ensure that all data validation is performed on the server, not on the client side. This prevents validation rules from being bypasse
Classify data sources as trusted (e.g., internal databases) or untrusted (e.g., user input, external APIs). Validate all data from untru
Implement a centralized input validation routine to ensure consistent and thorough validation across the application.
Define a consistent character set, such as UTF-8, for all sources of input to avoid encoding mismatches and potential security vul
Convert data to a common character set (e.g., UTF-8) before validation to ensure consistent handling and prevent encoding-based
Upon validation failure, reject the input and prevent further processing. This prevents malicious data from entering the system.
Determine if the system supports UTF-8 extended character sets. If supported, validate input after UTF-8 decoding is completed.
Validate all input from the client, including parameters, URLs, HTTP headers, and automated postbacks, to prevent malicious cod
Ensure that header values in both requests and responses contain only ASCII characters to prevent potential attacks exploiting cha
Validate data from redirects to prevent malicious content from being directly submitted to the redirect target, bypassing applicatio
Verify that input matches the expected data type, such as integer, string, or date, to prevent type-related errors and potential vulne
Check that input values fall within the expected range to prevent overflow or underflow conditions that could lead to vulnerabiliti
Limit the length of input to prevent buffer overflows and other length-based attacks.
Whenever possible, validate input against a whitelist of allowed characters to restrict the range of acceptable input and prevent m
If potentially hazardous characters must be allowed as input, implement additional controls like output encoding and secure APIs.
If standard validation fails, check for specific problematic characters, including null bytes (%00), new line characters (%0d, %0a,

Ensure that all encoding of output data is performed on the server, not on the client side, to prevent tampering and security vulner
Employ well-tested and standardized encoding routines for different data types, such as HTML entity encoding, to ensure consiste
Apply output encoding to all data that originates outside the application's trust boundary and is returned to the client. Use appropr
Encode all characters in output data unless they are explicitly known to be safe for the intended interpreter to prevent malicious c
Sanitize all output of untrusted data to prevent injection attacks in queries for SQL, XML, and LDAP. Apply contextual sanitation
Sanitize all output of untrusted data before incorporating it into operating system commands to prevent malicious code execution

Ensure that authentication is required for all pages and resources, except those specifically intended to be public.
Implement all authentication controls on the server, not on the client side, to prevent tampering with authentication logic.
Utilize established and tested authentication services whenever possible, such as Google Sign-In or OAuth, to simplify secure aut
Implement a centralized authentication mechanism for all authentication-related processes, providing a single point of control for
Separate authentication logic from the resource being requested and use redirection to and from the centralized authentication con
Authentication controls should fail securely, with responses not revealing which part of the authentication data was incorrect.
Apply the same level of security controls to administrative and account management functions as to the primary authentication m
If the application manages a credential store, ensure that only cryptographically strong one-way salted hashes of passwords are st
Perform password hashing on the server, not on the client side, to protect the hashing algorithm and salt values from exposure.
Validate the authentication data only after all data input is complete, especially for sequential authentication implementations.
Authentication failure responses should not indicate which part of the authentication data was incorrect.
Utilize authentication for connections to external systems involving sensitive information or functions.
Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location
Transmit authentication credentials using only HTTP POST requests to prevent exposure in URL parameters, which can be easily
Only send non-temporary passwords over encrypted connections or as encrypted data to protect them from interception.
Enforce password complexity requirements based on policy or regulations to enhance password security.
Enforce password length requirements based on policy or regulations to ensure stronger passwords.
Password entry should be obscured on the user's screen, using input type "password" on web forms.
Implement account disabling after a set number of invalid login attempts to deter brute force attacks.
Password reset and change operations should have the same level of security controls as account creation and authentication.
Password reset questions should support sufficiently random answers to enhance security.
If using email-based resets, only send email to pre-registered addresses with a temporary link or password.
Temporary passwords and links should have a short expiration time to reduce the risk of unauthorized access if they are comprom
Require users to change temporary passwords immediately upon first use to prevent prolonged use of insecure temporary passwor
Inform users when a password reset occurs to alert them of potential unauthorized access.
Implement mechanisms to discourage users from reusing old passwords to promote stronger and unique passwords.
Implement a delay between password creation and the first password change to prevent attackers from immediately changing the
Implement a policy requiring periodic password changes, with the time between resets being administratively controlled.
Disable the "remember me" option for password fields, especially on public or shared devices to enhance security.
Notify users of the last successful or unsuccessful login attempt to keep them informed about account activity.
Monitor and identify attacks against multiple user accounts using the same password, a common pattern used to bypass standard l
Change all vendor-supplied default passwords and user IDs or disable the associated accounts to prevent unauthorized access.
Require users to re-authenticate before performing critical operations, adding an extra layer of security for sensitive actions.
Use Multi-Factor Authentication (MFA) for highly sensitive or high-value transactional accounts to add an additional layer of sec
If using third-party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code.

Utilize the built-in session management provided by your web server or framework. This ensures that your application recognizes
Generate session identifiers (like cookies) on the server to prevent tampering.
Choose strong, secure algorithms for generating session identifiers. They should be random and unpredictable.
Limit where cookies with session IDs can be used by setting their domain and path.
Ensure that the logout function fully terminates the user's session or connection.
Provide a logout option on all pages protected by authorization, so users can easily log out.
Set a short session inactivity timeout, usually a few hours, to balance security and user convenience.
Do not allow users to stay logged in indefinitely. Log them out periodically, even during an active session.
If a user had a session before login, close that session and create a new one after successful login.
Whenever a user re-authenticates (e.g., changing their password), generate a new session identifier.
Prevent multiple simultaneous logins with the same user ID.
Do not expose session identifiers in URLs, error messages, or logs. Store them securely in the HTTP cookie header.
Implement access controls on the server to prevent unauthorized access to session data by other users or processes on the server.
Periodically generate new session identifiers and deactivate the old ones. This prevents session hijacking if the original identifier
Change the session identifier if the connection security switches from HTTP to HTTPS. Maintain HTTPS consistently within you
For sensitive server-side actions (e.g., account management), use strong random tokens or parameters to prevent Cross-Site Requ
For highly sensitive or critical operations, use per-request, rather than per-session, strong random tokens or parameters.
Mark cookies as "secure" when transmitted over a TLS (HTTPS) connection to prevent interception.
Set cookies with the HttpOnly attribute unless you specifically need client-side scripts to read or set a cookie's value.

Use only trusted system objects, such as server-side session objects, for making access authorization decisions.
Use a single site-wide component to check access authorization, including libraries that call external authorization services.
Access controls should fail securely, ensuring that unauthorized users cannot gain access to restricted resources.
Deny all access if the application cannot access its security configuration information, ensuring that security settings are enforced
Enforce authorization controls on every request, including those made by server-side scripts, "includes," and requests from rich cl
Segregate privileged logic from other application code to prevent unauthorized access to sensitive operations.
Restrict access to files and resources, including those outside the application's control, to only authorized users.
Ensure that access to protected URLs is restricted to only authorized users.
Restrict access to protected functions to only authorized users.
Limit access to direct object references to only authorized users.
Ensure that access to services is restricted to only authorized users.
Limit access to application data to only authorized users.
Control access to user and data attributes and policy information by authorized users.
Limit access to security-relevant configuration information to authorized users.
Ensure that server-side implementation and presentation layer representations of access control rules match.
If state data must be stored on the client, use encryption and integrity checking on the server side to prevent tampering.
Enforce application logic flows to comply with business rules, ensuring that application behavior aligns with business requiremen
Limit the number of transactions a single user or device can perform within a given period to deter automated attacks.
Use the "referer" header as a supplemental check, but not as the sole authorization check, as it can be spoofed.
If long authenticated sessions are allowed, periodically re-validate a user's authorization to ensure their privileges have not change
Implement account auditing and enforce the disabling of unused accounts, such as after 30 days from the expiration of an account
The application must support disabling of accounts and terminating sessions when authorization ceases, such as changes to roles,
Service accounts or accounts used for connections to external systems should have the least privilege necessary.
Create an Access Control Policy to document an application's business rules, data types, and access authorization criteria or proce

All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system, such as th
Protect master secrets used in cryptographic operations from unauthorized access, ensuring they are not exposed to potential attac
Cryptographic modules should fail securely to prevent potential security vulnerabilities in case of errors or attacks.
All random numbers, random file names, random GUIDs, and random strings should be generated using the cryptographic modul
Cryptographic modules used by the application should be compliant with standards such as FIPS 140-3 or an equivalent standard.
Establish and utilize a policy and process for how cryptographic keys will be managed to maintain the security and integrity of cr

Error responses should not reveal sensitive information like system details, session identifiers, or account information.
Error handlers should be configured not to reveal debugging or stack trace information to potential attackers.
Use custom error pages with generic error messages to prevent leaking sensitive information to users or attackers.
The application should handle its errors independently without relying solely on server configuration.
Ensure that allocated memory is correctly freed when error conditions occur to prevent memory leaks.
Error handling logic associated with security controls should deny access by default to avoid potential security vulnerabilities.
All logging controls should be implemented on a trusted system, such as the server.
Logging controls should record both successful and failed security events for comprehensive security monitoring.
Log entries should contain essential event data to help in diagnosing and understanding security incidents.
Ensure that log entries containing untrusted data cannot execute as code in log viewing interfaces or software.
Only authorized personnel should have access to logs, ensuring the confidentiality and integrity of log data.
Implement a centralized routine for all logging operations to maintain consistency and reliability.
Avoid storing sensitive information like system details, session identifiers, or passwords in log entries.
Implement mechanisms to conduct log analysis and monitoring of security events to detect anomalies or potential threats.
Record log entries for input validation failures to track and investigate potential security issues.
Record log entries for authentication attempts, particularly failures, to monitor potential unauthorized access attempts.
Record log entries for access control failures to monitor and address unauthorized access incidents.
Log events that indicate potential tampering or unexpected changes to the application's state data.
Record log entries for attempts to connect with invalid or expired session tokens to detect potential session-related security threat
Record log entries for system exceptions to identify and troubleshoot potential issues.
Document log entries for administrative functions, especially changes to security configuration settings.
Record log entries for backend TLS (Transport Layer Security) connection failures to detect potential security issues with secure
Document log entries for cryptographic module failures to identify and respond to potential cryptographic issues.
Employ cryptographic hash functions to verify the integrity of log entries and detect tampering.

Restrict users to only the functionality, data, and system information necessary for them to perform their tasks.
Ensure that cached or temporary copies of sensitive data are protected from unauthorized access, and delete them as soon as they
Use strong encryption for highly sensitive stored information, such as authentication verification data, even on the server.
Ensure that server-side source code is protected from being downloaded by users.
Avoid storing sensitive information like passwords or connection strings in clear text or insecure formats on the client side, such
Remove comments in user-accessible production code that could reveal backend system or sensitive information.
Remove any unnecessary documentation from the application and system that may reveal useful information to potential attackers
Avoid sending sensitive information in HTTP GET request parameters as it may be exposed in URLs or logs.
Disable auto-complete features on forms that may contain sensitive information, including login and authentication forms.
Disable client-side caching on pages containing sensitive information to prevent data from being stored locally.
Implement functionality to delete sensitive data when it is no longer needed, such as personal information or certain financial data
Ensure that sensitive data stored on the server, including cached data and temporary files, is protected by appropriate access contr

Ensure that all sensitive information is transmitted using encryption, such as TLS (Transport Layer Security), to protect the data d
Validate that TLS certificates used for securing connections are valid, have the correct domain name, are not expired, and include
Ensure that when a TLS connection fails, it does not fall back to an insecure or unencrypted connection, which could expose sens
Utilize TLS (or its equivalent) for securing connections to any content that requires authenticated access or any other sensitive inf
Employ TLS for securing connections to external systems that deal with sensitive information or critical functions.
Implement a consistent and standard TLS configuration throughout the application to ensure proper and secure encryption.
Specify character encodings for all data transmitted over connections to avoid character encoding issues that can lead to security v
Exclude parameters containing sensitive information from the HTTP referer header when linking to external websites to prevent d

Regularly check and update servers, frameworks, and system components to the latest approved versions to mitigate vulnerabilitie
Apply all security patches and updates issued for the specific version of servers, frameworks, and system components in use to ad
Disable directory listings to prevent exposing sensitive information about the web server's directory structure to potential attacker
Limit the permissions and access rights of web server, process, and service accounts to only what is necessary to perform their fu
Implement error handling routines that ensure the application fails securely when exceptions or errors occur, preventing the expos
Eliminate any features, functions, or files that are not essential for the application's operation, reducing the attack surface.
Ensure that test code or features not intended for production use are removed from the application before it is deployed.
Avoid exposing directory structures by isolating directories not intended for public indexing in an isolated parent directory and di
Clearly specify which HTTP methods (e.g., GET or POST) the application supports and whether they are handled differently on d
Deactivate any unnecessary HTTP methods, especially extensions like WebDAV, and only use well-vetted authentication mechan
Ensure that the web server is configured to handle both HTTP 1.0 and 1.1 consistently or understands any distinctions between th
Minimize the information revealed in HTTP response headers to avoid disclosing details about the server's operating system, web
Ensure that the security configuration settings of the application can be displayed in a human-readable format to facilitate auditing
Establish an asset management system to catalog and register all system components and software to monitor and maintain them
Segregate development environments from the production network, restricting access to authorized development and test groups.
Employ a software change control system to oversee and document changes made to the code, both in development and productio

Employ parameterized queries with strongly typed parameters to interact with the database, preventing SQL injection attacks.
Apply input validation and output encoding to sanitize data, ensuring that meta characters are addressed to protect against security
Ensure that variables used in database operations are strongly typed to prevent type-related vulnerabilities.
Limit the privileges granted to the application when interacting with the database to minimize the potential impact of security bre
Implement strong and secure credentials when connecting to the database to protect against unauthorized access.
Avoid hardcoding database connection strings in the application code. Store connection strings in a separate, encrypted configurat
Utilize stored procedures to access data, providing an abstraction layer and enabling the removal of permissions to base tables.
Close the database connection as soon as it is no longer needed to reduce the risk of unauthorized access or data exposure.
Eliminate or update default administrative passwords for the database, replacing them with strong passwords or implementing mu
Disable unnecessary database functionality and features, such as stored procedures or services, to reduce the attack surface.
Eliminate unnecessary default content provided by the database vendor, such as sample schemas or data, which can pose security
Deactivate or disable any default user accounts that are not needed to fulfill business requirements.
Use distinct credentials for database connections based on trust levels, such as separate credentials for regular users, read-only acc

Avoid directly passing user-supplied data to dynamic include functions to prevent code execution vulnerabilities.
Ensure that users are authenticated before they are allowed to upload files to the application to prevent unauthorized file uploads.
Allow only specific types of files to be uploaded that are relevant to the application's business requirements.
Verify the file type of uploaded files by examining their headers to ensure they match the expected format, as relying solely on fi
Store uploaded files in a location separate from the web application's context to avoid security risks. Uploaded files should be pla
Avoid uploading files that can be interpreted as code by the web server, as this may introduce security vulnerabilities.
Disable execution privileges on directories where files are uploaded to prevent the execution of uploaded files.
Secure file uploading in UNIX environments by mounting the target directory as a logical drive or using the chrooted environmen
Employ a white list of permitted file names and types when referencing existing files, validating the parameters being passed. If a
Avoid passing user-supplied data into dynamic redirects. If necessary, ensure that the redirect accepts only validated, relative path
Avoid passing directory or file paths as user input, and instead, use index values associated with a predefined list of paths to enha
Avoid disclosing absolute file paths to clients, as this information can potentially be exploited by attackers.
Set appropriate file permissions to make application files and resources read-only, preventing unauthorized modification.
Implement virus and malware scanning for files uploaded by users to prevent malicious content from entering the application.

Employ input and output controls to manage data from untrusted sources, ensuring that the data is processed safely and securely.
Verify that buffer sizes match the expected size to prevent buffer overflows and memory corruption vulnerabilities.
Exercise caution when using functions like strncpy() and understand that if the destination buffer size is the same as the source bu
Ensure that buffer boundaries are validated when calling functions in loops, preventing potential buffer overflows and data corrup
Limit the length of input strings to a reasonable size before using copy and concatenation functions to prevent buffer overflows.
Explicitly close resources such as connection objects and file handles instead of relying on garbage collection to ensure timely res
Employ non-executable stacks when possible to enhance security and prevent stack-based vulnerabilities.
Steer clear of using functions that are known to be vulnerable to security issues, such as printf, strcat, and strcpy.
Ensure that dynamically allocated memory is correctly deallocated at the end of functions and at all exit points to prevent memory

Prefer using well-tested managed code libraries and APIs for common tasks over developing custom unmanaged code.
Employ built-in APIs specific to the task at hand to perform operating system-related actions. Avoid allowing the application to e
Verify the integrity of interpreted code, libraries, executables, and configuration files using checksums or cryptographic hashes to
Employ locking mechanisms to prevent multiple simultaneous requests or utilize synchronization to avoid race conditions in mult
Safeguard shared variables and resources to prevent inappropriate concurrent access that could lead to data corruption or inconsis
Ensure that all variables and data stores are explicitly initialized either during declaration or right before their first usage to preve
If the application needs to run with elevated privileges, elevate those privileges only when necessary and reduce them to the least
Prevent calculation errors by having a deep understanding of your programming language's numeric representation and how it han
Avoid passing data provided by users to functions that dynamically execute code, as this can lead to code injection vulnerabilities
Prevent users from generating or modifying code to maintain control over the application's behavior and security.
Conduct a thorough review of secondary applications, third-party code, and libraries to assess their necessity and ensure that their
Implement secure update mechanisms, especially if your application supports automatic updates. Utilize cryptographic signatures
Example

When a user submits a form, the server checks the input data for validity and rejects it if it doesn't meet the criteria. Client-side Ja
When processing data from user-submitted forms and external APIs, ensure that all input is thoroughly validated, regardless of its
Create a single validation function that is called for all user input, ensuring that every input is consistently validated according to
Ensure that all data, regardless of its source, is consistently encoded using UTF-8 to prevent encoding-related issues.
Before validating user input, convert it to UTF-8 to standardize character encoding.
If a user submits invalid input, the system should reject it and not proceed with any further actions.
If the application supports extended character sets, ensure that validation occurs after decoding, addressing potential encoding-rel
When processing data from client-side sources, such as form submissions and HTTP headers, validate it rigorously to avoid code
Check that header values are limited to ASCII characters to prevent security issues stemming from character encoding variations.
When handling data from redirects, ensure that it is validated to prevent security bypasses.
Check that input is of the correct data type to avoid errors and security issues caused by data type mismatches.
Ensure that input values are within specified ranges to prevent security issues related to data overflow or underflow.
Restrict the length of input data to mitigate security risks associated with buffer overflows and other length-based vulnerabilities.
Ensure that input is validated against a predefined whitelist of permissible characters to minimize security risks.
If your application requires the use of hazardous characters, apply additional security measures like output encoding and secure A
If standard validation doesn't catch certain inputs, inspect for problematic characters like null bytes, new line characters, path alte

When generating HTML for a web page, the server should encode special characters to prevent cross-site scripting (XSS) vulnera
Use a trusted library or built-in functions for encoding data, such as HTML entity encoding for web content.
When displaying user-generated content on a web page, use HTML entity encoding to prevent HTML injection.
Encode special characters like "<" and ">" in user-generated content to prevent XSS attacks.
When constructing an SQL query from user input, sanitize the input to prevent SQL injection, ensuring that the user input doesn't
When executing shell commands with user input, sanitize the input to ensure that it doesn't contain harmful commands that could

All users accessing the application should be required to authenticate themselves, except for publicly accessible information like a
Authentication checks should be performed on the server to ensure the security of the process.
Implementing authentication through widely recognized and tested services like Google Sign-In enhances security and user exper
Authentication should be handled through a centralized system that manages user credentials and permissions.
Authentication processes should not be mixed with resource processing, and redirection to a centralized authentication control sho
If authentication fails, the system should provide a generic message like "Invalid username and/or password" without indicating w
Administrative actions and account management should have the same level of security as user authentication.
Passwords should be stored securely using strong hashing algorithms, and access to the storage should be tightly controlled.
Password hashing should occur on the server to maintain the security of the hashing process.
In a multi-step authentication process, data should be validated only after all steps are completed.
Error responses in case of authentication failure should provide the same message, such as "Invalid username and/or password," w
When accessing external systems with sensitive data, ensure that authentication is required to establish secure connections.
External service credentials should be securely stored and not kept in the application's source code.
User credentials should be sent using HTTP POST requests to avoid exposing them in URLs.
Non-temporary passwords should be transmitted securely to prevent eavesdropping.
Passwords should meet complexity requirements, such as including alphabetic, numeric, and special characters.
Passwords should meet length requirements, which may include a minimum length of eight characters or more.
When users enter passwords, the input should be masked to prevent visual observation.
After a specified number of failed login attempts, user accounts should be temporarily disabled.
The processes for resetting and changing passwords should be as secure as initial account creation and authentication.
Instead of using easily guessable questions like "favorite book," use questions that have less predictable answers.
When resetting passwords via email, send reset information only to email addresses that are pre-registered by the user.
Temporary passwords should only be valid for a short period, such as 24 hours.
Users should be prompted to change temporary passwords the first time they log in.
Users should receive notifications when their passwords are reset to keep them informed about security events.
Users should be prevented from using their old passwords when creating new ones.
Users should not be allowed to change their password immediately after creating it.
Passwords should be changed at regular intervals as specified by the policy.
Users should not be given the option to have their password remembered on public or shared devices.
Users should be aware of the last login attempts to detect any suspicious activity.
The system should detect and prevent attacks where multiple accounts are targeted using the same password.
Vendor-supplied default credentials should be replaced or disabled to prevent unauthorized access.
Users should re-enter their credentials before performing critical operations like changing account settings.
For highly sensitive accounts, require MFA to verify the user's identity.
When using third-party authentication code, thoroughly review it to check for vulnerabilities or malicious code.

If you're using a web framework like Express.js in Node.js, use its session management features.
When a user logs in, the server generates a unique session ID and sends it to the user's browser.
Instead of using a simple incremental number, use a cryptographically secure random string as the session identifier.
If your site is "example.com," restrict the cookie's domain to ".example.com" to prevent it from being used on other subdomains.
When a user clicks "Logout," their session is invalidated, and they are redirected to the login page.
Include a "Logout" link in the navigation menu on every page.
Automatically log the user out after 15 minutes of inactivity.
Prompt the user to re-enter their password after a set time, even if they are actively using the app.
When a user logs in, their previous session becomes invalid.
When a user updates their password, their session ID changes.
If a user is already logged in and tries to log in again from a different device, the previous session is invalidated.
Avoid displaying session IDs in the URL like "example.com?session=12345."
Only authorized server-side code can access and modify session data.
Every hour, generate a new session ID and invalidate the previous one.
If a user logs in via an insecure HTTP connection, generate a new session ID when they switch to a secure HTTPS connection.
When a user requests to change their password, generate a unique token to ensure the request is legitimate.
When processing a financial transaction, generate a unique token for each step of the transaction.
Ensure that cookies carrying session information are marked as "secure" to be transmitted only over secure HTTPS connections.
Use HttpOnly to prevent client-side scripts from accessing cookies containing sensitive session information.

Access authorization decisions should be based on information from trusted sources within the application.
Access to resources should be controlled consistently through a central component.
If a user is not authorized to access a resource, they should not be able to bypass the access control mechanism.
If the application is unable to access its security configuration, it should default to denying access.
Authorization checks should be consistently applied to all types of requests.
Critical functionality that requires elevated permissions should be isolated from regular application code.
Only users with the appropriate permissions should be able to access files and resources.
Users should be required to authenticate before accessing protected URLs.
Only users with proper permissions should be able to execute protected functions.
Users should not be able to access objects directly if they are not authorized.
Services should not be accessible to unauthorized users.
Users should have access only to the data they are authorized to see or modify.
User attributes and sensitive data should be restricted to authorized users.
Configuration settings related to security should not be accessible to unauthorized users.
Access control rules should be consistent between server-side implementation and the presentation layer.
State data stored on the client side should be encrypted and protected to prevent unauthorized modifications.
Application logic should adhere to business rules to maintain consistency and security.
Implement transaction limits to prevent abuse by automated systems or malicious users.
The "referer" header can be used as an additional security measure but should not be the only means of authorization.
Users with long sessions should have their authorization periodically re-validated to ensure that their privileges have not changed
Accounts that are not actively used should be disabled or removed to maintain security.
Accounts and sessions should be disabled when users no longer have authorization, such as when they change roles or leave the o
Service accounts should have only the permissions required for their specific tasks.
An Access Control Policy should outline the access requirements for data and system resources, defining who can access what an

Cryptographic operations should be performed on a trusted server rather than on the client side to prevent potential security risks.
Sensitive cryptographic keys and master secrets should be securely stored and protected against unauthorized access.
Cryptographic modules should be designed to handle errors or attacks in a way that doesn't compromise security.
To create unpredictable values, use approved cryptographic random number generators rather than relying on standard random fu
Cryptographic modules should meet established security standards to ensure their reliability and security.
Clearly defined policies and processes for managing cryptographic keys should be in place to ensure their proper use and security

Instead of displaying detailed error messages that could expose sensitive information, provide a generic error message like "An er
Avoid showing stack trace information in error messages, as it can provide insights into the application's internal workings.
Instead of displaying specific error messages, show custom error pages with general messages like "Page not found" or "Server er
Implement custom error handling logic within the application to manage and respond to errors effectively.
When an error is detected, release memory resources that were allocated to avoid memory leaks.
Configure security controls to deny access by default when encountering errors or unexpected conditions.
Ensure that log entries are generated and stored on a secure and trusted system to prevent tampering or unauthorized access.
Log successful security events, like user authentication, along with failed events for a complete audit trail.
Include relevant information such as timestamps, user identities, and event descriptions in log entries.
Implement proper encoding or escaping to prevent log entries with user input from being interpreted as executable code.
Control access to log files and systems containing logs to limit viewing privileges to authorized users.
Use a common function or routine for logging across the application to ensure uniformity and simplify maintenance.
Ensure that logs do not contain sensitive data that could be exploited if the logs were accessed by unauthorized parties.
Use log analysis tools and processes to regularly review and monitor log entries for security events.
Capture instances where input data fails validation checks, which may indicate security vulnerabilities.
Keep a record of all authentication attempts, with a focus on failed attempts, to detect and respond to potential security threats.
Document cases where access control mechanisms fail to prevent unauthorized access or actions.
Monitor and log suspicious events, like unauthorized changes to data or configuration settings.
Capture and investigate any attempts to use session tokens that are no longer valid or have been tampered with.
Capture and investigate system exceptions that may indicate problems within the application.
Maintain an audit trail of administrative actions, especially those related to security settings, for accountability and monitoring pu
Monitor and log any failures in secure connections between components of the application.
Capture events indicating failures or issues related to cryptographic modules used by the application.
Use hash functions to create checksums of log entries and validate their integrity during log analysis.

Users in a healthcare application should only have access to patient records they are authorized to view and not the entire databas
Delete cached copies of sensitive user data after the user logs out or when the data is no longer needed for processing.
Store user passwords using a secure hashing algorithm like bcrypt to protect them from unauthorized access.
Use appropriate access controls and server configurations to prevent users from accessing server-side source code.
Store sensitive information in a secure manner using encryption and secure storage practices.
Delete comments in the code that contain details about the application's architecture or system configurations.
Avoid publishing documentation that provides insights into the application's internal workings or configurations.
Instead of sending sensitive data as parameters in a URL, use HTTP POST requests or other secure methods.
Prevent browsers from automatically filling in sensitive data, such as usernames and passwords, to enhance security.
Set appropriate HTTP headers like "Cache-Control: no-store" to instruct browsers not to cache sensitive pages.
Allow users to request the removal of their personal data from the application when it's no longer necessary.
Implement access controls to restrict access to cached data and temporary files to only specific system users or roles.

When a user logs into an online banking application, their username and password are transmitted securely using TLS to prevent
An e-commerce website's TLS certificate should have the correct domain name, should not be expired, and should include all req
If a client fails to establish a TLS connection, it should not proceed with an unencrypted connection but should display an error m
When users access their email accounts, the connection should use TLS to protect the login credentials and email contents from in
When an application communicates with a third-party payment gateway to process financial transactions, it should use TLS to pro
Ensure that the application uses a well-established TLS implementation with the appropriate configuration settings to guarantee se
When transmitting data between a web server and a database, specify UTF-8 character encoding to ensure compatibility and prev
When a user clicks on an external link from an e-commerce website, the referer header should not include sensitive parameters lik

An organization should regularly update its web server software to the latest approved version to patch known security vulnerabil
After deploying a web application using a specific framework version, apply all available patches and updates released for that ve
When a web server receives a request for a directory that doesn't contain a default document (e.g., index.html), it should return a
A web server process should run with minimal privileges, granting access only to the directories and resources required for servin
If a web application encounters an unexpected exception, it should handle it gracefully by displaying a user-friendly error messag
An e-commerce website should remove any unused or unnecessary features, such as old product listings or deprecated functions,
Any test-related functionality in the application's codebase should be excluded from the production release, preventing unintended
If a website has directories containing configuration files or other sensitive data, these directories should be placed within a paren
In a RESTful web service, define which HTTP methods are allowed for various endpoints, indicating whether a particular endpoi
If a web application doesn't require the WebDAV HTTP extension for file management, it should disable this method to reduce p
If a web server accepts both HTTP 1.0 and HTTP 1.1 requests, it should process them in a consistent manner to prevent potential
HTTP response headers should not expose server details, such as "Server: Apache/2.4.29 (Unix) PHP/7.2.15" or "X-Powered-By:
A web application's security settings should be documented in a way that allows auditors to easily understand the configurations f
An organization should use an asset management system to keep an inventory of all servers, network devices, software, and hardw
Development and testing environments should be isolated from the live production network to minimize potential security risks a
Any modifications or updates to the application's source code should be documented in a change control system, including details

When querying a database for user authentication, use parameterized queries with strongly typed parameters like integers or string
When processing user-generated input for a search query, validate the input and ensure that it doesn't contain any unescaped meta
When passing variables to a database query, ensure that their data types match the expected data types in the database schema to
When connecting to the database, use a database user account with the minimum necessary privileges to perform the required ope
Use complex and unique passwords for database user accounts, and consider implementing multi-factor authentication for added s
Instead of directly embedding database connection strings in the code, store them in an encrypted configuration file external to th
Implement stored procedures in the database to abstract data access, ensuring that applications interact with the data through these
After executing a database query, promptly close the database connection to minimize the window of opportunity for potential att
When deploying a new database, change the default administrative passwords to strong, unique passwords, or implement multi-fa
When configuring a database server, only enable the features and options required for the application's functionality, turning off o
After installing a database system, remove sample schemas, tables, or data provided by the vendor, as they might contain security
If the database system includes default user accounts that are not essential for the application's functionality, disable or remove th
Implement role-based database access, providing different user roles with unique credentials and access rights to match their trust

Instead of using user input to dynamically include a file, use a predefined and validated list of files to include.
Only authenticated users should have the privilege to upload files.
If your application only requires image uploads, restrict file uploads to image file types (e.g., JPEG, PNG) and reject other file ty
When processing an uploaded file, check its header information to confirm its actual format rather than solely relying on the file e
Store uploaded files in a directory outside the web server's root directory to prevent direct access from the web.
Do not allow users to upload files like PHP, HTML, or JavaScript files that could be executed by the server.
Modify directory permissions to prevent any uploaded files from being executed by the web server.
When dealing with file uploads on UNIX systems, ensure that the uploaded files are placed in an isolated directory or chroot envi
When referencing files provided by users or external sources, validate the file names and types against a predefined white list, and
If your application allows dynamic redirects, ensure that the redirect URLs are either predefined and validated or accept only rela
When handling user input for file or directory paths, use predefined index values to reference specific paths rather than directly ac
When returning file paths or URLs to the client, ensure that they are relative paths and do not reveal the absolute file system struc
Configure file permissions on application files and resources to disallow write access, ensuring their integrity and preventing tam
When users upload files, automatically scan the files for viruses and malware to safeguard the application and its users from pote

When accepting user input, apply input controls such as input validation to validate and sanitize the data before using it in the app
When using functions that copy data into a buffer, double-check that the destination buffer is of the specified size and that it can a
When using strncpy(), be aware of its behavior and make sure to manually NULL-terminate the string if necessary to avoid issues
When using functions in loops that copy data into buffers, always check and control the loop's iteration to avoid writing data past
Before using copy or concatenation functions, truncate input strings to a predefined reasonable length to ensure they fit within the
When managing resources like database connections or file handles, always use explicit methods to close these resources once the
If your operating system or platform supports non-executable stacks, enable this feature to reduce the risk of stack-based buffer o
Instead of using functions like printf, strcat, or strcpy, opt for safer alternatives that do not exhibit known vulnerabilities, such as
When allocating memory dynamically (e.g., with malloc), always include code to release (free) the allocated memory in the funct

Instead of implementing custom unmanaged code for file I/O operations, use a widely accepted managed code library or API like
When interacting with the operating system, use APIs like System.Diagnostics.Process in C# to manage and execute external proc
Before loading a dynamically linked library, verify its integrity by comparing its hash value with a precomputed hash to ensure it
When managing shared resources, use locks or synchronization primitives such as mutexes to ensure that only one thread can acc
Protect shared data structures in a multi-threaded application by using proper locking mechanisms to ensure that multiple threads
Initialize variables with appropriate default values during declaration or initialize them just before their first use. For instance, ini
If your application requires elevated privileges to perform a specific task, raise those privileges only when executing that task, an
When performing mathematical calculations in a programming language, be aware of issues like integer overflow, floating-point
Do not allow users to provide input that is directly passed to functions capable of executing code dynamically, such as eval() or d
Avoid providing users with the capability to write or execute arbitrary code within the application, as this can lead to security risk
Before integrating third-party code or libraries into your application, carefully review and validate the code to confirm that it is bo
When delivering automatic updates for your application, ensure that the updates are digitally signed with a cryptographic signatur
before using it in the application. Similarly, use output controls like output encoding to prevent data from being executed as code when display

overflow, floating-point precision, and type conversion. Always ensure that numeric operations are consistent with your expectations and the la

a cryptographic signature to guarantee their authenticity. The download client should verify these signatures before applying updates. Encrypt
efore applying updates. Encrypt the communication channel between the host server and the client to protect the code updates from interception
he code updates from interception.