diff --git a/.wordlist-en.txt b/.wordlist-en.txt index a1df4599..7743e35d 100644 --- a/.wordlist-en.txt +++ b/.wordlist-en.txt @@ -115,7 +115,9 @@ InlineHilite Istio JA JDK +JEA JIRA +JIT JSON JSONP JSP diff --git a/docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md b/docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md deleted file mode 100644 index 1ed1f4ef..00000000 --- a/docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md +++ /dev/null @@ -1,81 +0,0 @@ -A security requirement is a statement of security functionality that ensures software security is being satisfied. -Security requirements are derived from industry standards, applicable laws, and a history of past vulnerabilities. - -Refer to proactive control [C4: Address Security form the Start][control4] and its [cheatsheets][csproactive-c1] -for more context from the OWASP Top 10 Proactive Controls project, -and use the lists below as suggestions for a checklist that has been tailored for the individual project. - -#### 1. System configuration - -1. Restrict applications, processes and service accounts to the least privileges possible -2. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible -3. Remove all unnecessary functionality and files -4. Remove test code or any functionality not intended for production, prior to deployment -5. The security configuration store for the application should be available in human readable form to support auditing -6. Isolate development environments from production and provide access only to authorized development and test groups -7. Implement a software change control system to manage and record changes to the code both in development and production -8. Turn off directory listings -9. Prevent accidentally accessible and sensitive pages from appearing in search engines using a robots.txt file, - the X-Robots-Tag response header or a robots html meta tag -10. Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is - required, utilize a well-vetted authentication mechanism -11. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application - frameworks unless implemented to confuse an attacker -12. Ensure the .git, .svn folders or any source control metadata aren't deployed together alongside the application in away - that makes these directly accessible externally or indirectly through the application -13. Do not store passwords, secrets, connection strings, key material, secret management integrations or other sensitive - information in clear text or in any non-cryptographically secure manner on the client, in source code, or build artifacts -14. Remove or restrict access to internal application and system documentation (such as for internal APIs) as this can reveal - backend system or other useful information to attackers -15. Restrict access to files or other resources, including those outside the application's direct control using an allow list - or the equivalent thereof. - -#### 2. Cryptographic practices - -1. Use peer reviewed and open solution cryptographic modules -2. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system -3. Cryptographic modules must fail securely -4. Ensure all random elements such as numbers, file names, UUID and strings are generated - using the cryptographic module approved random number generator -5. Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard -6. Establish and utilize a policy and process for how cryptographic keys will be managed -7. Ensure that any secret key is protected from unauthorized access -8. Store keys in a proper secrets vault as described below -9. Use independent keys when multiple keys are required -10. Build support for changing algorithms and keys when needed -11. Build application features to handle a key rotation - -#### 3. File management - -1. Do not pass user supplied data directly to any dynamic include function -2. Require authentication before allowing a file to be uploaded -3. Limit the type of files that can be uploaded to only those types that are needed for business purposes -4. Validate uploaded files are the expected type by checking file headers rather than by file extension -5. Do not save files in the same web context as the application -6. Prevent or restrict the uploading of any file that may be interpreted by the web server. -7. Turn off execution privileges on file upload directories -8. When referencing existing files, use an allow-list of allowed file names and types -9. Do not pass user supplied data into a dynamic redirect -10. Do not pass directory or file paths, use index values mapped to pre-defined list of paths -11. Never send the absolute file path to the client -12. Ensure application files and resources are read-only -13. Scan user uploaded files for viruses and malware - -#### References - -* OWASP [Application Security Verification Standard][asvs] (ASVS) -* OWASP [Mobile Application Security][mas] -* OWASP [Top 10 Proactive Controls][proactive10] - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue060201] or [edit on GitHub][edit060201]. - -[asvs]: https://owasp.org/www-project-application-security-verification-standard/ -[csproactive-c1]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c1-define-security-requirements -[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/ -[edit060201]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md -[issue060201]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/01-define-security-requirements -[mas]: https://mas.owasp.org/ -[proactive10]: https://top10proactive.owasp.org/ diff --git a/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md b/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md new file mode 100644 index 00000000..892babc2 --- /dev/null +++ b/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md @@ -0,0 +1,60 @@ +“Secure-by-Default” means products are resilient against prevalent exploitation techniques out of the box +without additional charge. Software should start in a secure state without requiring extensive user configuration, +ensuring the default settings are always the most secure option. + +Refer to proactive control [C5: Secure By Default Configurations][control5] and the +[Infrastructure as Code Security Cheatsheet][csproactive-c5] +for more context from the OWASP Top 10 Proactive Controls project, +and use the lists below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. System configuration + +1. Restrict applications, processes and service accounts to the least privileges possible +2. Code which defines the infrastructure should follow the principle of least privilege. +3. Remove all unnecessary functionality such as files, accounts, software, and demo capabilities +4. Remove test code or any functionality not intended for production, prior to deployment +5. The security configuration store for the application should be available in human readable form to support auditing +6. Isolate development environments from production and provide access only to authorized development and test groups +7. Implement a software change control system to manage and record changes to the code both in development and production +8. Prevent accidentally accessible and sensitive pages from appearing in search engines using a robots.txt file, +the + X-Robots-Tag response header or a robots html meta tag +9. Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is + required, utilize a well-vetted authentication mechanism +10. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application + frameworks unless implemented to confuse an attacker +11. Ensure the .git, .svn folders or any source control metadata aren't deployed together alongside the application in + away that makes these directly accessible externally or indirectly through the application +12. Do not store passwords, secrets, connection strings, key material, secret management integrations or other + sensitive information in clear text or in any non-cryptographically secure manner on the client, in source code, or build + artifacts +13. Remove or restrict access to internal application and system documentation (such as for internal APIs) as this can + reveal backend system or other useful information to attackers + +#### 2. File Management + +1. Turn off directory listings +2. Do not save files in the same web context as the application +3. Turn off execution privileges on file upload directories +4. Ensure application files and resources are read-only +5. Restrict access to files or other resources, including those outside the application's direct control using an allow list + or the equivalent thereof. + +#### 3. Cloud security + +1. Enforce JIT (Just-In-Time) access management +2. Use security vetted container images that is scanned for package and component vulnerabilities and pulled from a private + container registry +3. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on- + premises infrastructure +4. Utilize Policy-as-Code to enforce policies including privilege assignments + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060201] or [edit on GitHub][edit060201]. + +[control5]: https://top10proactive.owasp.org/the-top-10/c5-secure-by-default/ +[csproactive-c5]: https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html +[edit060201]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md +[issue060201]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/01-secure-by-default diff --git a/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md b/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md index 6addfdd6..845f3dee 100644 --- a/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md +++ b/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md @@ -1,7 +1,7 @@ Secure coding libraries and software frameworks with embedded security help software developers guard against security-related design and implementation flaws. -Refer to proactive control [C4: Address Security from the Start][control4] +Refer to proactive control [C6: Keep your Components Secure][control6] and its [cheatsheets][csproactive-c2] for more context from the OWASP Top 10 Proactive Controls project. For technology specific checklists refer to the appropriate OWASP Cheat Sheets: @@ -39,16 +39,18 @@ In addition consider the following extra checks for frameworks and libraries. 2. Use libraries and frameworks from trusted sources that are actively maintained and widely used 3. Review all secondary applications and third party libraries to determine business necessity 4. Validate safe functionality for all secondary applications and third party libraries -5. Create and maintain an inventory catalog of all third party libraries using Software Composition Analysis (SCA) +5. Create and maintain an inventory catalog of all third party libraries. It is recommended to automatically create + SBOMs (Software-Bill-Of-Materials) from within the build pipeline. 6. Proactively keep all third party libraries and components up to date 7. Reduce the attack surface by encapsulating the library and expose only the required behavior into your software 8. Use tested and approved managed code rather than creating new unmanaged code for common tasks 9. Utilize task specific built-in APIs to conduct operating system tasks -10. Do not allow the application to issue commands directly to the Operating System -11. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files -12. Restrict users from generating new code or altering existing code -13. Implement safe updates using encrypted channels -14. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures +10. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files +11. Restrict users from generating new code or altering existing code +12. Implement safe updates using encrypted channels +13. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures +14. Use your SBOMs together with periodic or SCA tools to automatically detect well-known publicly disclosed vulnerabilities. +15. integrate SCA tools in early stages of software development #### References @@ -84,7 +86,7 @@ then [submit an issue][issue060202] or [edit on GitHub][edit060202]. [cswebservice]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet [csxml]: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet [csproactive-c2]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c2-leverage-security-frameworks-and-libraries -[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/ +[control6]: https://top10proactive.owasp.org/the-top-10/c6-use-secure-dependencies/ [dependency]: https://owasp.org/www-project-dependency-check/ [edit060202]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md [issue060202]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/02-frameworks-libraries diff --git a/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md b/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md index b049087b..74e560e3 100644 --- a/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md +++ b/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md @@ -5,7 +5,9 @@ The target system may be another software component or it may be reflected back such as operating system commands, so encoding and escaping output data helps to provide defense in depth for the system as a whole. -Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3] and its [cheatsheets][csproactive-c4] +Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3] and its [cheatsheets][csproactive-c4] and +[C10: Stop Server Side Request Forgery][control10] together with +[Server-Side Request Forgery Prevention Cheat Sheet][csproactive-c10] for more context from the OWASP Top 10 Proactive Controls project, and use the list below as suggestions for a checklist that has been tailored for the individual project. @@ -15,7 +17,7 @@ and use the list below as suggestions for a checklist that has been tailored for 2. Conduct all output encoding on a trusted system 3. Utilize a standard, tested routine for each type of outbound encoding 4. Specify character sets, such as UTF-8, for all outputs -5. Apply canonicalization to convert unicode data into a standard form +5. Apply canonicalization to convert unicode data into a standard form and address obfuscation attacks 6. Ensure the output encoding is safe for all target systems 7. In particular sanitize all output used for operating system commands 8. Sanitize potentially dangerous characters before using the data to call another service @@ -40,7 +42,9 @@ The OWASP Developer Guide is a community effort; if there is something that need then [submit an issue][issue060204] or [edit on GitHub][edit060204]. [csproactive-c4]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c4-encode-and-escape-data +[csproactive-c10]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html [control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[control10]: https://top10proactive.owasp.org/the-top-10/c10-stop-server-side-request-forgery/ [edit060204]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md [encoder]: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project [ipcs]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet diff --git a/docs/en/04-design/02-web-app-checklist/05-validate-inputs.md b/docs/en/04-design/02-web-app-checklist/05-validate-inputs.md index 7fc7032f..4535a569 100644 --- a/docs/en/04-design/02-web-app-checklist/05-validate-inputs.md +++ b/docs/en/04-design/02-web-app-checklist/05-validate-inputs.md @@ -18,9 +18,8 @@ and use the list below as suggestions for a checklist that has been tailored for 6. Verify that protocol header values in both requests and responses contain only ASCII characters 7. Validate data from redirects 8. Validate data range and also data length -9. Utilize canonicalization to address obfuscation attacks -10. All validation failures should result in input rejection -11. Validate all input against an allowlist of characters, whenever possible +9. All validation failures should result in input rejection +10. Validate all input against an allowlist of characters, whenever possible #### 2. Libraries and frameworks @@ -29,6 +28,7 @@ and use the list below as suggestions for a checklist that has been tailored for 3. If the standard validation routine cannot address some inputs then use extra discrete checks 4. If any potentially hazardous input _must_ be allowed then implement additional controls 5. Validate for expected data types using an allow-list rather than a deny-list +6. Do not allow the application to issue commands directly to the Operating System #### 3. Validate serialized data @@ -41,6 +41,18 @@ and use the list below as suggestions for a checklist that has been tailored for 5. Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize 6. Monitor deserialization, for example alerting if a user agent constantly deserializes +#### 4. File validation + +1. Do not pass user supplied data directly to any dynamic include function +2. Limit the type of files that can be uploaded to only those types that are needed for business purposes +3. Validate uploaded files are the expected type by checking file headers rather than by file extension +4. Prevent or restrict the uploading of any file that may be interpreted by the web server. +5. When referencing existing files, use an allow-list of allowed file names and types +6. Do not pass user supplied data into a dynamic redirect +7. Do not pass directory or file paths, use index values mapped to pre-defined list of paths +8. Never send the absolute file path to the client +9. Scan user uploaded files for viruses and malware + #### References * OWASP [Cheat Sheet: Input Validation][ivcs] diff --git a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md index 97c390d4..8546522d 100644 --- a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md @@ -2,14 +2,14 @@ Session management is a process by which a server maintains the state of the users authentication so that the user may continue to use the system without re-authenticating. -Refer to proactive control [C7: Implement Digital Identity][control7] and its [cheatsheets][csproactive-c6] +Refer to proactive control [C7: Secure Digital Identities][control7] and its [cheatsheets][csproactive-c6] for more context from the OWASP Top 10 Proactive Controls project, and use the list below as suggestions for a checklist that has been tailored for the individual project. #### 1. Authentication -1. Design access control authentication thoroughly up-front -2. Require authentication for all pages and resources, except those specifically intended to be public +1. Require authentication for all pages and resources, except those specifically intended to be public +2. Require authentication before allowing a file to be uploaded 3. All authentication controls must be enforced on a trusted system 4. All authentication controls should fail securely 5. Establish and utilize standard, tested, authentication services whenever possible @@ -26,15 +26,14 @@ and use the list below as suggestions for a checklist that has been tailored for 14. Authentication credentials for accessing services external to the application should be stored in a secure store 15. Use only HTTP POST requests to transmit authentication credentials 16. Force all requests to go through access control checks unless public -17. Do not hard code access controls that are role based -18. Log all access control events -19. Validate the authentication data only on completion of all data input -20. Authentication failure responses should not indicate which part of the authentication data was incorrect. +17. Log all access control events +18. Validate the authentication data only on completion of all data input +19. Authentication failure responses should not indicate which part of the authentication data was incorrect. E.g. Through giving different textual response or HTTP response codes -21. Authentication failure responses should not give away the existent of user accounts by allowing the response time to +20. Authentication failure responses should not give away the existent of user accounts by allowing the response time to differ, depending on whether a username exist or not. Use a DB transaction that looks for a fake user profile in case the username doesn't exist -22. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks +21. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks #### 2. Passwords @@ -82,11 +81,15 @@ and use the list below as suggestions for a checklist that has been tailored for 17. Set cookies with the `HttpOnly` attribute, unless you specifically require client-side scripts within your application to read or set a cookie value -#### 4. Session Management +#### 4. Session Generation and Expiration -1. All active sessions must be terminated when a user account is disabled or deleted -2. After a successful change or removal of any authentication factor give the option to terminate all other active sessions -3. Supplement standard session management for sensitive server-side operations, like account management, by requiring and +1. Ensure that the session id is long, unique and random, i.e., is of high entropy +2. Generate a new session during authentication and re-authentication +3. All active sessions must be terminated when a user account is disabled or deleted +4. After a successful change or removal of any authentication factor give the option to terminate all other active sessions +5. Implement an idle timeout after a period of inactivity and an absolute maximum lifetime for each session, after + which users must re-authenticate +6. Supplement standard session management for sensitive server-side operations, like account management, by requiring and validating anti-forgery tokens (CSRF tokens) for each request that may change application state or execute an action #### References diff --git a/docs/en/04-design/02-web-app-checklist/07-access-controls.md b/docs/en/04-design/02-web-app-checklist/07-access-controls.md index 6348f6fc..dd2f0e07 100644 --- a/docs/en/04-design/02-web-app-checklist/07-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/07-access-controls.md @@ -5,7 +5,7 @@ Refer to proactive control [C1: Implement Access Controls][control1] and its [ch for more context from the OWASP Top 10 Proactive Controls project, and use the list below as suggestions for a checklist that has been tailored for the individual project. -#### 1. Authorization +#### 1. Implement Access Control 1. Design access control / authorization thoroughly up-front 2. Force all requests to go through access control checks unless public @@ -17,31 +17,35 @@ and use the list below as suggestions for a checklist that has been tailored for function-level, data-specific, and field-level access based on consumer permissions and resource attributes 7. Access Control criteria and/or processes not testable through automated tests should be documented so that they can be manually tested +8. Use only trusted system objects for making access authorization decisions +9. Use a single site-wide component to check authorization +10. Access control should fail securely +11. Deny all access if the application cannot access its security configuration information +12. Segregate privileged logic from other application code +13. Do not hard code access controls that are role based +14. Enforce application logic flows to comply with business rules +15. Server side implementation and presentation layer representations of access control rules should not differ in such a way + that they allow for business functionality and rules to be compromised -#### 2. Access control +#### 2. Access control Management -1. Enforce authorization controls on every request -2. Use only trusted system objects for making access authorization decisions -3. Use a single site-wide component to check access authorization -4. Access controls should fail securely -5. Deny all access if the application cannot access its security configuration information -6. Segregate privileged logic from other application code -7. Limit the number of transactions a single user or device can perform in a given period of time, +1. Limit the number of transactions a single user or device can perform in a given period of time, low enough to deter automated attacks but above the actual business requirement -8. If long authenticated sessions are allowed, periodically re-validate a user's authorization -9. Implement account auditing and enforce the disabling of unused accounts -10. The application must support termination of sessions when authorization ceases -11. Restrict function-level access to consumers with explicit permissions -12. Restrict direct object references to only authorized users with explicit permissions to specific data items +2. If long authenticated sessions are allowed, periodically re-validate a user's authorization +3. Implement account auditing and enforce the disabling of unused accounts +4. A new account should have minimal or no access by default +5. For highly sensitive accounts implement Just in Time (JIT), Just Enough Access (JEA) management and avoid the use + of admin accounts with global access +6. The application must support termination of sessions when authorization ceases +7. Restrict function-level access to consumers with explicit permissions +8. Restrict direct object references to only authorized users with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA) -13. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken +9. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA) -14. Restrict access security-relevant configuration information to only authorized users who have been allowed access through +10. Restrict access security-relevant configuration information to only authorized users who have been allowed access through multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis -15. Server side implementation and presentation layer representations of access control rules should not differ in such a way - that they allow for business functionality and rules to be compromised -16. Enforce application logic flows to comply with business rules +11. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible #### References diff --git a/docs/en/04-design/02-web-app-checklist/08-protect-data.md b/docs/en/04-design/02-web-app-checklist/08-protect-data.md index 9f47130b..0ecd71cf 100644 --- a/docs/en/04-design/02-web-app-checklist/08-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/08-protect-data.md @@ -2,30 +2,44 @@ Sensitive data such as passwords, credit card numbers, health records, personal require extra protection, particularly if that data falls under privacy laws (EU General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations. -Refer to proactive control [C2: Use Cryptography the proper way][control2] and its [cheatsheets][csproactive-c8] +Refer to proactive control [C2: Use Cryptography to Protect Data][control2] and its [cheatsheets][csproactive-c8] for more context from the OWASP Top 10 Proactive Controls project, and use the list below as suggestions for a checklist that has been tailored for the individual project. -#### 1. Data protection +#### 1. Cryptographic practices + +1. Use peer reviewed and open solution cryptographic modules +2. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system +3. Cryptographic modules must fail securely +4. Ensure all random elements such as numbers, file names, UUID and strings are generated + using the cryptographic module approved secure random number generator +5. Build support for changing algorithms when needed +6. Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard +7. Don't implement your own cryptographic protocols or routines. Use existing security vetted library and frameworks + +#### 2. Data protection 1. Classify data according to the level of sensitivity 2. Implement appropriate access controls for sensitive data -3. Encrypt data in transit -4. Ensure secure communication channels are properly configured -5. Avoid storing sensitive data when at all possible -6. Ensure sensitive data at rest is cryptographically protected to avoid unauthorized disclosure and modification -7. Purge sensitive data when that data is no longer required -8. Store application-level secrets in a secrets vault -9. Check that secrets are not stored in code, config files or environment variables -10. Implement least privilege, restricting access to functionality, data and system information -11. Protect all cached or temporary copies of sensitive data from unauthorized access -12. Purge those temporary copies of sensitive data as soon as they are no longer required -13. Do not include sensitive information in the URL or query string, such as an API key or session token -14. Disable client side caching on pages containing sensitive information (e.g. Cache-Control: no-store) -15. Set a referrer policy to prevent leakage of sensitive data to third-party services via the 'Referer' HTTP request header +3. Avoid storing sensitive data when at all possible +4. Implement least privilege, restricting access to functionality, data and system information +5. Do not include sensitive information in the URL or query string, such as an API key or session token +6. Disable client side caching on pages containing sensitive information (e.g. Cache-Control: no-store) +7. Set a referrer policy to prevent leakage of sensitive data to third-party services via the 'Referer' HTTP request header field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes -#### 2. Memory management +#### 3. Secret Management + +1. Establish and utilize a policy and process for how cryptographic keys will be managed +2. Ensure that any secret key is protected from unauthorized access +3. Store keys and application-level secrets in a proper secrets vault +4. Use independent keys when multiple keys are required +5. Build application features to handle a secret key rotation +6. Ensure that secrets are not stored in code, config files or environment variables +7. Scan code repositories to detect accidentally added secrets and credentials +8. Log all authorized access to a secret key for forensic purposes + +#### 4. Memory management 1. Explicitly initialize all variables and data stores 2. Check that any buffers are as large as specified @@ -37,13 +51,27 @@ and use the list below as suggestions for a checklist that has been tailored for 8. Protect shared variables and resources from inappropriate concurrent access 9. Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.) -#### 3. Encrypting Data in Transit +#### 5. Protect Data at Rest + +1. Ensure sensitive data at rest is cryptographically protected to avoid unauthorized disclosure and modification +2. Purge sensitive data when that data is no longer required +3. Protect all cached or temporary copies of sensitive data from unauthorized access +4. Purge those temporary copies of sensitive data as soon as they are no longer required + +#### 5. Protect Data in Transit -1. Utilize TLS connections for all connectivity between a client and external-facing, HTTP-based services -2. Ensure the TLS connections do not fall back to insecure or unencrypted communication -3. Utilize a single standard TLS implementation with (preferably the latest) secure version of TLS -4. Ensure the TLS connections are configured appropriately to validate certificates received before communicating and +1. Encrypt data in transit +2. Ensure secure communication channels are properly configured +3. Utilize TLS connections for all connectivity between a client and external-facing, HTTP-based services +4. Ensure the TLS connections do not fall back to insecure or unencrypted communication +5. Turn off older protocols to avoid protocol downgrade attacks +6. Do not offer HTTP. Disable both HTTP and SSL compression +7. Utilize a single standard TLS implementation with (preferably the latest) secure version of TLS +8. Ensure the TLS connections are configured appropriately to validate certificates received before communicating and checking revocation status +9. Use the Strict-Transport-Security Header +10. Use Content-Security-Policy to enforce client-side upgrade from HTTP to HTTPS. +11. Always utilize the “secure” flag for cookies to prevent transmission over HTTP. #### References