From b27130c373263dc7781e2e780f9abefce35d41b3 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Fri, 18 Jul 2025 09:31:15 +0200 Subject: [PATCH 01/16] Fixes #131 Top 10 proactivecontrols (#142) * Update and rename 01-define-security-requirements.md to 04-address-security-from-the-start.md * Update and rename 02-frameworks-libraries.md to 06-keep-your-components-secure.md * Update 06-digital-identity.md * Rename 04-address-security-from-the-start.md to 01-address-security-from-the-start.md * Rename 06-keep-your-components-secure.md to 02-keep-your-components-secure.md * Update 08-protect-data.md * Create 02-secure-by-default-configurations.md * Create 03-secure-by-default-configurations.md * Delete docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md * Update 03-secure-by-default-configurations.md * Move configuration requirements to secure by default configuration * correct linking * Update 02-keep-your-components-secure.md * Rename 03-secure-database-access.md to 04-secure-database-access.md * Rename 04-secure-database-access.md to 06-secure-database-access.md * Rename 06-digital-identity.md to 07-digital-identity.md * Rename 07-access-controls.md to 08-access-controls.md * Rename 08-protect-data.md to 09-protect-data.md * Rename 09-logging-monitoring.md to 10-logging-monitoring.md * Rename 10-handle-errors-exceptions.md to 11-handle-errors-exceptions.md * Add C10 from proactive controls * Update 04-encode-escape-data.md * Remove duplicate bullet point thart belongs to the encoding list * Update 01-address-security-from-the-start.md * Move bullet point from 01-address-security-from-the-start.md * Move bullet point to 08-access-controls.md * Remove bullet point that was meant for the access control list and that has become wrongly added to the authentication list * Update 09-protect-data.md * Add the practice * Move cryptographic practices to data protection * Change headers to conform to Top 10 Proactive Controls * Move data protection at rest bullet points under the appropriate header * Move file validation from address-security-from-the-start * Move authentication related issue to the authentication list. * Move from file management to secure by default * Move from address security from the start * move from secure from the start * No longer of interest as the new chapter now is called secure by default * Rename 03-secure-by-default-configurations.md to 01-secure-by-default-configurations.md * Update and rename 01-secure-by-default-configurations.md to 01-secure-by-default.md * Update and rename 04-encode-escape-data.md to 03-encode-escape-data.md * Rename 06-secure-database-access.md to 03-secure-database-access.md * Update and rename 03-encode-escape-data.md to 04-encode-escape-data.md * Rename 02-keep-your-components-secure.md to 02-frameworks-libraries.md * Add directions for editing * Fix link * Sort and create the file management header under secure by default * create header * Add JIT * Add cloud security * Add point about infra and policy as code. * Add point about infra as code * Add point from proactive controls * Move to validation * Move feom framework and libraryies * Add additional points about scanning for vulnerabilities * Shorten sentence * Move to access control * Move from digital identities * Add point related to session management * Move JIT to secure by default * Add jit * Add requirements for new accounts * Add JIT requirement * Separate the access control list into implementing and management * Add points from proactive controls * Add point about secret management * Add secret management list * Add point about logging * Add point about turning off older protocols * Add point about not serving http * Add point about the use of client side secure transmission features * Rename 07-digital-identity.md to 06-digital-identity.md * Rename 08-access-controls.md to 07-access-controls.md * Rename 09-protect-data.md to 08-protect-data.md * Rename 10-logging-monitoring.md to 09-logging-monitoring.md * Rename 11-handle-errors-exceptions.md to 10-handle-errors-exceptions.md * Fix linting * Fix linting * Fix ordering * Fix linting * Fix ordering * Update 02-frameworks-libraries.md * Fix linting * Fix linting * Fix linting * Fix ordering * Fix linting * Fix linting * Fix prdering * Fix spelling * Add words --- .wordlist-en.txt | 2 + .../01-define-security-requirements.md | 81 ------------------- .../01-secure-by-default.md | 60 ++++++++++++++ .../02-frameworks-libraries.md | 18 +++-- .../04-encode-escape-data.md | 8 +- .../05-validate-inputs.md | 18 ++++- .../06-digital-identity.md | 29 ++++--- .../07-access-controls.md | 42 +++++----- .../02-web-app-checklist/08-protect-data.md | 70 +++++++++++----- 9 files changed, 181 insertions(+), 147 deletions(-) delete mode 100644 docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md create mode 100644 docs/en/04-design/02-web-app-checklist/01-secure-by-default.md 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 From ea04baf6b231b5da11f0ba6a897d0086b580fa97 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Fri, 18 Jul 2025 10:44:53 +0200 Subject: [PATCH 02/16] #131 Fix the missing link (#144) * #131 Update mkdocs-pdf-en.yaml * #131 Update base mkdocs * #131 Update mkdocs-pdf-fa.yaml * #131 Update mkdocs-pdf-pt-br.yaml * #131 Recreate 01-define-security-requirements.md --- .../01-define-security-requirements.md | 81 +++++++++++++++++++ mkdocs-pdf-en.yaml | 2 +- mkdocs-pdf-fa.yaml | 2 +- mkdocs-pdf-pt-br.yaml | 2 +- mkdocs.yaml | 2 +- 5 files changed, 85 insertions(+), 4 deletions(-) create mode 100644 docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md 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 new file mode 100644 index 00000000..1ed1f4ef --- /dev/null +++ b/docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md @@ -0,0 +1,81 @@ +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/mkdocs-pdf-en.yaml b/mkdocs-pdf-en.yaml index 0d562103..bbd43d9e 100644 --- a/mkdocs-pdf-en.yaml +++ b/mkdocs-pdf-en.yaml @@ -62,7 +62,7 @@ nav: - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - - Define Security Requirements: en/04-design/02-web-app-checklist/01-define-security-requirements.md + - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md - Leverage Security Frameworks and Libraries: en/04-design/02-web-app-checklist/02-frameworks-libraries.md - Secure Database Access: en/04-design/02-web-app-checklist/03-secure-database-access.md - Encode and Escape Data: en/04-design/02-web-app-checklist/04-encode-escape-data.md diff --git a/mkdocs-pdf-fa.yaml b/mkdocs-pdf-fa.yaml index d6015482..798f156a 100644 --- a/mkdocs-pdf-fa.yaml +++ b/mkdocs-pdf-fa.yaml @@ -62,7 +62,7 @@ nav: - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - - Define Security Requirements: en/04-design/02-web-app-checklist/01-define-security-requirements.md + - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md - Leverage Security Frameworks and Libraries: en/04-design/02-web-app-checklist/02-frameworks-libraries.md - Secure Database Access: en/04-design/02-web-app-checklist/03-secure-database-access.md - Encode and Escape Data: en/04-design/02-web-app-checklist/04-encode-escape-data.md diff --git a/mkdocs-pdf-pt-br.yaml b/mkdocs-pdf-pt-br.yaml index 8f1fcff8..0ee4e7ed 100644 --- a/mkdocs-pdf-pt-br.yaml +++ b/mkdocs-pdf-pt-br.yaml @@ -65,7 +65,7 @@ nav: - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - - Define Security Requirements: en/04-design/02-web-app-checklist/01-define-security-requirements.md + - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md - Leverage Security Frameworks and Libraries: en/04-design/02-web-app-checklist/02-frameworks-libraries.md - Secure Database Access: en/04-design/02-web-app-checklist/03-secure-database-access.md - Encode and Escape Data: en/04-design/02-web-app-checklist/04-encode-escape-data.md diff --git a/mkdocs.yaml b/mkdocs.yaml index 4ca73534..e26d2097 100644 --- a/mkdocs.yaml +++ b/mkdocs.yaml @@ -77,7 +77,7 @@ nav: - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - - Define Security Requirements: en/04-design/02-web-app-checklist/01-define-security-requirements.md + - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md - Leverage Security Frameworks and Libraries: en/04-design/02-web-app-checklist/02-frameworks-libraries.md - Secure Database Access: en/04-design/02-web-app-checklist/03-secure-database-access.md - Encode and Escape Data: en/04-design/02-web-app-checklist/04-encode-escape-data.md From c18640f682f23fb27007f8f92ef1c6ac7864fffe Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Fri, 1 Aug 2025 06:50:43 +0100 Subject: [PATCH 03/16] update automation actions --- .github/workflows/ci.yaml | 4 ++-- .github/workflows/housekeeping.yaml | 2 +- .github/workflows/pr.yaml | 4 ++-- .github/workflows/release.yaml | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 4a90fca5..f7fe01e2 100644 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -60,12 +60,12 @@ jobs: uses: actions/checkout@v4.2.2 - name: Spell check EN language - uses: rojopolis/spellcheck-github-actions@0.49.0 + uses: rojopolis/spellcheck-github-actions@0.51.0 with: config_path: .spellcheck-en.yaml - name: Spell check ES language - uses: rojopolis/spellcheck-github-actions@0.49.0 + uses: rojopolis/spellcheck-github-actions@0.51.0 with: config_path: .spellcheck-es.yaml diff --git a/.github/workflows/housekeeping.yaml b/.github/workflows/housekeeping.yaml index 94e0d5af..623dcf2c 100644 --- a/.github/workflows/housekeeping.yaml +++ b/.github/workflows/housekeeping.yaml @@ -25,7 +25,7 @@ jobs: keep_minimum_runs: 10 - name: Delete unused workflows - uses: otto-de/purge-deprecated-workflow-runs@v3.0.3 + uses: otto-de/purge-deprecated-workflow-runs@v3.0.4 with: token: ${{ github.token }} diff --git a/.github/workflows/pr.yaml b/.github/workflows/pr.yaml index 13545661..907ee1ff 100644 --- a/.github/workflows/pr.yaml +++ b/.github/workflows/pr.yaml @@ -53,7 +53,7 @@ jobs: uses: actions/checkout@v4.2.2 - name: Spell check EN language - uses: rojopolis/spellcheck-github-actions@0.49.0 + uses: rojopolis/spellcheck-github-actions@0.51.0 with: config_path: .spellcheck-en.yaml @@ -65,7 +65,7 @@ jobs: uses: actions/checkout@v4.2.2 - name: Spell check ES language - uses: rojopolis/spellcheck-github-actions@0.49.0 + uses: rojopolis/spellcheck-github-actions@0.51.0 with: config_path: .spellcheck-es.yaml diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index 85ad2f5f..cd1cee04 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -59,7 +59,7 @@ jobs: sed -e s/x.x.x/${releaseVersion:1}/g .release-note-template.md > ./release-notes.txt - name: Create release notes - uses: softprops/action-gh-release@v2.2.2 + uses: softprops/action-gh-release@v2.3.2 with: draft: true name: "${releaseVersion:1}" From 783055da9b5008cf6db6b7f97db9c0eab32aafb8 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 4 Aug 2025 20:11:46 +0200 Subject: [PATCH 04/16] Missing requirement for sm3 moving session management to C7 about digital identities (#148) * Update 07-access-controls.md * Move session management to digital identity * Move session management requirements to digital identity * Fixes linting --- .../06-digital-identity.md | 6 +++++- .../02-web-app-checklist/07-access-controls.md | 18 ++++++++---------- 2 files changed, 13 insertions(+), 11 deletions(-) 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 8546522d..c13f84c0 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 @@ -81,7 +81,7 @@ 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 Generation and Expiration +#### 4. Session Management 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 @@ -91,6 +91,10 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +7. If long authenticated sessions are allowed, periodically re-validate a user's authorization +8. The application must support termination of sessions when authorization ceases +9. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users + should be able to terminate their active sessions #### 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 dd2f0e07..0a0d941b 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 @@ -31,21 +31,19 @@ and use the list below as suggestions for a checklist that has been tailored for 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 -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 +2. Implement account auditing and enforce the disabling of unused accounts +3. A new account should have minimal or no access by default +4. 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 +5. Restrict function-level access to consumers with explicit permissions +6. 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) -9. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken +7. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA) -10. Restrict access security-relevant configuration information to only authorized users who have been allowed access through +8. 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 -11. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +9. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible #### References From 432507304e52ac97c9e2127e08eb85e763802fb2 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 4 Aug 2025 21:47:48 +0200 Subject: [PATCH 05/16] Update 06-digital-identity.md (#149) --- docs/en/04-design/02-web-app-checklist/06-digital-identity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 c13f84c0..e2b548f0 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 @@ -93,7 +93,7 @@ and use the list below as suggestions for a checklist that has been tailored for validating anti-forgery tokens (CSRF tokens) for each request that may change application state or execute an action 7. If long authenticated sessions are allowed, periodically re-validate a user's authorization 8. The application must support termination of sessions when authorization ceases -9. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users +9. Application administrators should be able to terminate active sessions and authentication codes and -tokens, and users should be able to terminate their active sessions #### References From 10b0909e25f3c234b2d4e54e7f4dfce637ee3bc8 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 5 Aug 2025 16:59:46 +0200 Subject: [PATCH 06/16] Concurrent sessions (#150) * changes in requirements to align on concurrent sessions * move all session management items under session management * Remove item concerning concurrent sessions * Reorder items --- .../06-digital-identity.md | 36 +++++++++---------- 1 file changed, 16 insertions(+), 20 deletions(-) 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 e2b548f0..0daf0c9c 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 @@ -56,7 +56,7 @@ and use the list below as suggestions for a checklist that has been tailored for 15. Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in the browser's storage mechanisms -#### 3. Cryptographic based authentication +#### 3. Session Management 1. Use the server or framework's session management controls 2. Session identifier creation must always be done on a trusted system @@ -70,30 +70,26 @@ and use the list below as suggestions for a checklist that has been tailored for 8. Disallow persistent logins and enforce periodic session terminations, even when the session is active 9. If a session was established before login, close that session and establish a new session after a successful login 10. Generate a new session identifier on any re-authentication -11. Do not allow concurrent logins with the same user ID -12. Do not expose session identifiers in URLs, error messages or logs -13. Implement appropriate access controls to protect server side session data +11. Do not expose session identifiers in URLs, error messages or logs +12. Implement appropriate access controls to protect server side session data from unauthorized access from other users of the server -14. Generate a new session identifier and deactivate the old one periodically -15. Generate a new session identifier if the connection security changes from HTTP to HTTPS, +13. Generate a new session identifier and deactivate the old one periodically +14. Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication -16. Set the `secure` attribute for cookies transmitted over an [TLS][tls] connection -17. Set cookies with the `HttpOnly` attribute, +15. Set the `secure` attribute for cookies transmitted over an [TLS][tls] connection +16. 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 - -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 +17. Ensure that the session id is long, unique and random, i.e., is of high entropy +18. Generate a new session during authentication and re-authentication +19. All active sessions must be terminated when a user account is disabled or deleted +20. After a successful change or removal of any authentication factor give the option to terminate all other active sessions +21. 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 +22. 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 -7. If long authenticated sessions are allowed, periodically re-validate a user's authorization -8. The application must support termination of sessions when authorization ceases -9. Application administrators should be able to terminate active sessions and authentication codes and -tokens, and users +23. If long authenticated sessions are allowed, periodically re-validate a user's authorization +24. The application must support termination of sessions when authorization ceases +25. Application administrators should be able to terminate active sessions and authentication codes and -tokens, and users should be able to terminate their active sessions #### References From 0cde6cae554e1271df4f0aabde11841245dcf498 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 5 Aug 2025 17:00:59 +0200 Subject: [PATCH 07/16] Correct identifier (#151) --- docs/en/04-design/02-web-app-checklist/08-protect-data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 0ecd71cf..bdf00485 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 @@ -58,7 +58,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +#### 6. Protect Data in Transit 1. Encrypt data in transit 2. Ensure secure communication channels are properly configured From d28c81972a780dd5ecc523363b428f4038de8d17 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 5 Aug 2025 17:16:58 +0200 Subject: [PATCH 08/16] generalize requirement (#152) --- docs/en/04-design/02-web-app-checklist/08-protect-data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 bdf00485..12c9a9f2 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 @@ -49,7 +49,7 @@ and use the list below as suggestions for a checklist that has been tailored for 6. Properly free allocated memory upon the completion of functions and at all exit points 7. Overwrite any sensitive information stored in allocated memory at all exit points from the function 8. Protect shared variables and resources from inappropriate concurrent access -9. Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.) +9. Avoid the use of known vulnerable functions #### 5. Protect Data at Rest From bac40ee5ef8c0b269b34c50743e0e01b6d483b75 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 7 Aug 2025 12:41:48 +0200 Subject: [PATCH 09/16] Adding SCP 115 (#153) * Adding 115 from SCP * ensure the line length isn't too long * Fix linting * Adding word to wordlist * Sort list * merge 6.1.12 and 6.1.21 * split 9.2.10 into 9.2.10 and 9.2.11 --- .wordlist-en.txt | 39 ++++++++++--------- .../06-digital-identity.md | 4 +- .../09-logging-monitoring.md | 5 +++ 3 files changed, 27 insertions(+), 21 deletions(-) diff --git a/.wordlist-en.txt b/.wordlist-en.txt index 7743e35d..af76f3d2 100644 --- a/.wordlist-en.txt +++ b/.wordlist-en.txt @@ -1,5 +1,5 @@ -AES AEAD +AES APIT APIs APK @@ -7,7 +7,7 @@ ARP ASVS AUTH Adoptium -alirezakkt +Amauri Analyser Andra Andreas @@ -17,16 +17,18 @@ AppSec AppSensor Arithmatex Atlassian +BOLA BOM BOMs +BOPLA BOV BetterEm +Bizerra Bluesky Brømsø CAPEC CCM CFB -ChaCha CISO CMS CMSeeK @@ -45,6 +47,7 @@ CVSS CWE Canonicalisation Cavalcanti +ChaCha ChartMuseum Cheatsheet Cheatsheets @@ -81,6 +84,7 @@ Dracon ECB ENISA ESAPI +Ebihara Ecommerce Elie EscapeAll @@ -218,6 +222,7 @@ RSA RansomWare Recx Riccardo +Roxana Ruleset SAFEcode SAML @@ -307,6 +312,7 @@ WHATWG WPScan WSTG Wayfinder +WebDAV WebGoat WebGoat's WebHook @@ -321,10 +327,13 @@ XML XSS XXE YAML +Yuuki ZH aSemy ai algorithmically +alirezakkt +allowlist angularjs api architected @@ -407,6 +416,7 @@ frontends gamification gamifies gamify +git github gitlab gmail @@ -423,6 +433,7 @@ integrations intel interoperate io +ip iteratively javascript js @@ -465,6 +476,7 @@ permalink personalization plaintext pre +printf programmatically proscriptive px @@ -495,10 +507,13 @@ skf socio soupsieve stacktrace +strcat +strcpy subcommand subcommands subdirectories subdirectory +svn synchronizer templating testbed @@ -506,8 +521,10 @@ testssl threatspec toolchain transactional +tunable txt typosquatting +unencrypted unforgeable unicode unkeyed @@ -526,19 +543,3 @@ wstg wtf www xsaero -Roxana -Amauri -Bizerra -Ebihara -Yuuki -svn -git -BOPLA -BOLA -WebDAV -tunable -allowlist -printf -strcat -strcpy -unencrypted 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 0daf0c9c..8f6b6b46 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 @@ -21,7 +21,8 @@ and use the list below as suggestions for a checklist that has been tailored for 9. Administrative and account management must be at least as secure as the primary authentication mechanism 10. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts 11. Re-authenticate users prior to performing critical operations -12. Enforce account disabling after an established number of invalid login attempts +12. Enforce account disabling after an established number of invalid login attempts, or add a random tunable + delay for authentication failures to defer brute force attacks and protect against timing attacks 13. Utilize authentication for connections to external systems that involve sensitive information or functions 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 @@ -33,7 +34,6 @@ and use the list below as suggestions for a checklist that has been tailored for 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 -21. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks #### 2. Passwords diff --git a/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md b/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md index 48bdbd3b..d97cbb05 100644 --- a/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md +++ b/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md @@ -32,6 +32,11 @@ and use the list below as suggestions for a checklist that has been tailored for 7. Synchronize across nodes to ensure that timestamps are consistent 8. All logging controls should be implemented on a trusted system 9. Ensure that a mechanism exists to conduct log analysis +10. Each log entry must includes necessary metadata (such as when, where, who, what) that would allow for a detailed + investigation of the timeline when an event happens +11. Each log entry must include a time stamp, severity, tagging of security events, + identity of the account holder, trace id and span id that can be correlated against the end user's ip, event outcome, + event description #### 3. Monitoring From 9a3f15799c014917c803ce6d778e17a70920f6fd Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 7 Aug 2025 13:40:14 +0200 Subject: [PATCH 10/16] #90 Adding identifiers for each headline in the checklist (#154) * Adding identifieras for each headline in the checklist * Add missing words to the wordlist * Update 07-access-controls.md --- .wordlist-en.txt | 18 +++++++++++++++++- .../01-secure-by-default.md | 6 +++--- .../02-frameworks-libraries.md | 2 +- .../03-secure-database-access.md | 6 +++--- .../04-encode-escape-data.md | 4 ++-- .../02-web-app-checklist/05-validate-inputs.md | 8 ++++---- .../06-digital-identity.md | 6 +++--- .../02-web-app-checklist/07-access-controls.md | 4 ++-- .../02-web-app-checklist/08-protect-data.md | 12 ++++++------ .../09-logging-monitoring.md | 6 +++--- .../10-handle-errors-exceptions.md | 2 +- 11 files changed, 45 insertions(+), 29 deletions(-) diff --git a/.wordlist-en.txt b/.wordlist-en.txt index af76f3d2..8be8120f 100644 --- a/.wordlist-en.txt +++ b/.wordlist-en.txt @@ -1,3 +1,4 @@ +ACM AEAD AES APIT @@ -28,10 +29,13 @@ Bluesky Brømsø CAPEC CCM +CEC CFB CISO CMS CMSeeK +COE +CP CPE CRL CRS @@ -82,6 +86,7 @@ DotNet DrHEADer Dracon ECB +EE ENISA ESAPI Ebihara @@ -90,6 +95,7 @@ Elie EscapeAll Exploitability FIPS +FV Flaxman GCM GCP @@ -144,6 +150,7 @@ Kubeaudit Kubernetes Kulkarni LDAP +LF LFD LINDDUN LINNDUN @@ -201,6 +208,7 @@ OpenID OpenJDK PCI PDFs +PDR PID PIDs PKI @@ -233,13 +241,19 @@ SBOM SBOMs SBT SCA +SCM SCP +SDA +SDC SDLC SDLCs SECCOMP SELinux +SFL SIEM SKF +SL +SLD SMS SNYK SPOA @@ -249,6 +263,7 @@ SSLyze SSO SSP SSRF +SSV SVG SaaSBOM Saad @@ -297,6 +312,7 @@ VDR VM VPN VPNs +VSD VWAD Vandana VerSprite @@ -542,4 +558,4 @@ wrongsecrets wstg wtf www -xsaero +xsaero \ No newline at end of file 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 index 892babc2..46543bd5 100644 --- 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 @@ -7,7 +7,7 @@ Refer to proactive control [C5: Secure By Default Configurations][control5] and 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. System configuration (SC) 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. @@ -31,7 +31,7 @@ the 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 +#### 2. File management (FM) 1. Turn off directory listings 2. Do not save files in the same web context as the application @@ -40,7 +40,7 @@ the 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 +#### 3. Cloud security (CS) 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 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 845f3dee..42a8b2c7 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 @@ -33,7 +33,7 @@ and use them as the starting point for a checklist that is tailored for the tech In addition consider the following extra checks for frameworks and libraries. -#### 1. Security Frameworks and Libraries +#### 1. Security frameworks and libraries (SFL) 1. Ensure servers, frameworks and system components are running the latest approved versions and patches 2. Use libraries and frameworks from trusted sources that are actively maintained and widely used diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md b/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md index 024bb810..bc1017e7 100644 --- a/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md +++ b/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md @@ -4,7 +4,7 @@ Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3 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. Secure queries +#### 1. Secure queries (SQ) 1. Use Query Parameterization to prevent untrusted input being interpreted as part of a SQL command 2. Use strongly typed parameterized queries @@ -14,7 +14,7 @@ and use the list below as suggestions for a checklist that has been tailored for 6. Connection strings should not be hard coded within the application 7. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted -#### 2. Secure configuration +#### 2. Secure database configuration (SDC) 1. The application should use the lowest possible level of privilege when accessing the database 2. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database @@ -23,7 +23,7 @@ and use the list below as suggestions for a checklist that has been tailored for 5. Remove unnecessary default vendor content, for example sample schemas 6. Disable any default accounts that are not required to support business requirements -#### 3. Secure authentication +#### 3. Secure database authentication (SDA) 1. Remove or change all default database administrative passwords 2. The application should connect to the database with different credentials for every trust distinction 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 74e560e3..400887e6 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 @@ -11,7 +11,7 @@ Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3 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. Character encoding and canonicalization +#### 1. Character encoding and canonicalization (CEC) 1. Apply output encoding just before the content is passed to the target system 2. Conduct all output encoding on a trusted system @@ -22,7 +22,7 @@ and use the list below as suggestions for a checklist that has been tailored for 7. In particular sanitize all output used for operating system commands 8. Sanitize potentially dangerous characters before using the data to call another service -#### 2. Contextual output encoding +#### 2. Contextual output encoding (COE) Contextual output encoding of data is based on how it will be utilized by the target. The specific methods vary depending on the way the output data is used, such as HTML entity encoding. 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 4535a569..5d0794f6 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 @@ -8,7 +8,7 @@ Refer to proactive control [C3: Validate All Input & Handle Exceptions][control3 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. Syntax and semantic validity +#### 1. Syntax and semantic validity (SSV) 1. Identify all data sources and classify them into trusted and untrusted 2. Validate all input data from untrusted sources such as client provided data @@ -21,7 +21,7 @@ and use the list below as suggestions for a checklist that has been tailored for 9. All validation failures should result in input rejection 10. Validate all input against an allowlist of characters, whenever possible -#### 2. Libraries and frameworks +#### 2. Libraries and frameworks (LF) 1. Conduct all input validation on a trusted system [^SCP1] 2. Use a centralized input validation library or framework for the whole application @@ -30,7 +30,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +#### 3. Validate serialized data (VSD) 1. Implement integrity checks or encryption of the serialized objects to prevent hostile object creation or data tampering @@ -41,7 +41,7 @@ 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 +#### 4. File validation (FV) 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 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 8f6b6b46..82abf152 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 @@ -6,7 +6,7 @@ Refer to proactive control [C7: Secure Digital Identities][control7] 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. Authentication +#### 1. Authentication (A) 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 @@ -35,7 +35,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 -#### 2. Passwords +#### 2. Passwords (P) 1. If your application manages a credential store, use cryptographically strong one-way salted hashes 2. Password hashing must be implemented on a trusted system @@ -56,7 +56,7 @@ and use the list below as suggestions for a checklist that has been tailored for 15. Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in the browser's storage mechanisms -#### 3. Session Management +#### 3. Session Management (SM) 1. Use the server or framework's session management controls 2. Session identifier creation must always be done on a trusted system 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 0a0d941b..1eb65b56 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. Implement Access Control +#### 1. Access control (AC) 1. Design access control / authorization thoroughly up-front 2. Force all requests to go through access control checks unless public @@ -27,7 +27,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 Management +#### 2. Access control management (ACM) 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 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 12c9a9f2..9a7a5beb 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 @@ -6,7 +6,7 @@ Refer to proactive control [C2: Use Cryptography to Protect Data][control2] and 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. Cryptographic practices +#### 1. Cryptographic practices (CP) 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 @@ -17,7 +17,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +#### 2. Data protection (DP) 1. Classify data according to the level of sensitivity 2. Implement appropriate access controls for sensitive data @@ -28,7 +28,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 -#### 3. Secret Management +#### 3. Secret and credential management (SCM) 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 @@ -39,7 +39,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +#### 4. Memory management (MM) 1. Explicitly initialize all variables and data stores 2. Check that any buffers are as large as specified @@ -51,14 +51,14 @@ 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 -#### 5. Protect Data at Rest +#### 5. Protect Data at Rest (PDR) 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 -#### 6. Protect Data in Transit +#### 6. Protect Data in Transit (PDT) 1. Encrypt data in transit 2. Ensure secure communication channels are properly configured diff --git a/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md b/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md index d97cbb05..abb35b8f 100644 --- a/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md +++ b/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md @@ -5,7 +5,7 @@ Refer to proactive control [C9: Implement Security Logging and Monitoring][contr and its [cheatsheets][csproactive-c9] 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. Security logging +#### 1. Security logging (SL) 1. Log submitted data that is outside of an expected numeric range 2. Log all apparent tampering events, that involve changes to data and state that should not be modifiable @@ -21,7 +21,7 @@ and use the list below as suggestions for a checklist that has been tailored for 12. Log all backend TLS connection failures 13. Log cryptographic module failures -#### 2. Security logging design +#### 2. Security logging design (SLD) 1. Protect log integrity 2. Ensure log entries that include untrusted data will not execute as code in the intended log viewing interface or software @@ -38,7 +38,7 @@ and use the list below as suggestions for a checklist that has been tailored for identity of the account holder, trace id and span id that can be correlated against the end user's ip, event outcome, event description -#### 3. Monitoring +#### 3. Monitoring (M) 1. Effective monitoring and alerting should be established to detect and respond to suspicious activities quickly 2. Account for attack patterns that bypass standard lockouts, such as using the same passwords against multiple user accounts diff --git a/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md b/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md index 04b4548c..d9c5387f 100644 --- a/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md +++ b/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md @@ -6,7 +6,7 @@ Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3 and its [cheatsheets][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. -#### 1. Errors and exceptions +#### 1. Errors and exceptions (EE) 1. Manage exceptions in a centralized manner to avoid duplicated try/catch blocks in the code 2. Ensure that all unexpected behavior is correctly handled inside the application From bcb805abe53a192a9e6cd6358827399c9ee9dbd9 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 7 Aug 2025 15:46:10 +0200 Subject: [PATCH 11/16] Update the checklist to add information regarding owasp scp (#155) --- docs/en/04-design/02-web-app-checklist/index.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/en/04-design/02-web-app-checklist/index.md b/docs/en/04-design/02-web-app-checklist/index.md index 30766d94..307e4af6 100644 --- a/docs/en/04-design/02-web-app-checklist/index.md +++ b/docs/en/04-design/02-web-app-checklist/index.md @@ -12,6 +12,10 @@ an individual project's requirements and environment; they are not meant to be f Probably the best starting point for a checklist is given by the [Application Security Verification Standard (ASVS)][asvs]. The ASVS can be used to provide a framework for an initial checklist, according to the security verification level, and this initial ASVS checklist can then be expanded using the following checklist sections. +An effort has also been made to migrate best practices from the [OWASP Secure Coding Practices-Quick Reference Guide][scp] +to the OWASP DevGuide. +This checklist should contain most of the items from the quick references, some, however, have been rewritten or left out to +ensure this checklist is in line with modern practices. ---- @@ -22,3 +26,4 @@ then [submit an issue][issue0602] or [edit on GitHub][edit0602]. [edit0602]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/index.md [issue0602]: https://github.com/OWASP/DevGuide/issues/new?labels=content&template=request.md&title=Update:%2004-design/02-web-app-checklist/index [proactive10]: https://owasp.org/www-project-proactive-controls/ +[scp]: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ From 81107541b7f2af0eab6dcfaf1984fe81c1e2ed23 Mon Sep 17 00:00:00 2001 From: Jon Gadsden Date: Tue, 26 Aug 2025 14:32:38 +0100 Subject: [PATCH 12/16] update workflow actions --- .github/workflows/ci.yaml | 12 ++++++------ .github/workflows/housekeeping.yaml | 4 ++-- .github/workflows/pr.yaml | 16 ++++++++-------- .github/workflows/release.yaml | 6 +++--- contributing.md | 13 +++++++++---- release-process.md | 2 +- 6 files changed, 29 insertions(+), 24 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index f7fe01e2..4c9618a5 100644 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -20,10 +20,10 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Link Checker - uses: lycheeverse/lychee-action@v2.4.1 + uses: lycheeverse/lychee-action@v2.6.1 with: args: >- --no-progress @@ -41,7 +41,7 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Lint markdown uses: DavidAnson/markdownlint-cli2-action@v20.0.0 @@ -57,7 +57,7 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Spell check EN language uses: rojopolis/spellcheck-github-actions@0.51.0 @@ -92,7 +92,7 @@ jobs: needs: [md_linter, spell_checker] steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Install python uses: actions/setup-python@v5.6.0 @@ -125,7 +125,7 @@ jobs: needs: [md_linter, spell_checker] steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Install python uses: actions/setup-python@v5.6.0 diff --git a/.github/workflows/housekeeping.yaml b/.github/workflows/housekeeping.yaml index 623dcf2c..03bc0271 100644 --- a/.github/workflows/housekeeping.yaml +++ b/.github/workflows/housekeeping.yaml @@ -34,10 +34,10 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Link Checker - uses: lycheeverse/lychee-action@v2.4.1 + uses: lycheeverse/lychee-action@v2.6.1 with: # skip the jekyll files under '_includes' directory, check all other directories args: >- diff --git a/.github/workflows/pr.yaml b/.github/workflows/pr.yaml index 907ee1ff..d30955fc 100644 --- a/.github/workflows/pr.yaml +++ b/.github/workflows/pr.yaml @@ -13,10 +13,10 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Link Checker - uses: lycheeverse/lychee-action@v2.4.1 + uses: lycheeverse/lychee-action@v2.6.1 with: args: >- --no-progress @@ -34,7 +34,7 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Lint markdown uses: DavidAnson/markdownlint-cli2-action@v20.0.0 @@ -50,7 +50,7 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Spell check EN language uses: rojopolis/spellcheck-github-actions@0.51.0 @@ -62,7 +62,7 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Spell check ES language uses: rojopolis/spellcheck-github-actions@0.51.0 @@ -74,7 +74,7 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 # rojopolis/spellcheck-github-actions does not support PT-BR, # only PT, and PT-BR is too different to pass a PT spellcheck @@ -99,7 +99,7 @@ jobs: needs: [md_linter, spell_checker_en, spell_checker_es, spell_checker_pt-br] steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Install python uses: actions/setup-python@v5.6.0 @@ -129,7 +129,7 @@ jobs: needs: [build_check] steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Install python uses: actions/setup-python@v5.6.0 diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index cd1cee04..de7327d9 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -15,7 +15,7 @@ jobs: runs-on: ubuntu-24.04 steps: - name: Checkout markdown - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Install python uses: actions/setup-python@v5.6.0 @@ -45,10 +45,10 @@ jobs: needs: [export_pdf] steps: - name: Check out - uses: actions/checkout@v4.2.2 + uses: actions/checkout@v5.0.0 - name: Fetch prepared SBOM artifacts - uses: actions/download-artifact@v4.3.0 + uses: actions/download-artifact@v5.0.0 with: name: 'pdf-export' path: 'site/OWASP_Developer_Guide.pdf' diff --git a/contributing.md b/contributing.md index 1268bb7d..fd0344ad 100644 --- a/contributing.md +++ b/contributing.md @@ -18,7 +18,11 @@ Feel free to discuss topics in the [project wiki][wiki] and create new discussio * follow our [Code of Conduct](code_of_conduct.md) * ensure that all contributions are within the [license](license.txt) -* the use of generative AI is not prohibited but must be declared in the pull request +* although the use of generative AI is not prohibited, it _must_ be declared in the pull request + +The Developer Guide is a documentation project and so there may be differences of opinion on wording or punctuation. +If you submit a pull request please make it substantive, otherwise +it will be hard to get attention from the maintainers for trivial changes and it may end up being rejected. #### Philosophy @@ -54,9 +58,10 @@ and should rarely deal with any subject at an advanced level. This is a deliberate policy that makes the guide accessible and keeps the length reasonable. The overview/introduction of the main sections should be aimed at the introductory level, -with more detail contained in the sub-sections at a medium technical level. +with more detail at a medium technical level contained in any sections that follow. + Note this guide should not replicate the many detailed sources on specific security topics; -instead provide links to these specialist security knowledge bases. +instead provide links to any specialist security knowledge bases and refer the user to them. #### Page structure @@ -96,7 +101,7 @@ If you can help with these translations then please contact the lead translator ### Media kit The OWASP projects have [media kits][media] that contain biographies of the project leaders and other project media. -This can be used for logos and marketing material. +Please use the project media for any logos and marketing material. ### Pull requests diff --git a/release-process.md b/release-process.md index d1932bb5..6470f26b 100644 --- a/release-process.md +++ b/release-process.md @@ -26,7 +26,7 @@ The [PDF][pdf-guide] version of the [web document][devguide] can be downloaded f [devguide]: devguide.owasp.org [leaders]: https://github.com/OWASP/www-project-developer-guide/blob/main/leaders.md -[pdf-guide]: https://github.com/OWASP/threat-dragon/releases/download/v4.1.8/OWASP_Developer_Guide-V4.1.8.pdf +[pdf-guide]: https://github.com/OWASP/DevGuide/releases/download/vx.x.x/OWASP_Developer_Guide-Vx.x.x.pdf ``` ---- From 96d6acc7c55cb5fd6d4ef86256d7d12c9cef4ec5 Mon Sep 17 00:00:00 2001 From: Jon Gadsden Date: Wed, 27 Aug 2025 09:08:51 +0100 Subject: [PATCH 13/16] add OpenSSF badge --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index c6f5582e..378a4f61 100644 --- a/README.md +++ b/README.md @@ -3,6 +3,7 @@ [![CC BY-SA 4.0 license](https://img.shields.io/github/license/owasp/DevGuide.svg)](license.txt) [![OWASP Lab project](https://img.shields.io/badge/owasp-lab%20project-f7b73c.svg)](https://www.owasp.org/projects) [![Build status](https://github.com/OWASP/DevGuide/actions/workflows/ci.yaml/badge.svg?event=push)][build] +[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/9373/badge)](https://www.bestpractices.dev/projects/9373) ## OWASP Foundation Developer Guide From b38da666d9ab828d37931b578830fed65efac3ad Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 23 Sep 2025 12:56:15 +0200 Subject: [PATCH 14/16] #158 Correcting page about OWASP Cornucopia (#159) * #158 Correcting page about OWASP Cornucopia * #158 Correct linting * #158 Correct linting and add words to wordlist * #158 Correct url --- .wordlist-en.txt | 4 ++ .../01-threat-modeling/04-cornucopia.md | 49 ++++++++++++------- 2 files changed, 36 insertions(+), 17 deletions(-) diff --git a/.wordlist-en.txt b/.wordlist-en.txt index 8be8120f..837786d6 100644 --- a/.wordlist-en.txt +++ b/.wordlist-en.txt @@ -58,6 +58,7 @@ Cheatsheets ClickJacking Clickjacking CodeQL +Copi Coraza Crackmes Cryptographic @@ -175,6 +176,7 @@ MagicLink Matteo Microservices Misconfiguration +MLSec ModSecurity Multifactor NIST @@ -419,6 +421,7 @@ edumco encodings endif enum +eop esapi executables exfiltrate @@ -470,6 +473,7 @@ lychee mastg maswe misconfiguration +mlsec mitigations modsecurity modularized diff --git a/docs/en/04-design/01-threat-modeling/04-cornucopia.md b/docs/en/04-design/01-threat-modeling/04-cornucopia.md index 9757cddb..77525bd7 100644 --- a/docs/en/04-design/01-threat-modeling/04-cornucopia.md +++ b/docs/en/04-design/01-threat-modeling/04-cornucopia.md @@ -1,19 +1,30 @@ ![Cornucopia logo](../../../assets/images/logos/cornucopia.png "OWASP Cornucopia"){ align=right width=180 } -OWASP Cornucopia is a card game used to help derive application security requirements -during the software development life cycle. -[Cornucopia][cornucopia] is an OWASP Lab project, and can be [downloaded][cornucopia-cards] from its project page. +OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams identify security +requirements in Agile, conventional and formal development processes. It is language, platform and technology-agnostic. +The idea behind Cornucopia is to help development teams, especially those using Agile methodologies, to identify application +security requirements and develop security-based user stories. +[Cornucopia][cornucopia] is an OWASP production project. The cards can be [downloaded][cornucopia-cards] and printed or +[bought online][online] from its website. +It is also possible to play OWASP Cornucopia online using the cornucopia game engine called [Copi][copi]. Using the +[online game engine][copi], it is possible to play: + +* [OWASP Cornucopia Website App][start-game] to gamify threat modeling and requirement analysis for website apps +* [OWASP Cornucopia Mobile App][start-game] to gamify threat modeling and requirement analysis for mobile apps +* [Elevation of Privilege][eop] to do general threat modeling +* [Elevation of MLSec][mlsec] for threat modeling applications that uses machine learning or Gen AI +* [OWASP Cumulus][cumulus] for threat model cloud infrastructure #### What is Cornucopia? -Cornucopia provides a [set of cards][cornucopia-cards] designed to gamify threat modeling activities, +Cornucopia provides a [set of cards][cornucopia-browser] designed to gamify threat modeling activities, helping agile development teams to identify weaknesses in applications and then record remediations or requirements. There are three versions of the Cornucopia deck of threat modeling cards: * Website App Edition * Mobile App Edition -* Enterprise App Edition +* Enterprise App Edition (legacy) The decks come with several suits according to the application, and always contain an overall 'Cornucopia' suit. @@ -36,13 +47,11 @@ Vulnerabilities are arranged in domains as five suits with the additional Cornuc To provide context the Cornucopia Website App cards reference other projects: * OWASP Application Security Verification Standard ([ASVS][asvs]) -* OWASP Secure Coding Practices ([SCP][scp-v21]]) quick reference guide -* OWASP [AppSensor][appsensor] +* OWASP Developer Guide ([Web Application Checklist][devguide]) +* STRIDE * MITRE's Common Attack Pattern Enumeration and Classification ([CAPEC][capec]) * [SAFEcode][safecode] -The SCP quick reference guide has now been incorporated as part of this [Developer Guide](../02-web-app-checklist/index.md). - #### Mobile App Edition Similarly to the website application deck, the mobile application deck has five domains/suits, @@ -79,7 +88,8 @@ The outcome of the game is to identify possible threats and propose remediations #### How to use Cornucopia The OWASP Spotlight series provides an excellent overview of Cornucopia and how it can be used for gamification: -'Project 16 - [Cornucopia][spotlight16]'. +'Project 16 - [Cornucopia][spotlight16]'. [Videos on the OWASP Cornucopia website][cornucopia-play] also demonstrate several +ways the game can be utilized. Ideally Cornucopia is played in person using physical cards, with the development team and security architects in the same room. @@ -103,32 +113,37 @@ as well as having a good time. #### References -* [AppSensor][appsensor] * Application Security Verification Standard, [ASVS][asvs] * Common Attack Pattern Enumeration and Classification, [CAPEC][capec] * [Cornucopia][cornucopia] * Mobile Application Security Verification Standard, [MASVS][masvs]) * Mobile Application Security Testing Guide, [MASTG][mastg]) -* [Secure Coding Practices][scp-v21] quick reference guide * [SAFEcode][safecode] * [Spotlight][spotlight16] on Cornucopia +* OWASP Developer Guide ([Web Application Checklist][devguide]) ---- The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue060104] or [edit on GitHub][edit060104]. -[appsensor]: https://owasp.org/www-project-appsensor/ [asvs]: https://owasp.org/www-project-application-security-verification-standard/ [capec]: https://capec.mitre.org/ -[cornucopia]: https://owasp.org/www-project-cornucopia/ -[cornucopia-cards]: https://owasp.org/www-project-cornucopia#div-cards +[cornucopia]: https://cornucopia.owasp.org +[cornucopia-browser]: https://cornucopia.owasp.org/cards +[cornucopia-cards]: https://cornucopia.owasp.org/printing#Current-printable-version [cornucopia-score]: https://owasp.org/www-project-cornucopia/assets/files/Cornucopia-scoresheet.pdf -[cornucopia-play]: https://owasp.org/www-project-cornucopia#div-play +[cornucopia-play]: https://cornucopia.owasp.org/how-to-play +[copi]: https://copi.owasp.org +[cumulus]: https://github.com/OWASP/cumulus +[eop]: https://github.com/adamshostack/eop [edit060104]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/04-cornucopia.md [issue060104]: https://github.com/OWASP/DevGuide/issues/new?labels=content&template=request.md&title=Update:%2004-design/01-threat-modeling/04-cornucopia [mastg]: https://mas.owasp.org/MASTG/ [masvs]: https://mas.owasp.org/MASVS/ +[mlsec]: https://github.com/kantega/elevation-of-mlsec +[online]: https://cornucopia.owasp.org/webshop [safecode]: https://safecode.org/ -[scp-v21]: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/assets/docs/OWASP_SCP_Quick_Reference_Guide_v21.pdf +[devguide]: https://devguide.owasp.org/en/04-design/02-web-app-checklist [spotlight16]: https://youtu.be/NesxjEGX58s +[start-game]: https://copi.owasp.org/games/new From d6c1e05940e89afc6448888710063441a1bb4a5d Mon Sep 17 00:00:00 2001 From: Izar Tarandach Date: Thu, 9 Oct 2025 15:03:32 -0400 Subject: [PATCH 15/16] Pytm description fix (#163) * pytm is a Python library * Fixing some details about pytm * Apparently I can't spell in 2 languages --- docs/en/04-design/01-threat-modeling/02-pytm.md | 8 ++++---- docs/es/04-design/01-threat-modeling/02-pytm.md | 9 ++++----- 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/docs/en/04-design/01-threat-modeling/02-pytm.md b/docs/en/04-design/01-threat-modeling/02-pytm.md index 3493a3be..bcdcc28d 100644 --- a/docs/en/04-design/01-threat-modeling/02-pytm.md +++ b/docs/en/04-design/01-threat-modeling/02-pytm.md @@ -3,13 +3,13 @@ The OWASP [pytm (Pythonic Threat Modeling)][pytmproject] project is a framework for threat modeling and its automation. The goal of pytm is to shift threat modeling to the left, making threat modeling more automated and developer-centric. -Pytm is an OWASP Lab Project with a community of contributors creating [regular releases][pytmreleases]. +Pytm is an OWASP Production Project with a community of contributors creating [regular releases][pytmreleases]. #### What is pytm? -Pytm is a Java library that provides programmatic way of threat modeling; +Pytm is a Python library that provides a programmatic way of threat modeling; the application model itself is defined as a python3 source file and follows Python program syntax. -Findings are included in the application model python program with threats defined as rows in an associated text file. +Findings are included in a template-defined threat modeling report. The threat file can be reused between projects and provides for accumulation of a knowledge base. Using pytm the model and threats can be programmatically output as a [dot][graphvizdot] data flow diagram @@ -59,7 +59,7 @@ The following tools and libraries need to be installed: * Python 3.x * [Graphviz][graphvizdot] package -* Java, such as OpenJDK 10 or 11 +* Java, such as OpenJDK 10 or 11 (exclusively for the generation of the sequence diagram) * the [PlantUML][plantumljar] executable JAR file * and of course pytm itself: clone the [pytm project repo][pytmrepo] diff --git a/docs/es/04-design/01-threat-modeling/02-pytm.md b/docs/es/04-design/01-threat-modeling/02-pytm.md index 2bad418d..613a8614 100644 --- a/docs/es/04-design/01-threat-modeling/02-pytm.md +++ b/docs/es/04-design/01-threat-modeling/02-pytm.md @@ -6,15 +6,14 @@ El objetivo de pytm es realizar el modelado de amenazas Shift-Left, lo que signi el modelado ya en etapas tempranas del proyecto, haciendo que el modelado de amenazas sea más automatizado y centrado en el desarrollador. -Pytm es un Proyecto de Laboratorio de OWASP con una comunidad de colaboradores +Pytm es un Proyecto de Producción de OWASP con una comunidad de colaboradores que crean [versiones regulares][pytmreleases]. #### ¿Qué es pytm? -Pytm es una biblioteca Java que proporciona una forma programática de modelado de amenazas; +Pytm es una biblioteca Python que proporciona una forma programática de modelado de amenazas; el modelo de aplicación en sí se define como un archivo fuente de python3 y sigue la sintaxis del programa Python. -Los hallazgos se incluyen en el programa python del modelo de aplicación con amenazas definidas -como filas en un archivo de texto asociado. +Los hallazgos se incluyen en un informe de modelado de amenazas basado en plantillas. El archivo de amenazas puede reutilizarse entre proyectos y permite la acumulación de una base de conocimiento. Usando pytm, el modelo y las amenazas pueden ser programáticamente generados @@ -69,7 +68,7 @@ Las siguientes herramientas y bibliotecas deben estar instaladas: * Python 3.x * Paquete [Graphviz][graphvizdot] -* Java, como OpenJDK 10 u 11 +* Java, como OpenJDK 10 u 11 (solamente para el uso del diagrama de secuencia) * El archivo JAR ejecutable de [PlantUML][plantumljar] * Y por supuesto pytm: clone el [repositorio del proyecto pytm][pytmrepo] From 526a9b63fa00181c6f52c72f9179ff330e2ab0ad Mon Sep 17 00:00:00 2001 From: Jon Gadsden Date: Mon, 13 Oct 2025 21:20:56 +0100 Subject: [PATCH 16/16] update actions in workflows --- .github/workflows/ci.yaml | 10 +++++----- .github/workflows/housekeeping.yaml | 2 +- .github/workflows/pr.yaml | 10 +++++----- .github/workflows/release.yaml | 4 ++-- 4 files changed, 13 insertions(+), 13 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 4c9618a5..158d2f05 100644 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -60,19 +60,19 @@ jobs: uses: actions/checkout@v5.0.0 - name: Spell check EN language - uses: rojopolis/spellcheck-github-actions@0.51.0 + uses: rojopolis/spellcheck-github-actions@0.52.0 with: config_path: .spellcheck-en.yaml - name: Spell check ES language - uses: rojopolis/spellcheck-github-actions@0.51.0 + uses: rojopolis/spellcheck-github-actions@0.52.0 with: config_path: .spellcheck-es.yaml # rojopolis/spellcheck-github-actions does not support PT-BR, # only PT, and PT-BR is too different to pass a PT spellcheck - name: Set up Python for PT-BR - uses: actions/setup-python@v5.6.0 + uses: actions/setup-python@v6.0.0 with: python-version: '3.10' @@ -95,7 +95,7 @@ jobs: uses: actions/checkout@v5.0.0 - name: Install python - uses: actions/setup-python@v5.6.0 + uses: actions/setup-python@v6.0.0 with: python-version: 3.x @@ -128,7 +128,7 @@ jobs: uses: actions/checkout@v5.0.0 - name: Install python - uses: actions/setup-python@v5.6.0 + uses: actions/setup-python@v6.0.0 with: python-version: 3.x diff --git a/.github/workflows/housekeeping.yaml b/.github/workflows/housekeeping.yaml index 03bc0271..fc72c7fb 100644 --- a/.github/workflows/housekeeping.yaml +++ b/.github/workflows/housekeeping.yaml @@ -60,7 +60,7 @@ jobs: steps: - name: Tidy stale PRs and issues - uses: actions/stale@v9 + uses: actions/stale@v10.1.0 with: days-before-issue-stale: 183 days-before-issue-close: -1 diff --git a/.github/workflows/pr.yaml b/.github/workflows/pr.yaml index d30955fc..c868bfd5 100644 --- a/.github/workflows/pr.yaml +++ b/.github/workflows/pr.yaml @@ -53,7 +53,7 @@ jobs: uses: actions/checkout@v5.0.0 - name: Spell check EN language - uses: rojopolis/spellcheck-github-actions@0.51.0 + uses: rojopolis/spellcheck-github-actions@0.52.0 with: config_path: .spellcheck-en.yaml @@ -65,7 +65,7 @@ jobs: uses: actions/checkout@v5.0.0 - name: Spell check ES language - uses: rojopolis/spellcheck-github-actions@0.51.0 + uses: rojopolis/spellcheck-github-actions@0.52.0 with: config_path: .spellcheck-es.yaml @@ -79,7 +79,7 @@ jobs: # rojopolis/spellcheck-github-actions does not support PT-BR, # only PT, and PT-BR is too different to pass a PT spellcheck - name: Set up Python - uses: actions/setup-python@v5.6.0 + uses: actions/setup-python@v6.0.0 with: python-version: '3.10' @@ -102,7 +102,7 @@ jobs: uses: actions/checkout@v5.0.0 - name: Install python - uses: actions/setup-python@v5.6.0 + uses: actions/setup-python@v6.0.0 with: python-version: 3.x @@ -132,7 +132,7 @@ jobs: uses: actions/checkout@v5.0.0 - name: Install python - uses: actions/setup-python@v5.6.0 + uses: actions/setup-python@v6.0.0 with: python-version: 3.x diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index de7327d9..c09db037 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -18,7 +18,7 @@ jobs: uses: actions/checkout@v5.0.0 - name: Install python - uses: actions/setup-python@v5.6.0 + uses: actions/setup-python@v6.0.0 with: python-version: 3.x @@ -59,7 +59,7 @@ jobs: sed -e s/x.x.x/${releaseVersion:1}/g .release-note-template.md > ./release-notes.txt - name: Create release notes - uses: softprops/action-gh-release@v2.3.2 + uses: softprops/action-gh-release@v2.3.3 with: draft: true name: "${releaseVersion:1}"