{“payload”:{“allShortcutsEnabled”:false,”fileTree”:{“Secure-Coding-Practices”:{“items”:[{“name”:”Secure-Coding-Practices.md”,”path”:”Secure-Coding-Practices/Secure-Coding-Practices.md”,”contentType”:”file”}],”totalCount”:1},””:{“items”:[{“name”:”Secure-Coding-Practices”,”path”:”Secure-Coding-Practices”,”contentType”:”directory”},{“name”:”README.md”,”path”:”README.md”,”contentType”:”file”}],”totalCount”:2}},”fileTreeProcessingTime”:3.85494,”foldersToFetch”:[],”reducedMotionEnabled”:null,”repo”:{“id”:714865529,”defaultBranch”:”main”,”name”:”Checklist”,”ownerLogin”:”Hari-prasaanth”,”currentUserCanPush”:false,”isFork”:false,”isEmpty”:false,”createdAt”:”2023-11-06T02:08:42.000Z”,”ownerAvatar”:”https://avatars.githubusercontent.com/u/107095268?v=4″,”public”:true,”private”:false,”isOrgOwned”:false},”symbolsExpanded”:false,”treeExpanded”:true,”refInfo”:{“name”:”main”,”listCacheKey”:”v0:1699236523.0″,”canEdit”:false,”refType”:”branch”,”currentOid”:”595509c13ddd4e724f607dc14e2623d6e8d8060f”},”path”:”Secure-Coding-Practices/Secure-Coding-Practices.md”,”currentUser”:null,”blob”:{“rawLines”:null,”stylingDirectives”:null,”csv”:null,”csvError”:null,”dependabotInfo”:{“showConfigurationBanner”:false,”configFilePath”:null,”networkDependabotPath”:”/Hari-prasaanth/Checklist/network/updates”,”dismissConfigurationNoticePath”:”/settings/dismiss-notice/dependabot_configuration_notice”,”configurationNoticeDismissed”:null,”repoAlertsPath”:”/Hari-prasaanth/Checklist/security/dependabot”,”repoSecurityAndAnalysisPath”:”/Hari-prasaanth/Checklist/settings/security_analysis”,”repoOwnerIsOrg”:false,”currentUserCanAdminRepo”:false},”displayName”:”Secure-Coding-Practices.md”,”displayUrl”:”https://github.com/Hari-prasaanth/Checklist/blob/main/Secure-Coding-Practices/Secure-Coding-Practices.md?raw=true”,”headerInfo”:{“blobSize”:”91.3 KB”,”deleteInfo”:{“deleteTooltip”:”You must be signed in to make or propose changes”},”editInfo”:{“editTooltip”:”You must be signed in to make or propose changes”},”ghDesktopPath”:”https://desktop.github.com”,”gitLfsPath”:null,”onBranch”:true,”shortPath”:”63d274a”,”siteNavLoginPath”:”/login?return_to=https%3A%2F%2Fgithub.com%2FHari-prasaanth%2FChecklist%2Fblob%2Fmain%2FSecure-Coding-Practices%2FSecure-Coding-Practices.md”,”isCSV”:false,”isRichtext”:true,”toc”:[{“level”:1,”text”:”Secure Coding Practices”,”anchor”:”secure-coding-practices”,”htmlText”:”Secure Coding Practices”},{“level”:3,”text”:”Contents:”,”anchor”:”contents”,”htmlText”:”Contents:”},{“level”:2,”text”:”1. Input Validation”,”anchor”:”1-input-validation”,”htmlText”:”1. Input Validation”},{“level”:2,”text”:”2. Output Encoding”,”anchor”:”2-output-encoding”,”htmlText”:”2. Output Encoding”},{“level”:2,”text”:”3. Authentication and Password Management”,”anchor”:”3-authentication-and-password-management”,”htmlText”:”3. Authentication and Password Management”},{“level”:2,”text”:”4. Session Management”,”anchor”:”4-session-management”,”htmlText”:”4. Session Management”},{“level”:2,”text”:”5. Access Control”,”anchor”:”5-access-control”,”htmlText”:”5. Access Control”},{“level”:2,”text”:”6. Cryptographic Practices”,”anchor”:”6-cryptographic-practices”,”htmlText”:”6. Cryptographic Practices”},{“level”:2,”text”:”7. Error Handling and Logging”,”anchor”:”7-error-handling-and-logging”,”htmlText”:”7. Error Handling and Logging”},{“level”:2,”text”:”8. Data Protection”,”anchor”:”8-data-protection”,”htmlText”:”8. Data Protection”},{“level”:2,”text”:”9. Communication Security”,”anchor”:”9-communication-security”,”htmlText”:”9. Communication Security”},{“level”:2,”text”:”10. System Configuration”,”anchor”:”10-system-configuration”,”htmlText”:”10. System Configuration”},{“level”:2,”text”:”11. Database Security”,”anchor”:”11-database-security”,”htmlText”:”11. Database Security”},{“level”:2,”text”:”12. File Management”,”anchor”:”12-file-management”,”htmlText”:”12. File Management”},{“level”:2,”text”:”13. Memory Management”,”anchor”:”13-memory-management”,”htmlText”:”13. Memory Management”},{“level”:2,”text”:”14. General Coding Practices”,”anchor”:”14-general-coding-practices”,”htmlText”:”14. General Coding Practices”},{“level”:2,”text”:”15. Glossary”,”anchor”:”15-glossary”,”htmlText”:”15. Glossary”}],”lineInfo”:{“truncatedLoc”:”452″,”truncatedSloc”:”370″},”mode”:”file”},”image”:false,”isCodeownersFile”:null,”isPlain”:false,”isValidLegacyIssueTemplate”:false,”issueTemplateHelpUrl”:”https://docs.github.com/articles/about-issue-and-pull-request-templates”,”issueTemplate”:null,”discussionTemplate”:null,”language”:”Markdown”,”languageID”:222,”large”:false,”loggedIn”:false,”newDiscussionPath”:”/Hari-prasaanth/Checklist/discussions/new”,”newIssuePath”:”/Hari-prasaanth/Checklist/issues/new”,”planSupportInfo”:{“repoIsFork”:null,”repoOwnedByCurrentUser”:null,”requestFullPath”:”/Hari-prasaanth/Checklist/blob/main/Secure-Coding-Practices/Secure-Coding-Practices.md”,”showFreeOrgGatedFeatureMessage”:null,”showPlanSupportBanner”:null,”upgradeDataAttributes”:null,”upgradePath”:null},”publishBannersInfo”:{“dismissActionNoticePath”:”/settings/dismiss-notice/publish_action_from_dockerfile”,”dismissStackNoticePath”:”/settings/dismiss-notice/publish_stack_from_file”,”releasePath”:”/Hari-prasaanth/Checklist/releases/new?marketplace=true”,”showPublishActionBanner”:false,”showPublishStackBanner”:false},”rawBlobUrl”:”https://github.com/Hari-prasaanth/Checklist/raw/main/Secure-Coding-Practices/Secure-Coding-Practices.md”,”renderImageOrRaw”:false,”richText”:”
- n
- OWASP Based Checklist 🌟🌟
- 200+ Test Cases 🚀🚀
n
n
n
Contents:
n
- n
- Input Validation
- Output Encoding
- Authentication and Password Management
- Session Management
- Access Control
- Cryptographic Practices
- Error Handling and Logging
- Data Protection
- Communication Security
- System Configuration
- Database Security
- File Management
- Memory Management
- General Coding Practices
- Glossary
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
nn
1. Input Validation
n
The “Input validation” section in your Secure Coding Practices checklist involves measures to ensure that data coming into your application is safe and free from potential security risks. It includes practices like conducting validation on trusted systems, distinguishing between trusted and untrusted data sources, specifying character sets, validating data types, lengths, and ranges, and being cautious about potentially hazardous characters. The goal is to prevent malicious data from entering your application and to handle it safely if it must be allowed. These practices help safeguard against common security vulnerabilities, such as injection attacks, by ensuring that only well-formed, expected, and safe data is processed.
n
n
| No | Test Case | Scenario | Example |
|---|---|---|---|
| 1.1 | Conduct all data validation on a trusted system | Ensure that all data validation is performed on the server, not on the client side. This prevents validation rules from being bypassed by manipulating client-side code. | 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 JavaScript should not be relied upon for validation. |
| 1.2 | Identify all data sources and classify them | Classify data sources as trusted (e.g., internal databases) or untrusted (e.g., user input, external APIs). Validate all data from untrusted sources to prevent malicious input. | When processing data from user-submitted forms and external APIs, ensure that all input is thoroughly validated, regardless of its source. |
| 1.3 | Centralized input validation routine | Implement a centralized input validation routine to ensure consistent and thorough validation across the application. | Create a single validation function that is called for all user input, ensuring that every input is consistently validated according to predefined rules. |
| 1.4 | Specify proper character sets | Define a consistent character set, such as UTF-8, for all sources of input to avoid encoding mismatches and potential security vulnerabilities. | Ensure that all data, regardless of its source, is consistently encoded using UTF-8 to prevent encoding-related issues. |
| 1.5 | Encode data to a common character set | Convert data to a common character set (e.g., UTF-8) before validation to ensure consistent handling and prevent encoding-based attacks. | Before validating user input, convert it to UTF-8 to standardize character encoding. |
| 1.6 | All validation failures result in input rejection | Upon validation failure, reject the input and prevent further processing. This prevents malicious data from entering the system. | If a user submits invalid input, the system should reject it and not proceed with any further actions. |
| 1.7 | Determine system support for UTF-8 extended character sets | Determine if the system supports UTF-8 extended character sets. If supported, validate input after UTF-8 decoding is completed. | If the application supports extended character sets, ensure that validation occurs after decoding, addressing potential encoding-related vulnerabilities. |
| 1.8 | Validate all client-provided data | Validate all input from the client, including parameters, URLs, HTTP headers, and automated postbacks, to prevent malicious code injection. | When processing data from client-side sources, such as form submissions and HTTP headers, validate it rigorously to avoid code injection vulnerabilities. |
| 1.9 | Verify header values contain only ASCII characters | Ensure that header values in both requests and responses contain only ASCII characters to prevent potential attacks exploiting character encoding differences. | Check that header values are limited to ASCII characters to prevent security issues stemming from character encoding variations. |
| 1.10 | Validate data from redirects | Validate data from redirects to prevent malicious content from being directly submitted to the redirect target, bypassing application logic. | When handling data from redirects, ensure that it is validated to prevent security bypasses. |
| 1.11 | Validate for expected data types | Verify that input matches the expected data type, such as integer, string, or date, to prevent type-related errors and potential vulnerabilities. | Check that input is of the correct data type to avoid errors and security issues caused by data type mismatches. |
| 1.12 | Validate data range | Check that input values fall within the expected range to prevent overflow or underflow conditions that could lead to vulnerabilities. | Ensure that input values are within specified ranges to prevent security issues related to data overflow or underflow. |
| 1.13 | Validate data length | Limit the length of input to prevent buffer overflows and other length-based attacks. | Restrict the length of input data to mitigate security risks associated with buffer overflows and other length-based vulnerabilities. |
| 1.14 | Validate all input against a “white” list | Whenever possible, validate input against a whitelist of allowed characters to restrict the range of acceptable input and prevent malicious code injection. | Ensure that input is validated against a predefined whitelist of permissible characters to minimize security risks. |
| 1.15 | Handle hazardous characters < > ” ‘ % ( ) & + \ ‘ “ | If potentially hazardous characters must be allowed as input, implement additional controls like output encoding and secure APIs. | If your application requires the use of hazardous characters, apply additional security measures like output encoding and secure APIs to mitigate potential risks. |
| 1.16 | Check specific inputs | If standard validation fails, check for specific problematic characters, including null bytes (%00), new line characters (%0d, %0a, \r, \n), path alteration characters (../ or ..), and alternate representations of hazardous characters. | If standard validation doesn’t catch certain inputs, inspect for problematic characters like null bytes, new line characters, path alteration sequences, or alternate encodings of hazardous characters. |
nn
2. Output Encoding
n
The “output encoding” section in your Secure Coding Practices checklist focuses on ensuring that data leaving your application is secure and properly formatted. It involves practices such as conducting encoding on trusted systems, utilizing established encoding routines, and contextually encoding or sanitizing data before returning it to clients. This helps prevent security vulnerabilities by ensuring that all data is presented in a safe and well-structured manner, especially when it originated from untrusted sources. Proper output encoding safeguards against issues like cross-site scripting (XSS) and injection attacks by ensuring that data is correctly processed for the intended interpreter and presentation medium.
n
n
| No | Test Case | Scenario | Example |
|---|---|---|---|
| 2.1 | Conduct all encoding on a trusted system | Ensure that all encoding of output data is performed on the server, not on the client side, to prevent tampering and security vulnerabilities. | When generating HTML for a web page, the server should encode special characters to prevent cross-site scripting (XSS) vulnerabilities. |
| 2.2 | Utilize a standard, tested routine for each type of outbound encoding | Employ well-tested and standardized encoding routines for different data types, such as HTML entity encoding, to ensure consistent and secure encoding. | Use a trusted library or built-in functions for encoding data, such as HTML entity encoding for web content. |
| 2.3 | Contextually output encode all data returned to the client | Apply output encoding to all data that originates outside the application’s trust boundary and is returned to the client. Use appropriate encoding based on the context. | When displaying user-generated content on a web page, use HTML entity encoding to prevent HTML injection. |
| 2.4 | Encode all characters unless they are known to be safe | Encode all characters in output data unless they are explicitly known to be safe for the intended interpreter to prevent malicious code injection or data manipulation. | Encode special characters like “<" and ">” in user-generated content to prevent XSS attacks. |
| 2.5 | Contextually sanitize output of untrusted data to queries | Sanitize all output of untrusted data to prevent injection attacks in queries for SQL, XML, and LDAP. Apply contextual sanitation based on the query type. | When constructing an SQL query from user input, sanitize the input to prevent SQL injection, ensuring that the user input doesn’t contain harmful SQL commands. |
| 2.6 | Sanitize output of untrusted data to operating system commands | Sanitize all output of untrusted data before incorporating it into operating system commands to prevent malicious code execution or system compromise. | When executing shell commands with user input, sanitize the input to ensure that it doesn’t contain harmful commands that could compromise the system. |
nn
3. Authentication and Password Management
n
“Authentication and Password Management” focuses on ensuring secure access to your application. It includes practices like requiring authentication for most resources, using standard authentication services, securely storing and handling passwords, enforcing password complexity and reset policies, and monitoring for suspicious activities. The goal is to protect user accounts, data, and sensitive functions by implementing strong authentication and password management practices, ultimately safeguarding against unauthorized access and security breaches.
n
n
| No | Test Case | Scenario | Example |
|---|---|---|---|
| 3.1 | Require authentication for all pages and resources | Ensure that authentication is required for all pages and resources, except those specifically intended to be public. | All users accessing the application should be required to authenticate themselves, except for publicly accessible information like a homepage. |
| 3.2 | Enforce all authentication controls on a trusted system | Implement all authentication controls on the server, not on the client side, to prevent tampering with authentication logic. | Authentication checks should be performed on the server to ensure the security of the process. |
| 3.3 | Establish and use standard, tested authentication services | Utilize established and tested authentication services whenever possible, such as Google Sign-In or OAuth, to simplify secure authentication. | Implementing authentication through widely recognized and tested services like Google Sign-In enhances security and user experience. |
| 3.4 | Use a centralized implementation for all authentication controls | Implement a centralized authentication mechanism for all authentication-related processes, providing a single point of control for managing user credentials and access permissions. | Authentication should be handled through a centralized system that manages user credentials and permissions. |
| 3.5 | Segregate authentication logic from requested resources | Separate authentication logic from the resource being requested and use redirection to and from the centralized authentication control to ensure security. | Authentication processes should not be mixed with resource processing, and redirection to a centralized authentication control should be used. |
| 3.6 | Ensure secure failure of authentication controls | Authentication controls should fail securely, with responses not revealing which part of the authentication data was incorrect. | If authentication fails, the system should provide a generic message like “Invalid username and/or password” without indicating which part of the authentication data was incorrect. |
| 3.7 | Secure administrative and account management functions | Apply the same level of security controls to administrative and account management functions as to the primary authentication mechanism to ensure consistent security. | Administrative actions and account management should have the same level of security as user authentication. |
| 3.8 | Secure storage of password hashes | If the application manages a credential store, ensure that only cryptographically strong one-way salted hashes of passwords are stored. The table/file storing the passwords and keys should be writable only by the application. | Passwords should be stored securely using strong hashing algorithms, and access to the storage should be tightly controlled. |
| 3.9 | Implement password hashing on a trusted system | Perform password hashing on the server, not on the client side, to protect the hashing algorithm and salt values from exposure. | Password hashing should occur on the server to maintain the security of the hashing process. |
| 3.10 | Validate authentication data after all data input | Validate the authentication data only after all data input is complete, especially for sequential authentication implementations. | In a multi-step authentication process, data should be validated only after all steps are completed. |
| 3.11 | Secure authentication failure responses | Authentication failure responses should not indicate which part of the authentication data was incorrect. | Error responses in case of authentication failure should provide the same message, such as “Invalid username and/or password,” without specifying the exact error. |
| 3.12 | Use authentication for connections to external systems | Utilize authentication for connections to external systems involving sensitive information or functions. | When accessing external systems with sensitive data, ensure that authentication is required to establish secure connections. |
| 3.13 | Encrypt and store external authentication credentials | Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location on a trusted system, not in the source code. | External service credentials should be securely stored and not kept in the application’s source code. |
| 3.14 | Use only HTTP POST requests for authentication credentials | Transmit authentication credentials using only HTTP POST requests to prevent exposure in URL parameters, which can be easily intercepted. | User credentials should be sent using HTTP POST requests to avoid exposing them in URLs. |
| 3.15 | Send non-temporary passwords over encrypted connections | Only send non-temporary passwords over encrypted connections or as encrypted data to protect them from interception. | Non-temporary passwords should be transmitted securely to prevent eavesdropping. |
| 3.16 | Enforce password complexity requirements | Enforce password complexity requirements based on policy or regulations to enhance password security. | Passwords should meet complexity requirements, such as including alphabetic, numeric, and special characters. |
| 3.17 | Enforce password length requirements | Enforce password length requirements based on policy or regulations to ensure stronger passwords. | Passwords should meet length requirements, which may include a minimum length of eight characters or more. |
| 3.18 | Obscure password entry on the user’s screen | Password entry should be obscured on the user’s screen, using input type “password” on web forms. | When users enter passwords, the input should be masked to prevent visual observation. |
| 3.19 | Enforce account disabling after invalid login attempts | Implement account disabling after a set number of invalid login attempts to deter brute force attacks. | After a specified number of failed login attempts, user accounts should be temporarily disabled. |
| 3.20 | Secure password reset and change operations | Password reset and change operations should have the same level of security controls as account creation and authentication. | The processes for resetting and changing passwords should be as secure as initial account creation and authentication. |
| 3.21 | Use random security questions | Password reset questions should support sufficiently random answers to enhance security. | Instead of using easily guessable questions like “favorite book,” use questions that have less predictable answers. |
| 3.22 | Send reset information to pre-registered email addresses | If using email-based resets, only send email to pre-registered addresses with a temporary link or password. | When resetting passwords via email, send reset information only to email addresses that are pre-registered by the user. |
| 3.23 | Set short expiration times for temporary passwords | Temporary passwords and links should have a short expiration time to reduce the risk of unauthorized access if they are compromised. | Temporary passwords should only be valid for a short period, such as 24 hours. |
| 3.24 | Enforce changing of temporary passwords on first use | Require users to change temporary passwords immediately upon first use to prevent prolonged use of insecure temporary passwords. | Users should be prompted to change temporary passwords the first time they log in. |
| 3.25 | Notify users of password resets | Inform users when a password reset occurs to alert them of potential unauthorized access. | Users should receive notifications when their passwords are reset to keep them informed about security events. |
| 3.26 | Prevent password re-use | Implement mechanisms to discourage users from reusing old passwords to promote stronger and unique passwords. | Users should be prevented from using their old passwords when creating new ones. |
| 3.27 | Enforce a waiting period for password changes | Implement a delay between password creation and the first password change to prevent attackers from immediately changing the password. | Users should not be allowed to change their password immediately after creating it. |
| 3.28 | Enforce periodic password changes | Implement a policy requiring periodic password changes, with the time between resets being administratively controlled. | Passwords should be changed at regular intervals as specified by the policy. |
| 3.29 | Disable “remember me” functionality for password fields | Disable the “remember me” option for password fields, especially on public or shared devices to enhance security. | Users should not be given the option to have their password remembered on public or shared devices. |
| 3.30 | Report last account activity to users | Notify users of the last successful or unsuccessful login attempt to keep them informed about account activity. | Users should be aware of the last login attempts to detect any suspicious activity. |
| 3.31 | Implement monitoring for multi-account attacks | Monitor and identify attacks against multiple user accounts using the same password, a common pattern used to bypass standard lockouts. | The system should detect and prevent attacks where multiple accounts are targeted using the same password. |
| 3.32 | Change default passwords and user IDs | Change all vendor-supplied default passwords and user IDs or disable the associated accounts to prevent unauthorized access. | Vendor-supplied default credentials should be replaced or disabled to prevent unauthorized access. |
| 3.33 | Re-authenticate users before critical operations | Require users to re-authenticate before performing critical operations, adding an extra layer of security for sensitive actions. | Users should re-enter their credentials before performing critical operations like changing account settings. |
| 3.34 | Implement Multi-Factor Authentication for sensitive accounts | Use Multi-Factor Authentication (MFA) for highly sensitive or high-value transactional accounts to add an additional layer of security. | For highly sensitive accounts, require MFA to verify the user’s identity. |
| 3.35 | Inspect third-party authentication code | If using third-party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code. | When using third-party authentication code, thoroughly review it to check for vulnerabilities or malicious code. |
nn
4. Session Management
n
“Session Management” is all about ensuring secure and well-controlled user sessions within your application. It involves practices like using trusted session management controls, setting appropriate timeout periods, disallowing concurrent logins, and protecting session data from unauthorized access. The primary goal is to safeguard user sessions from common threats like session hijacking or Cross-Site Request Forgery (CSRF) by implementing robust session management practices. These practices help maintain the integrity and security of user sessions while allowing for smooth and secure interactions with your application.
n
n
| No | Test Case | Scenario | Example |
|---|---|---|---|
| 4.1 | Use Server or Framework Session Management | Utilize the built-in session management provided by your web server or framework. This ensures that your application recognizes and uses valid session identifiers. | If you’re using a web framework like Express.js in Node.js, use its session management features. |
| 4.2 | Create Session Identifiers on a Trusted System | Generate session identifiers (like cookies) on the server to prevent tampering. | When a user logs in, the server generates a unique session ID and sends it to the user’s browser. |
| 4.3 | Use Secure Session Algorithms | Choose strong, secure algorithms for generating session identifiers. They should be random and unpredictable. | Instead of using a simple incremental number, use a cryptographically secure random string as the session identifier. |
| 4.4 | Set Domain and Path for Cookies | Limit where cookies with session IDs can be used by setting their domain and path. | If your site is “example.com,” restrict the cookie’s domain to “.example.com” to prevent it from being used on other subdomains. |
| 4.5 | Properly Terminate Sessions on Logout | Ensure that the logout function fully terminates the user’s session or connection. | When a user clicks “Logout,” their session is invalidated, and they are redirected to the login page. |
| 4.6 | Accessible Logout | Provide a logout option on all pages protected by authorization, so users can easily log out. | Include a “Logout” link in the navigation menu on every page. |
| 4.7 | Session Timeout | Set a short session inactivity timeout, usually a few hours, to balance security and user convenience. | Automatically log the user out after 15 minutes of inactivity. |
| 4.8 | Avoid Persistent Logins | Do not allow users to stay logged in indefinitely. Log them out periodically, even during an active session. | Prompt the user to re-enter their password after a set time, even if they are actively using the app. |
| 4.9 | Close Old Session on Login | If a user had a session before login, close that session and create a new one after successful login. | When a user logs in, their previous session becomes invalid. |
| 4.10 | Generate New Session Identifier on Re-authentication | Whenever a user re-authenticates (e.g., changing their password), generate a new session identifier. | When a user updates their password, their session ID changes. |
| 4.11 | No Concurrent Logins with the Same User ID | Prevent multiple simultaneous logins with the same user ID. | If a user is already logged in and tries to log in again from a different device, the previous session is invalidated. |
| 4.12 | Hide Session Identifiers | Do not expose session identifiers in URLs, error messages, or logs. Store them securely in the HTTP cookie header. | Avoid displaying session IDs in the URL like “example.com?session=12345.” |
| 4.13 | Protect Server-Side Session Data | Implement access controls on the server to prevent unauthorized access to session data by other users or processes on the server. | Only authorized server-side code can access and modify session data. |
| 4.14 | Rotate Session Identifiers | Periodically generate new session identifiers and deactivate the old ones. This prevents session hijacking if the original identifier was compromised. | Every hour, generate a new session ID and invalidate the previous one. |
| 4.15 | Switch to HTTPS | Change the session identifier if the connection security switches from HTTP to HTTPS. Maintain HTTPS consistently within your application. | If a user logs in via an insecure HTTP connection, generate a new session ID when they switch to a secure HTTPS connection. |
| 4.16 | Use Strong Tokens for Sensitive Operations | For sensitive server-side actions (e.g., account management), use strong random tokens or parameters to prevent Cross-Site Request Forgery (CSRF) attacks. | When a user requests to change their password, generate a unique token to ensure the request is legitimate. |
| 4.17 | Use Strong Tokens for Critical Operations | For highly sensitive or critical operations, use per-request, rather than per-session, strong random tokens or parameters. | When processing a financial transaction, generate a unique token for each step of the transaction. |
| 4.18 | Set “Secure” Attribute for Cookies | Mark cookies as “secure” when transmitted over a TLS (HTTPS) connection to prevent interception. | Ensure that cookies carrying session information are marked as “secure” to be transmitted only over secure HTTPS connections. |
| 4.19 | Use HttpOnly for Cookies | Set cookies with the HttpOnly attribute unless you specifically need client-side scripts to read or set a cookie’s value. | Use HttpOnly to prevent client-side scripts from accessing cookies containing sensitive session information. |
nn
5. Access Control
n
“Access Control” is about ensuring that only authorized users can access specific parts of your application. This section includes practices such as using trusted system objects for authorization decisions, enforcing access controls on every request, segregating privileged logic, and restricting access to files, resources, URLs, functions, and data. The primary goal is to prevent unauthorized access to sensitive areas of your application and data by implementing strong access control practices. These practices help protect your application from security threats, ensuring that users can only access what they are allowed to and that sensitive information remains secure.
n
n
| No | Test Case | Scenario | Example |
|---|---|---|---|
| 5.1 | Use only trusted system objects for access authorization | Use only trusted system objects, such as server-side session objects, for making access authorization decisions. | Access authorization decisions should be based on information from trusted sources within the application. |
| 5.2 | Implement a single site-wide comp |
