From 510f0acf49be61064831e902966f04ed51d837db Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 17:23:31 +0200 Subject: [PATCH 01/92] Update and rename 01-define-security-requirements.md to 04-address-security-from-the-start.md --- ...y-requirements.md => 04-address-security-from-the-start.md} | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) rename docs/en/04-design/02-web-app-checklist/{01-define-security-requirements.md => 04-address-security-from-the-start.md} (95%) 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/04-address-security-from-the-start.md similarity index 95% rename from docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md rename to docs/en/04-design/02-web-app-checklist/04-address-security-from-the-start.md index 1ed1f4ef..859fdbf5 100644 --- a/docs/en/04-design/02-web-app-checklist/01-define-security-requirements.md +++ b/docs/en/04-design/02-web-app-checklist/04-address-security-from-the-start.md @@ -1,5 +1,4 @@ -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. +When designing a new application, creating a secure architecture prevents vulnerabilities before they even become part of the application. This prevents costly repairs and repudiation problems. 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, From 8f021a340def15bf6edfd5bf0d933b784b1e164c Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 17:32:56 +0200 Subject: [PATCH 02/92] Update and rename 02-frameworks-libraries.md to 06-keep-your-components-secure.md --- ...meworks-libraries.md => 06-keep-your-components-secure.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename docs/en/04-design/02-web-app-checklist/{02-frameworks-libraries.md => 06-keep-your-components-secure.md} (97%) diff --git a/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md b/docs/en/04-design/02-web-app-checklist/06-keep-your-components-secure.md similarity index 97% rename from docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md rename to docs/en/04-design/02-web-app-checklist/06-keep-your-components-secure.md index 6addfdd6..85dc96b2 100644 --- a/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md +++ b/docs/en/04-design/02-web-app-checklist/06-keep-your-components-secure.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: @@ -84,7 +84,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 From 4fd43de8caeea2b427993bae1c3c8f9de26fed55 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 17:44:23 +0200 Subject: [PATCH 03/92] Update 06-digital-identity.md --- 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 97c390d4..ff4a2e9b 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,7 +2,7 @@ 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. From 4e07af5b7aa5b78ffec1e935c01a63c28d82caf9 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 17:44:53 +0200 Subject: [PATCH 04/92] Rename 04-address-security-from-the-start.md to 01-address-security-from-the-start.md --- ...ty-from-the-start.md => 01-address-security-from-the-start.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{04-address-security-from-the-start.md => 01-address-security-from-the-start.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/04-address-security-from-the-start.md b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/04-address-security-from-the-start.md rename to docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md From 5a7beb0a05f4709c3f9bfb865dbcf5087f42097a Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 17:45:30 +0200 Subject: [PATCH 05/92] Rename 06-keep-your-components-secure.md to 02-keep-your-components-secure.md --- ...our-components-secure.md => 02-keep-your-components-secure.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{06-keep-your-components-secure.md => 02-keep-your-components-secure.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/06-keep-your-components-secure.md b/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/06-keep-your-components-secure.md rename to docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md From 3d2d351f72bcefea12358be1368623d8af090a88 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 18:34:47 +0200 Subject: [PATCH 06/92] Update 08-protect-data.md --- 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 9f47130b..c8911400 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,7 +2,7 @@ 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. From 6633ce55d0dd38c0570e1cd9d365539134c4bd68 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 19:08:43 +0200 Subject: [PATCH 07/92] Create 02-secure-by-default-configurations.md --- .../02-web-app-checklist/02-secure-by-default-configurations.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md diff --git a/docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md @@ -0,0 +1 @@ + From 598c8aa9aeb630fd3436bbd50a9531ba0af6579e Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 19:22:54 +0200 Subject: [PATCH 08/92] Create 03-secure-by-default-configurations.md --- .../03-secure-by-default-configurations.md | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md new file mode 100644 index 00000000..b295458f --- /dev/null +++ b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md @@ -0,0 +1,27 @@ +“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. Remove all unnecessary functionality and files +3. Remove test code or any functionality not intended for production, prior to deployment +4. The security configuration store for the application should be available in human readable form to support auditing +5. Isolate development environments from production and provide access only to authorized development and test groups +6. Implement a software change control system to manage and record changes to the code both in development and production +7. Turn off directory listings +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 +14. Restrict access to files or other resources, including those outside the application's direct control using an allow list or the equivalent thereof. + +[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 From 731dba91c995115893f7f7e4913623374f53936c Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 19:24:07 +0200 Subject: [PATCH 09/92] Delete docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md --- .../02-web-app-checklist/02-secure-by-default-configurations.md | 1 - 1 file changed, 1 deletion(-) delete mode 100644 docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md diff --git a/docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md deleted file mode 100644 index 8b137891..00000000 --- a/docs/en/04-design/02-web-app-checklist/02-secure-by-default-configurations.md +++ /dev/null @@ -1 +0,0 @@ - From 2aa54e420de44bcf6cec39cf47a627db706fa4cd Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 19:25:22 +0200 Subject: [PATCH 10/92] Update 03-secure-by-default-configurations.md --- .../02-web-app-checklist/03-secure-by-default-configurations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md index b295458f..38810799 100644 --- a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md +++ b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md @@ -6,7 +6,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 1. Restrict applications, processes and service accounts to the least privileges possible 2. Remove all unnecessary functionality and files From 73890f5ea52622227d737a8f50992677b0a02908 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 20:49:16 +0200 Subject: [PATCH 11/92] Move configuration requirements to secure by default configuration --- .../01-address-security-from-the-start.md | 23 +------------------ 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md index 859fdbf5..25ac5b4c 100644 --- a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md +++ b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md @@ -6,28 +6,7 @@ and use the lists below as suggestions for a checklist that has been tailored fo #### 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. +1. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible #### 2. Cryptographic practices From 277d91f58cc107b9a2c15827e94957bd014ba233 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:33:21 +0200 Subject: [PATCH 12/92] correct linking --- .../02-web-app-checklist/02-keep-your-components-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md b/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md index 85dc96b2..35544fea 100644 --- a/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md +++ b/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md @@ -84,7 +84,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 -[control6]: [https://top10proactive.owasp.org/the-top-10/c6-use-secure-dependencies/] +[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 From b078e8bbb9ad89cba448c7241f2954ca58a955ce Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:39:22 +0200 Subject: [PATCH 13/92] Update 02-keep-your-components-secure.md --- .../02-web-app-checklist/02-keep-your-components-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md b/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md index 35544fea..2620c5db 100644 --- a/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md +++ b/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md @@ -39,7 +39,7 @@ 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 From 5f900ec3471303634a41301e12473b3e5cf7579a Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:46:55 +0200 Subject: [PATCH 14/92] Rename 03-secure-database-access.md to 04-secure-database-access.md --- ...{03-secure-database-access.md => 04-secure-database-access.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{03-secure-database-access.md => 04-secure-database-access.md} (100%) 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/04-secure-database-access.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/03-secure-database-access.md rename to docs/en/04-design/02-web-app-checklist/04-secure-database-access.md From 30ea175dfaaac76f9aebe19a7827377e48da3bf3 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:47:48 +0200 Subject: [PATCH 15/92] Rename 04-secure-database-access.md to 06-secure-database-access.md --- ...{04-secure-database-access.md => 06-secure-database-access.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{04-secure-database-access.md => 06-secure-database-access.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/04-secure-database-access.md b/docs/en/04-design/02-web-app-checklist/06-secure-database-access.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/04-secure-database-access.md rename to docs/en/04-design/02-web-app-checklist/06-secure-database-access.md From 6ccc8b3f5301bfa80c8e73eb905a60697be2a011 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:48:20 +0200 Subject: [PATCH 16/92] Rename 06-digital-identity.md to 07-digital-identity.md --- .../{06-digital-identity.md => 07-digital-identity.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{06-digital-identity.md => 07-digital-identity.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/06-digital-identity.md rename to docs/en/04-design/02-web-app-checklist/07-digital-identity.md From bd284d86f1d18a91c814bbb66db8035bfad9c7c2 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:48:58 +0200 Subject: [PATCH 17/92] Rename 07-access-controls.md to 08-access-controls.md --- .../{07-access-controls.md => 08-access-controls.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{07-access-controls.md => 08-access-controls.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/07-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/07-access-controls.md rename to docs/en/04-design/02-web-app-checklist/08-access-controls.md From fdd8483e8d144dfc935cf9331e8be007d9014ba6 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:49:26 +0200 Subject: [PATCH 18/92] Rename 08-protect-data.md to 09-protect-data.md --- .../{08-protect-data.md => 09-protect-data.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{08-protect-data.md => 09-protect-data.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/08-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/08-protect-data.md rename to docs/en/04-design/02-web-app-checklist/09-protect-data.md From c92c42f0a28b848a1dfe438e29dbfdcbb2fabf62 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:51:00 +0200 Subject: [PATCH 19/92] Rename 09-logging-monitoring.md to 10-logging-monitoring.md --- .../{09-logging-monitoring.md => 10-logging-monitoring.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{09-logging-monitoring.md => 10-logging-monitoring.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md b/docs/en/04-design/02-web-app-checklist/10-logging-monitoring.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md rename to docs/en/04-design/02-web-app-checklist/10-logging-monitoring.md From 0cc7dd3c9115b40bf468aa288a657dc1440ec7fc Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 22:51:29 +0200 Subject: [PATCH 20/92] Rename 10-handle-errors-exceptions.md to 11-handle-errors-exceptions.md --- ...handle-errors-exceptions.md => 11-handle-errors-exceptions.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{10-handle-errors-exceptions.md => 11-handle-errors-exceptions.md} (100%) 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/11-handle-errors-exceptions.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md rename to docs/en/04-design/02-web-app-checklist/11-handle-errors-exceptions.md From 3fcae42f5bbe8382267b8f515045ba61bb76bd80 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 23:11:32 +0200 Subject: [PATCH 21/92] Add C10 from proactive controls --- .../04-design/02-web-app-checklist/04-encode-escape-data.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) 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..c232ce66 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,7 @@ 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. @@ -40,7 +40,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 From 59daf169f8923c569211b1439776461cca04d94a Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 23:14:15 +0200 Subject: [PATCH 22/92] Update 04-encode-escape-data.md --- docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 c232ce66..c5f3ba83 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 @@ -15,7 +15,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 From 95eeb928764c20dd02619a52759f76305915e8ec Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 23:18:15 +0200 Subject: [PATCH 23/92] Remove duplicate bullet point thart belongs to the encoding list --- docs/en/04-design/02-web-app-checklist/05-validate-inputs.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) 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..10f5a924 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 From b08abd129df9167496e08ccb42f1f9783e6850c6 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 23:31:13 +0200 Subject: [PATCH 24/92] Update 01-address-security-from-the-start.md --- .../02-web-app-checklist/01-address-security-from-the-start.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md index 25ac5b4c..b13494cc 100644 --- a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md +++ b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md @@ -4,7 +4,7 @@ Refer to proactive control [C4: Address Security form the Start][control4] and i 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. Access Control Design 1. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible From 0dfdf09ac3d92ad21fca37953aeded872dc5d384 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 23:36:47 +0200 Subject: [PATCH 25/92] Move bullet point from 01-address-security-from-the-start.md --- docs/en/04-design/02-web-app-checklist/08-access-controls.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md index 6348f6fc..90fb07d6 100644 --- a/docs/en/04-design/02-web-app-checklist/08-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/08-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 +#### 2. Authorization 1. Design access control / authorization thoroughly up-front 2. Force all requests to go through access control checks unless public @@ -18,7 +18,7 @@ and use the list below as suggestions for a checklist that has been tailored for 7. Access Control criteria and/or processes not testable through automated tests should be documented so that they can be manually tested -#### 2. Access control +#### 3. Access control 1. Enforce authorization controls on every request 2. Use only trusted system objects for making access authorization decisions @@ -42,6 +42,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 16. Enforce application logic flows to comply with business rules +17. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible #### References From 4bd2951422eb5fc863d0efc1333193564e1a136f Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 23:37:44 +0200 Subject: [PATCH 26/92] Move bullet point to 08-access-controls.md --- .../01-address-security-from-the-start.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md index b13494cc..2c92b130 100644 --- a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md +++ b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md @@ -4,10 +4,6 @@ Refer to proactive control [C4: Address Security form the Start][control4] and i 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. Access Control Design - -1. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible - #### 2. Cryptographic practices 1. Use peer reviewed and open solution cryptographic modules From 79e724b2a8e4e46bd4211a0b0a738e562d2b4918 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 14 Jul 2025 23:45:39 +0200 Subject: [PATCH 27/92] Remove bullet point that was meant for the access control list and that has become wrongly added to the authentication list --- .../07-digital-identity.md | 43 +++++++++---------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md index ff4a2e9b..bc130f7b 100644 --- a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md @@ -8,33 +8,32 @@ and use the list below as suggestions for a checklist that has been tailored for #### 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 -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 -6. If using third party code for authentication inspect the code carefully +1. Require authentication for all pages and resources, except those specifically intended to be public +2. All authentication controls must be enforced on a trusted system +3. All authentication controls should fail securely +4. Establish and utilize standard, tested, authentication services whenever possible +5. If using third party code for authentication inspect the code carefully to ensure it is not affected by any malicious code -7. Use a centralized implementation for all authentication controls -8. Segregate authentication logic from the resource being requested and +6. Use a centralized implementation for all authentication controls +7. Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control -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 -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 -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. +8. Administrative and account management must be at least as secure as the primary authentication mechanism +9. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts +10. Re-authenticate users prior to performing critical operations +11. Enforce account disabling after an established number of invalid login attempts +12. Utilize authentication for connections to external systems that involve sensitive information or functions +13. Authentication credentials for accessing services external to the application should be stored in a secure store +14. Use only HTTP POST requests to transmit authentication credentials +15. Force all requests to go through access control checks unless public +16. Do not hard code access controls that are role based +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 From b59eca6d332d2ada81665596c793ed621fb20455 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 00:04:55 +0200 Subject: [PATCH 28/92] Update 09-protect-data.md --- .../02-web-app-checklist/09-protect-data.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index c8911400..719773fc 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -25,6 +25,21 @@ and use the list below as suggestions for a checklist that has been tailored for 15. 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. 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 + #### 2. Memory management 1. Explicitly initialize all variables and data stores From 6b32d33c197bb4b4c4cb3cc3fd41b359f0dcfce4 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 00:09:57 +0200 Subject: [PATCH 29/92] Add the practice --- .../02-web-app-checklist/09-protect-data.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index 719773fc..a29d5b03 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -6,7 +6,22 @@ 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. 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 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 + +#### 2. Data protection 1. Classify data according to the level of sensitivity 2. Implement appropriate access controls for sensitive data @@ -25,22 +40,7 @@ and use the list below as suggestions for a checklist that has been tailored for 15. 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. 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 - -#### 2. Memory management +#### 3. Memory management 1. Explicitly initialize all variables and data stores 2. Check that any buffers are as large as specified @@ -52,7 +52,7 @@ 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 +#### 4. Encrypting 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 From 6a00985bf7ac71d6864bdfaa07dee77eaef768e2 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 00:11:29 +0200 Subject: [PATCH 30/92] Move cryptographic practices to data protection --- .../01-address-security-from-the-start.md | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md index 2c92b130..18308a67 100644 --- a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md +++ b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md @@ -4,21 +4,6 @@ Refer to proactive control [C4: Address Security form the Start][control4] and i 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. -#### 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 From b698423ed68ff0a91a357debc566ab3e2c9a64c4 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 11:54:15 +0200 Subject: [PATCH 31/92] Change headers to conform to Top 10 Proactive Controls --- .../02-web-app-checklist/09-protect-data.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index a29d5b03..0cf9daa2 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -25,8 +25,6 @@ and use the list below as suggestions for a checklist that has been tailored for 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 @@ -52,12 +50,17 @@ 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.) -#### 4. Encrypting 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 +#### 4. Protct Data at Rest + +#### 5. Protct Data in Transit + +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. Utilize a single standard TLS implementation with (preferably the latest) secure version of TLS +6. Ensure the TLS connections are configured appropriately to validate certificates received before communicating and checking revocation status #### References From fe13df1ea3ea77cfb70c0982e8c59e61c6d0a395 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 12:07:28 +0200 Subject: [PATCH 32/92] Move data protection at rest bullet points under the appropriate header --- .../02-web-app-checklist/09-protect-data.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index 0cf9daa2..af988dab 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -20,22 +20,18 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +12. Store application-level secrets in a secrets vault +13. Check that secrets are not stored in code, config files or environment variables #### 2. Data protection 1. Classify data according to the level of sensitivity 2. Implement appropriate access controls for sensitive data 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 +6. Implement least privilege, restricting access to functionality, data and system information +7. Do not include sensitive information in the URL or query string, such as an API key or session token +8. Disable client side caching on pages containing sensitive information (e.g. Cache-Control: no-store) +9. 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. Memory management @@ -50,9 +46,13 @@ 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.) - #### 4. Protct 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. Protct Data in Transit 1. Encrypt data in transit From f7291403123cede5563c351c67ded749b4303e75 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Wed, 16 Jul 2025 13:01:17 +0200 Subject: [PATCH 33/92] Move file validation from address-security-from-the-start --- .../02-web-app-checklist/05-validate-inputs.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) 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 10f5a924..9935a439 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 @@ -40,6 +40,19 @@ 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] From 91866107d93814337cbc46f09a760df53bb49d0b Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:35:54 +0200 Subject: [PATCH 34/92] Move authentication related issue to the authentication list. --- .../07-digital-identity.md | 41 ++++++++++--------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md index bc130f7b..2ce99106 100644 --- a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md @@ -9,31 +9,32 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Authentication 1. Require authentication for all pages and resources, except those specifically intended to be public -2. All authentication controls must be enforced on a trusted system -3. All authentication controls should fail securely -4. Establish and utilize standard, tested, authentication services whenever possible -5. If using third party code for authentication inspect the code carefully +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 +6. If using third party code for authentication inspect the code carefully to ensure it is not affected by any malicious code -6. Use a centralized implementation for all authentication controls -7. Segregate authentication logic from the resource being requested and +7. Use a centralized implementation for all authentication controls +8. Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control -8. Administrative and account management must be at least as secure as the primary authentication mechanism -9. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts -10. Re-authenticate users prior to performing critical operations -11. Enforce account disabling after an established number of invalid login attempts -12. Utilize authentication for connections to external systems that involve sensitive information or functions -13. Authentication credentials for accessing services external to the application should be stored in a secure store -14. Use only HTTP POST requests to transmit authentication credentials -15. Force all requests to go through access control checks unless public -16. Do not hard code access controls that are role based -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. +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 +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 +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. E.g. Through giving different textual response or HTTP response codes -20. Authentication failure responses should not give away the existent of user accounts by allowing the response time to +21. 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 +22. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks #### 2. Passwords From b6bff8aaade129759a78ada8493e674ac103bd76 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:38:32 +0200 Subject: [PATCH 35/92] Move from file management to secure by default --- .../03-secure-by-default-configurations.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md index 38810799..f43f02c6 100644 --- a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md +++ b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md @@ -15,13 +15,14 @@ and use the lists below as suggestions for a checklist that has been tailored fo 5. Isolate development environments from production and provide access only to authorized development and test groups 6. Implement a software change control system to manage and record changes to the code both in development and production 7. Turn off directory listings -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 -14. Restrict access to files or other resources, including those outside the application's direct control using an allow list or the equivalent thereof. +8. Do not save files in the same web context as the application +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. [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 From 71b6a730315113e4994d6346582999a52fa01998 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:41:48 +0200 Subject: [PATCH 36/92] Move from address security from the start --- .../03-secure-by-default-configurations.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md index f43f02c6..610cad4b 100644 --- a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md +++ b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md @@ -16,13 +16,14 @@ and use the lists below as suggestions for a checklist that has been tailored fo 6. Implement a software change control system to manage and record changes to the code both in development and production 7. Turn off directory listings 8. Do not save files in the same web context as the application -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. +9. Turn off execution privileges on file upload directories +10. 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 +11. 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 +12. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks unless implemented to confuse an attacker +13. 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 +14. 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 +15. 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 +16. Restrict access to files or other resources, including those outside the application's direct control using an allow list or the equivalent thereof. [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 From 467b8b139a2e177e32393d5a88d7ba7b678d7c6f Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:44:09 +0200 Subject: [PATCH 37/92] move from secure from the start --- .../03-secure-by-default-configurations.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md index 610cad4b..f3024baf 100644 --- a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md +++ b/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md @@ -17,13 +17,14 @@ and use the lists below as suggestions for a checklist that has been tailored fo 7. Turn off directory listings 8. Do not save files in the same web context as the application 9. Turn off execution privileges on file upload directories -10. 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 -11. 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 -12. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks unless implemented to confuse an attacker -13. 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 -14. 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 -15. 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 -16. Restrict access to files or other resources, including those outside the application's direct control using an allow list or the equivalent thereof. +10. Ensure application files and resources are read-only +11. 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 +12. 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 +13. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks unless implemented to confuse an attacker +14. 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 +15. 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 +16. 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 +17. Restrict access to files or other resources, including those outside the application's direct control using an allow list or the equivalent thereof. [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 From c3c562240a77193cc2df5296988e446e414f818b Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:46:24 +0200 Subject: [PATCH 38/92] No longer of interest as the new chapter now is called secure by default --- .../01-address-security-from-the-start.md | 40 ------------------- 1 file changed, 40 deletions(-) delete mode 100644 docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md diff --git a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md b/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md deleted file mode 100644 index 18308a67..00000000 --- a/docs/en/04-design/02-web-app-checklist/01-address-security-from-the-start.md +++ /dev/null @@ -1,40 +0,0 @@ -When designing a new application, creating a secure architecture prevents vulnerabilities before they even become part of the application. This prevents costly repairs and repudiation problems. - -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. - -#### 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/ From 217034ff7300be0436b46a188d6f81fb8a9dd7f8 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:48:46 +0200 Subject: [PATCH 39/92] Rename 03-secure-by-default-configurations.md to 01-secure-by-default-configurations.md --- ...t-configurations.md => 01-secure-by-default-configurations.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{03-secure-by-default-configurations.md => 01-secure-by-default-configurations.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/01-secure-by-default-configurations.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/03-secure-by-default-configurations.md rename to docs/en/04-design/02-web-app-checklist/01-secure-by-default-configurations.md From b814db8c1cd55bfbadfc18b9cc0918c67127ad85 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:53:47 +0200 Subject: [PATCH 40/92] Update and rename 01-secure-by-default-configurations.md to 01-secure-by-default.md --- ...ure-by-default-configurations.md => 01-secure-by-default.md} | 2 ++ 1 file changed, 2 insertions(+) rename docs/en/04-design/02-web-app-checklist/{01-secure-by-default-configurations.md => 01-secure-by-default.md} (91%) diff --git a/docs/en/04-design/02-web-app-checklist/01-secure-by-default-configurations.md b/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md similarity index 91% rename from docs/en/04-design/02-web-app-checklist/01-secure-by-default-configurations.md rename to docs/en/04-design/02-web-app-checklist/01-secure-by-default.md index f3024baf..1b2685a8 100644 --- a/docs/en/04-design/02-web-app-checklist/01-secure-by-default-configurations.md +++ b/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md @@ -28,3 +28,5 @@ and use the lists below as suggestions for a checklist that has been tailored fo [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 +[edit060204]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md +[issue060204]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/01-secure-by-default From 68fd8c8b3f03bdfaedb5421b0435d5ed0e427515 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 12:55:34 +0200 Subject: [PATCH 41/92] Update and rename 04-encode-escape-data.md to 03-encode-escape-data.md --- .../{04-encode-escape-data.md => 03-encode-escape-data.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename docs/en/04-design/02-web-app-checklist/{04-encode-escape-data.md => 03-encode-escape-data.md} (96%) 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/03-encode-escape-data.md similarity index 96% rename from docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md rename to docs/en/04-design/02-web-app-checklist/03-encode-escape-data.md index c5f3ba83..ecd49010 100644 --- a/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md +++ b/docs/en/04-design/02-web-app-checklist/03-encode-escape-data.md @@ -43,8 +43,8 @@ then [submit an issue][issue060204] or [edit on GitHub][edit060204]. [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 +[edit060204]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/03-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 -[issue060204]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/04-encode-escape-data +[issue060204]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/03-encode-escape-data [proactive10]: https://top10proactive.owasp.org/ From a14aaa366a61c63fda76639873cd476b5c98e836 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 13:32:51 +0200 Subject: [PATCH 42/92] Rename 06-secure-database-access.md to 03-secure-database-access.md --- ...{06-secure-database-access.md => 03-secure-database-access.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{06-secure-database-access.md => 03-secure-database-access.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/06-secure-database-access.md b/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/06-secure-database-access.md rename to docs/en/04-design/02-web-app-checklist/03-secure-database-access.md From 1f9ffe019a51812484f758cbee6b70ecb3694695 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 13:34:31 +0200 Subject: [PATCH 43/92] Update and rename 03-encode-escape-data.md to 04-encode-escape-data.md --- .../{03-encode-escape-data.md => 04-encode-escape-data.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename docs/en/04-design/02-web-app-checklist/{03-encode-escape-data.md => 04-encode-escape-data.md} (96%) diff --git a/docs/en/04-design/02-web-app-checklist/03-encode-escape-data.md b/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md similarity index 96% rename from docs/en/04-design/02-web-app-checklist/03-encode-escape-data.md rename to docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md index ecd49010..c5f3ba83 100644 --- a/docs/en/04-design/02-web-app-checklist/03-encode-escape-data.md +++ b/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md @@ -43,8 +43,8 @@ then [submit an issue][issue060204] or [edit on GitHub][edit060204]. [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/03-encode-escape-data.md +[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 -[issue060204]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/03-encode-escape-data +[issue060204]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/04-encode-escape-data [proactive10]: https://top10proactive.owasp.org/ From a40c57cd62324ef3d7bd528d8c1b48c514110c30 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 13:36:02 +0200 Subject: [PATCH 44/92] Rename 02-keep-your-components-secure.md to 02-frameworks-libraries.md --- ...-keep-your-components-secure.md => 02-frameworks-libraries.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{02-keep-your-components-secure.md => 02-frameworks-libraries.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md b/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/02-keep-your-components-secure.md rename to docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md From 60c02f53564fa2847fcba837bc515efb875eef3a Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 13:39:14 +0200 Subject: [PATCH 45/92] Add directions for editing --- .../04-design/02-web-app-checklist/01-secure-by-default.md | 5 +++++ 1 file changed, 5 insertions(+) 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 1b2685a8..dcf6deb2 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 @@ -26,6 +26,11 @@ and use the lists below as suggestions for a checklist that has been tailored fo 16. 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 17. Restrict access to files or other resources, including those outside the application's direct control using an allow list or the equivalent thereof. +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060202] or [edit on GitHub][edit060202]. + [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 [edit060204]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md From a04dfc5dcfb390d76a67db14388c58140f596ad0 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 13:41:01 +0200 Subject: [PATCH 46/92] Fix link --- .../04-design/02-web-app-checklist/01-secure-by-default.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 dcf6deb2..539f1e1b 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 @@ -29,9 +29,9 @@ and use the lists below as suggestions for a checklist that has been tailored fo ---- The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue060202] or [edit on GitHub][edit060202]. +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 -[edit060204]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md -[issue060204]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/02-web-app-checklist/01-secure-by-default +[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 From aa0667b7555433cbb3559fb6e2f7378f932cfed0 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 14:08:07 +0200 Subject: [PATCH 47/92] Sort and create the file management header under secure by default --- .../01-secure-by-default.md | 25 +++++++++++-------- 1 file changed, 14 insertions(+), 11 deletions(-) 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 539f1e1b..cd6fc961 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 @@ -14,17 +14,20 @@ and use the lists below as suggestions for a checklist that has been tailored fo 4. The security configuration store for the application should be available in human readable form to support auditing 5. Isolate development environments from production and provide access only to authorized development and test groups 6. Implement a software change control system to manage and record changes to the code both in development and production -7. Turn off directory listings -8. Do not save files in the same web context as the application -9. Turn off execution privileges on file upload directories -10. Ensure application files and resources are read-only -11. 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 -12. 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 -13. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks unless implemented to confuse an attacker -14. 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 -15. 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 -16. 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 -17. Restrict access to files or other resources, including those outside the application's direct control using an allow list or the equivalent thereof. +7. 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 +8. 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 +9. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks unless implemented to confuse an attacker +10. 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 +11. 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 +12. 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. ---- From 26a08e3d3167748b90b70d032da086b53554f8da Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 14:09:20 +0200 Subject: [PATCH 48/92] create header --- docs/en/04-design/02-web-app-checklist/01-secure-by-default.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 cd6fc961..8718c59f 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 @@ -21,7 +21,7 @@ and use the lists below as suggestions for a checklist that has been tailored fo 11. 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 12. 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 1. Turn off directory listings 2. Do not save files in the same web context as the application From 8bbdc12c183978b790e860f02f1171b7205b6cc7 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 14:58:34 +0200 Subject: [PATCH 49/92] Add JIT --- .../08-access-controls.md | 31 ++++++++++--------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md index 90fb07d6..fff3c89a 100644 --- a/docs/en/04-design/02-web-app-checklist/08-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/08-access-controls.md @@ -11,11 +11,11 @@ and use the list below as suggestions for a checklist that has been tailored for 2. Force all requests to go through access control checks unless public 3. Deny by default; if a request is not specifically allowed then it is denied 4. Apply least privilege, providing the least access as is necessary -5. Log all authorization events -6. Create unit and integration test to document and verify an application's business rules, data types and access +6. Log all authorization events +7. Create unit and integration test to document and verify an application's business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled for restricting 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 +8. Access Control criteria and/or processes not testable through automated tests should be documented so that they can be manually tested #### 3. Access control @@ -25,24 +25,25 @@ and use the list below as suggestions for a checklist that has been tailored for 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, +6. Enforce JIT (Just-In-Time) access management. +7. Segregate privileged logic from other application code +8. 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 +9. If long authenticated sessions are allowed, periodically re-validate a user's authorization +10. Implement account auditing and enforce the disabling of unused accounts +11. The application must support termination of sessions when authorization ceases +12. Restrict function-level access to consumers with explicit permissions +13. 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 +14. 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 +15. 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 +16. 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 -17. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +17. Enforce application logic flows to comply with business rules +18. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible #### References From 3ac0e80887c4381ed5b63bd9de86b0f9cddafbf8 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 15:15:34 +0200 Subject: [PATCH 50/92] Add cloud security --- .../en/04-design/02-web-app-checklist/01-secure-by-default.md | 4 ++++ 1 file changed, 4 insertions(+) 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 8718c59f..ad0509b1 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 @@ -29,6 +29,10 @@ and use the lists below as suggestions for a checklist that has been tailored fo 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. Use security vetted container images that is scanned for package and component vulnerabilities and pulled from a private container registry + ---- The OWASP Developer Guide is a community effort; if there is something that needs changing From 7763ca6684b8ef99ffbfc504288c5bbfedd6354b Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 15:46:26 +0200 Subject: [PATCH 51/92] Add point about infra and policy as code. --- docs/en/04-design/02-web-app-checklist/01-secure-by-default.md | 2 ++ 1 file changed, 2 insertions(+) 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 ad0509b1..5145f0c0 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 @@ -32,6 +32,8 @@ and use the lists below as suggestions for a checklist that has been tailored fo #### 3. Cloud security 1. Use security vetted container images that is scanned for package and component vulnerabilities and pulled from a private container registry +2. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on-premises infrastructure +3. Utilize Policy-as-Code to enforce policies including privilege assignments ---- From 922342f08a486d44335ebb7c93eb3caad7077a4f Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 15:48:35 +0200 Subject: [PATCH 52/92] Add point about infra as code --- .../01-secure-by-default.md | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) 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 5145f0c0..a5a62494 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 @@ -9,17 +9,18 @@ and use the lists below as suggestions for a checklist that has been tailored fo #### 1. System configuration 1. Restrict applications, processes and service accounts to the least privileges possible -2. Remove all unnecessary functionality and files -3. Remove test code or any functionality not intended for production, prior to deployment -4. The security configuration store for the application should be available in human readable form to support auditing -5. Isolate development environments from production and provide access only to authorized development and test groups -6. Implement a software change control system to manage and record changes to the code both in development and production -7. 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 -8. 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 -9. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks unless implemented to confuse an attacker -10. 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 -11. 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 -12. 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. Code which defines the infrastructure should follow the principle of least privilege. +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. 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 From ba7f71a82b74542feff42fa92651d563efed3f26 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 15:51:18 +0200 Subject: [PATCH 53/92] Add point from proactive controls --- docs/en/04-design/02-web-app-checklist/01-secure-by-default.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 a5a62494..f3cbfc77 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 @@ -10,7 +10,7 @@ and use the lists below as suggestions for a checklist that has been tailored fo 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 and files +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 From 05d37ef07eb3aced4f6d16a5676e571be4cb9e1b Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 15:54:01 +0200 Subject: [PATCH 54/92] Move to validation --- .../02-web-app-checklist/02-frameworks-libraries.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) 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 2620c5db..f1702099 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 @@ -44,10 +44,9 @@ In addition consider the following extra checks for frameworks and libraries. 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 +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 14. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures #### References From fab8e798053605f908fe925fd9be60ba0b90dbae Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 15:56:06 +0200 Subject: [PATCH 55/92] Move feom framework and libraryies --- docs/en/04-design/02-web-app-checklist/05-validate-inputs.md | 1 + 1 file changed, 1 insertion(+) 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 9935a439..7e943ff7 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 @@ -28,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 From 88f8c4a745f2f66dbe306e5dbcd0716f9797c1f0 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 16:12:45 +0200 Subject: [PATCH 56/92] Add additional points about scanning for vulnerabilities --- .../04-design/02-web-app-checklist/02-frameworks-libraries.md | 2 ++ 1 file changed, 2 insertions(+) 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 f1702099..96e1c2b3 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 @@ -48,6 +48,8 @@ In addition consider the following extra checks for frameworks and libraries. 11. Restrict users from generating new code or altering existing code 12. Implement safe updates using encrypted channels 14. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures +15. Use your SBOMs together with periodic or continuous monitoring tools such as OWASP dependency-track to automatically detect well-known publicly disclosed vulnerabilities. +16. integrate SCA tools in early stages of software development #### References From 819da0fc2bc83d6b0d8b40a11311e263e64d73f1 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 16:14:10 +0200 Subject: [PATCH 57/92] Shorten sentence --- .../04-design/02-web-app-checklist/02-frameworks-libraries.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 96e1c2b3..8a69ce1d 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 @@ -48,7 +48,7 @@ In addition consider the following extra checks for frameworks and libraries. 11. Restrict users from generating new code or altering existing code 12. Implement safe updates using encrypted channels 14. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures -15. Use your SBOMs together with periodic or continuous monitoring tools such as OWASP dependency-track to automatically detect well-known publicly disclosed vulnerabilities. +15. Use your SBOMs together with periodic or SCA tools to automatically detect well-known publicly disclosed vulnerabilities. 16. integrate SCA tools in early stages of software development #### References From fc2141670c68f4edd2303dedfd20cedb94fb4567 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 16:39:10 +0200 Subject: [PATCH 58/92] Move to access control --- .../02-web-app-checklist/07-digital-identity.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md index 2ce99106..b8632624 100644 --- a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md @@ -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 From b582cb8419ed2076d36b8f9e94e830367bfb6b83 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 16:40:54 +0200 Subject: [PATCH 59/92] Move from digital identities --- docs/en/04-design/02-web-app-checklist/08-access-controls.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md index fff3c89a..22e46ccb 100644 --- a/docs/en/04-design/02-web-app-checklist/08-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/08-access-controls.md @@ -44,6 +44,7 @@ and use the list below as suggestions for a checklist that has been tailored for that they allow for business functionality and rules to be compromised 17. Enforce application logic flows to comply with business rules 18. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +19. Do not hard code access controls that are role based #### References From 7b45260b6ba8479ae21fd0edf7c41aa43cf14013 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 17:04:48 +0200 Subject: [PATCH 60/92] Add point related to session management --- .../02-web-app-checklist/07-digital-identity.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md index b8632624..c7baae28 100644 --- a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/07-digital-identity.md @@ -81,11 +81,14 @@ 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 From aed3fb9fb905b870450225cfb37e863fbb994b12 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 20:00:42 +0200 Subject: [PATCH 61/92] Move JIT to secure by default --- .../08-access-controls.md | 27 +++++++++---------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md index 22e46ccb..05198495 100644 --- a/docs/en/04-design/02-web-app-checklist/08-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/08-access-controls.md @@ -25,26 +25,25 @@ and use the list below as suggestions for a checklist that has been tailored for 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. Enforce JIT (Just-In-Time) access management. -7. Segregate privileged logic from other application code -8. Limit the number of transactions a single user or device can perform in a given period of time, +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, low enough to deter automated attacks but above the actual business requirement -9. If long authenticated sessions are allowed, periodically re-validate a user's authorization -10. Implement account auditing and enforce the disabling of unused accounts -11. The application must support termination of sessions when authorization ceases -12. Restrict function-level access to consumers with explicit permissions -13. Restrict direct object references to only authorized users with explicit permissions to specific data items +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 to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA) -14. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken +13. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA) -15. Restrict access security-relevant configuration information to only authorized users who have been allowed access through +14. 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 -16. Server side implementation and presentation layer representations of access control rules should not differ in such a way +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 -17. Enforce application logic flows to comply with business rules -18. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible -19. Do not hard code access controls that are role based +16. Enforce application logic flows to comply with business rules +17. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +18. Do not hard code access controls that are role based #### References From 7345b4deeeb4ec468c3676e62a05c02ccba1becf Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 20:01:21 +0200 Subject: [PATCH 62/92] Add jit --- .../04-design/02-web-app-checklist/01-secure-by-default.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) 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 f3cbfc77..57139d80 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 @@ -32,9 +32,10 @@ and use the lists below as suggestions for a checklist that has been tailored fo #### 3. Cloud security -1. Use security vetted container images that is scanned for package and component vulnerabilities and pulled from a private container registry -2. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on-premises infrastructure -3. Utilize Policy-as-Code to enforce policies including privilege assignments +1. 6. 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 ---- From 5af705b625253701ece6607477a25471832035ba Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 20:14:53 +0200 Subject: [PATCH 63/92] Add requirements for new accounts --- .../08-access-controls.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md index 05198495..fed6e708 100644 --- a/docs/en/04-design/02-web-app-checklist/08-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/08-access-controls.md @@ -30,20 +30,21 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +10. A new account should have minimal or no access by default +11. The application must support termination of sessions when authorization ceases +12. Restrict function-level access to consumers with explicit permissions +13. 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 +14. 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 +15. 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 +16. 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 -17. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible -18. Do not hard code access controls that are role based +17. Enforce application logic flows to comply with business rules +18. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +19. Do not hard code access controls that are role based #### References From 8dcd451a4521c647f131c58ef0bce04f7c796635 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 20:19:02 +0200 Subject: [PATCH 64/92] Add JIT requirement --- .../08-access-controls.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md index fed6e708..487dd803 100644 --- a/docs/en/04-design/02-web-app-checklist/08-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/08-access-controls.md @@ -31,20 +31,21 @@ and use the list below as suggestions for a checklist that has been tailored for 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. A new account should have minimal or no access by default -11. The application must support termination of sessions when authorization ceases -12. Restrict function-level access to consumers with explicit permissions -13. Restrict direct object references to only authorized users with explicit permissions to specific data items +11. For highly sensitive accounts implement Just in Time (JIT), Just Enough Access (JEA) management and avoid the use of admin accounts with global access +12. The application must support termination of sessions when authorization ceases +13. Restrict function-level access to consumers with explicit permissions +14. 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) -14. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken +15. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA) -15. Restrict access security-relevant configuration information to only authorized users who have been allowed access through +16. 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 -16. Server side implementation and presentation layer representations of access control rules should not differ in such a way +17. 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 -17. Enforce application logic flows to comply with business rules -18. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible -19. Do not hard code access controls that are role based +18. Enforce application logic flows to comply with business rules +19. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +20. Do not hard code access controls that are role based #### References From 094078d9e1f5b3139d365d43d8a8284421cb200e Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 20:42:58 +0200 Subject: [PATCH 65/92] Separate the access control list into implementing and management --- .../08-access-controls.md | 45 +++++++++---------- 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/08-access-controls.md index 487dd803..496178a2 100644 --- a/docs/en/04-design/02-web-app-checklist/08-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/08-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. -#### 2. 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,35 +17,34 @@ 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 8. Access Control criteria and/or processes not testable through automated tests should be documented so that they can be manually tested +9. Use only trusted system objects for making access authorization decisions +10. Use a single site-wide component to check authorization +11. Access control should fail securely +12. Deny all access if the application cannot access its security configuration information +13. Segregate privileged logic from other application code +14. Do not hard code access controls that are role based +15. Enforce application logic flows to comply with business rules +16. 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 -#### 3. 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. A new account should have minimal or no access by default -11. For highly sensitive accounts implement Just in Time (JIT), Just Enough Access (JEA) management and avoid the use of admin accounts with global access -12. The application must support termination of sessions when authorization ceases -13. Restrict function-level access to consumers with explicit permissions -14. 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) -15. 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) -16. 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 -17. 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 -18. Enforce application logic flows to comply with business rules -19. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible -20. Do not hard code access controls that are role based +11. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible #### References From 0acfa01027aa8cbec653159b3c58dabae3490c79 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 20:57:59 +0200 Subject: [PATCH 66/92] Add points from proactive controls --- docs/en/04-design/02-web-app-checklist/09-protect-data.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index af988dab..f1ae0ed4 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -22,6 +22,7 @@ and use the list below as suggestions for a checklist that has been tailored for 11. Build application features to handle a key rotation 12. Store application-level secrets in a secrets vault 13. Check that secrets are not stored in code, config files or environment variables +14. Don't implement your own cryptographic protocols or routines. Use existing security vetted library and frameworks #### 2. Data protection From b9d704f697e8820ba31f59b25a77bc3b72cc257e Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:02:52 +0200 Subject: [PATCH 67/92] Add point about secret management --- docs/en/04-design/02-web-app-checklist/09-protect-data.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index f1ae0ed4..0e40760a 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -22,7 +22,8 @@ and use the list below as suggestions for a checklist that has been tailored for 11. Build application features to handle a key rotation 12. Store application-level secrets in a secrets vault 13. Check that secrets are not stored in code, config files or environment variables -14. Don't implement your own cryptographic protocols or routines. Use existing security vetted library and frameworks +14. Scan code repositories to detect accidentally added secrets and credentials +15. Don't implement your own cryptographic protocols or routines. Use existing security vetted library and frameworks #### 2. Data protection From b7aea9277b566929d1cb3deaa79807355bb3c92f Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:16:50 +0200 Subject: [PATCH 68/92] Add secret management list --- .../02-web-app-checklist/09-protect-data.md | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index 0e40760a..0a8e0257 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -13,17 +13,9 @@ and use the list below as suggestions for a checklist that has been tailored for 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 -12. Store application-level secrets in a secrets vault -13. Check that secrets are not stored in code, config files or environment variables -14. Scan code repositories to detect accidentally added secrets and credentials -15. Don't implement your own cryptographic protocols or routines. Use existing security vetted library and frameworks +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 @@ -36,7 +28,17 @@ and use the list below as suggestions for a checklist that has been tailored for 9. 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. 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 +8. Scan code repositories to detect accidentally added secrets and credentials + +#### 4. Memory management 1. Explicitly initialize all variables and data stores 2. Check that any buffers are as large as specified @@ -48,7 +50,7 @@ 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.) -#### 4. Protct Data at Rest +#### 5. Protct 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 From 05ef6eac08f1d34bbef262d8087d96520e7384c4 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:21:57 +0200 Subject: [PATCH 69/92] Add point about logging --- docs/en/04-design/02-web-app-checklist/09-protect-data.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index 0a8e0257..23f4795f 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -37,6 +37,7 @@ and use the list below as suggestions for a checklist that has been tailored for 5. Build application features to handle a secret key rotation 6. Ensure that secrets are not stored in code, config files or environment variables 8. Scan code repositories to detect accidentally added secrets and credentials +9. Log all authorized access to a secret key for forensic purposes #### 4. Memory management From 97bde526a657479774b1a7d0d3c0a2c9da778569 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:26:45 +0200 Subject: [PATCH 70/92] Add point about turning off older protocols --- docs/en/04-design/02-web-app-checklist/09-protect-data.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index 23f4795f..8a818c15 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -64,8 +64,9 @@ and use the list below as suggestions for a checklist that has been tailored for 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. Utilize a single standard TLS implementation with (preferably the latest) secure version of TLS -6. Ensure the TLS connections are configured appropriately to validate certificates received before communicating and +5. Turn off older protocols to avoid protocol downgrade attacks +6. Utilize a single standard TLS implementation with (preferably the latest) secure version of TLS +7. Ensure the TLS connections are configured appropriately to validate certificates received before communicating and checking revocation status #### References From 8fbf2ebc798fa0196e8727897c87d4108f6f8500 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:30:59 +0200 Subject: [PATCH 71/92] Add point about not serving http --- docs/en/04-design/02-web-app-checklist/09-protect-data.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index 8a818c15..20b2e441 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -12,7 +12,7 @@ and use the list below as suggestions for a checklist that has been tailored for 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 + 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 @@ -65,8 +65,9 @@ and use the list below as suggestions for a checklist that has been tailored for 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. Utilize a single standard TLS implementation with (preferably the latest) secure version of TLS -7. Ensure the TLS connections are configured appropriately to validate certificates received before communicating and +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 #### References From 4b5f8cef9f868a8843ae6eb1f69bfd8c66e66a15 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:36:51 +0200 Subject: [PATCH 72/92] Add point about the use of client side secure transmission features --- docs/en/04-design/02-web-app-checklist/09-protect-data.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/09-protect-data.md index 20b2e441..8b775785 100644 --- a/docs/en/04-design/02-web-app-checklist/09-protect-data.md +++ b/docs/en/04-design/02-web-app-checklist/09-protect-data.md @@ -69,6 +69,9 @@ and use the list below as suggestions for a checklist that has been tailored for 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 ef4592b5a1971b3f4db3944ae58f0fd0f8d2f432 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:38:56 +0200 Subject: [PATCH 73/92] Rename 07-digital-identity.md to 06-digital-identity.md --- .../{07-digital-identity.md => 06-digital-identity.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{07-digital-identity.md => 06-digital-identity.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/07-digital-identity.md b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/07-digital-identity.md rename to docs/en/04-design/02-web-app-checklist/06-digital-identity.md From 5d71336f8d5e7e6cc2ebb50a30ac371d4d39cc2d Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:39:50 +0200 Subject: [PATCH 74/92] Rename 08-access-controls.md to 07-access-controls.md --- .../{08-access-controls.md => 07-access-controls.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{08-access-controls.md => 07-access-controls.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/08-access-controls.md b/docs/en/04-design/02-web-app-checklist/07-access-controls.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/08-access-controls.md rename to docs/en/04-design/02-web-app-checklist/07-access-controls.md From 38ff9ac6021463bd94bfc8467875ceb985a2338e Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:40:16 +0200 Subject: [PATCH 75/92] Rename 09-protect-data.md to 08-protect-data.md --- .../{09-protect-data.md => 08-protect-data.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{09-protect-data.md => 08-protect-data.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/09-protect-data.md b/docs/en/04-design/02-web-app-checklist/08-protect-data.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/09-protect-data.md rename to docs/en/04-design/02-web-app-checklist/08-protect-data.md From 5ddac7ddd574435f06e98bbad0923c8c58bc6421 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:40:42 +0200 Subject: [PATCH 76/92] Rename 10-logging-monitoring.md to 09-logging-monitoring.md --- .../{10-logging-monitoring.md => 09-logging-monitoring.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{10-logging-monitoring.md => 09-logging-monitoring.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/10-logging-monitoring.md b/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/10-logging-monitoring.md rename to docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md From 64151e6dcbc75990367f96ab1defca3a4ed8c655 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 21:41:08 +0200 Subject: [PATCH 77/92] Rename 11-handle-errors-exceptions.md to 10-handle-errors-exceptions.md --- ...handle-errors-exceptions.md => 10-handle-errors-exceptions.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/en/04-design/02-web-app-checklist/{11-handle-errors-exceptions.md => 10-handle-errors-exceptions.md} (100%) diff --git a/docs/en/04-design/02-web-app-checklist/11-handle-errors-exceptions.md b/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md similarity index 100% rename from docs/en/04-design/02-web-app-checklist/11-handle-errors-exceptions.md rename to docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md From d7f013c4fbfda0d46030f1080db06588d86d7d0a Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:20:57 +0200 Subject: [PATCH 78/92] Fix linting --- .../01-secure-by-default.md | 32 ++++++++++++------- 1 file changed, 21 insertions(+), 11 deletions(-) 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 57139d80..12d24457 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 @@ -2,7 +2,8 @@ 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] +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. @@ -15,12 +16,18 @@ and use the lists below as suggestions for a checklist that has been tailored fo 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 +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 +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 +12. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application + frameworks unless implemented to confuse an attacker +14. 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 +16. 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 +18. 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 @@ -28,14 +35,17 @@ and use the lists below as suggestions for a checklist that has been tailored fo 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. +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. 6. 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 +2. Use security vetted container images that is scanned for package and component vulnerabilities and pulled from a private + container registry +4. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on- + premises infrastructure +6. Utilize Policy-as-Code to enforce policies including privilege assignments ---- From 6e33c912d7ae88c7c3236d64a1645b001372e78f Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:25:26 +0200 Subject: [PATCH 79/92] Fix linting --- .../02-web-app-checklist/01-secure-by-default.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) 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 12d24457..5ccbfbc4 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 @@ -17,7 +17,7 @@ and use the lists below as suggestions for a checklist that has been tailored fo 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 + 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 12. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application @@ -36,15 +36,15 @@ and use the lists below as suggestions for a checklist that has been tailored fo 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. + or the equivalent thereof. #### 3. Cloud security 1. 6. 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 + container registry 4. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on- - premises infrastructure + premises infrastructure 6. Utilize Policy-as-Code to enforce policies including privilege assignments ---- From 76da67596653cbbf5d13663c46ef1cdfb6472840 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:35:43 +0200 Subject: [PATCH 80/92] Fix ordering --- .../01-secure-by-default.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) 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 5ccbfbc4..2c21b1d6 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 @@ -17,16 +17,17 @@ and use the lists below as suggestions for a checklist that has been tailored fo 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 -10. Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is +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 -12. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application +10. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks unless implemented to confuse an attacker -14. Ensure the .git, .svn folders or any source control metadata aren't deployed together alongside the application in +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 -16. Do not store passwords, secrets, connection strings, key material, secret management integrations or other +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 -18. Remove or restrict access to internal application and system documentation (such as for internal APIs) as this can +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 @@ -40,12 +41,12 @@ and use the lists below as suggestions for a checklist that has been tailored fo #### 3. Cloud security -1. 6. Enforce JIT (Just-In-Time) access management +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 -4. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on- +3. Utilize Infrastructure-as-Code templates for automated provisioning and configuration of your cloud and on- premises infrastructure -6. Utilize Policy-as-Code to enforce policies including privilege assignments +4. Utilize Policy-as-Code to enforce policies including privilege assignments ---- From 1a2335ca70847fe07dd0b6af3138f12a280776c7 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:41:30 +0200 Subject: [PATCH 81/92] Fix linting --- docs/en/04-design/02-web-app-checklist/01-secure-by-default.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 2c21b1d6..892babc2 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 @@ -26,7 +26,8 @@ the 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 + 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 From fc390963a91d8ea1587cf6843bc93c326b0c28ee Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:42:38 +0200 Subject: [PATCH 82/92] Fix ordering --- .../02-web-app-checklist/02-frameworks-libraries.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 8a69ce1d..ab382410 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 @@ -47,9 +47,9 @@ In addition consider the following extra checks for frameworks and libraries. 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 -14. Use cryptographic signatures when updating your code and ensure the package manager verify those signatures -15. Use your SBOMs together with periodic or SCA tools to automatically detect well-known publicly disclosed vulnerabilities. -16. integrate SCA tools in early stages of software development +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 From 8a9fbd6c1f9bc30ccf7401358ef1bb32ee23d2dd Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:44:49 +0200 Subject: [PATCH 83/92] Update 02-frameworks-libraries.md --- .../04-design/02-web-app-checklist/02-frameworks-libraries.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 ab382410..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 @@ -39,7 +39,8 @@ 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. It is recommended to automatically create SBOMs (Software-Bill-Of-Materials) from within the build pipeline. +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 From d808c789a4126d9c14a9893b220f9e1f3abb1759 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:48:56 +0200 Subject: [PATCH 84/92] Fix linting --- .../04-design/02-web-app-checklist/04-encode-escape-data.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) 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 c5f3ba83..d5fc2d4c 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] and [C10: Stop Server Side Request Forgery][control10] together with [Server-Side Request Forgery Prevention Cheat Sheet][csproactive-c10] +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. From a33d11413d0ae7a950241e4dd9a42eae5c90dcda Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:49:48 +0200 Subject: [PATCH 85/92] Fix linting --- docs/en/04-design/02-web-app-checklist/05-validate-inputs.md | 1 - 1 file changed, 1 deletion(-) 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 7e943ff7..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 @@ -53,7 +53,6 @@ and use the list below as suggestions for a checklist that has been tailored for 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] From a7eb610dbeb3deed6a316e7934b359acbee17cd8 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:51:13 +0200 Subject: [PATCH 86/92] Fix linting --- docs/en/04-design/02-web-app-checklist/06-digital-identity.md | 3 ++- 1 file changed, 2 insertions(+), 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 c7baae28..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 @@ -87,7 +87,8 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +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 From 19f5c4704b2d73f056ab092f888b2d0eab2ada23 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:53:11 +0200 Subject: [PATCH 87/92] Fix ordering --- .../07-access-controls.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) 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 496178a2..a660ebe0 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 @@ -11,20 +11,20 @@ and use the list below as suggestions for a checklist that has been tailored for 2. Force all requests to go through access control checks unless public 3. Deny by default; if a request is not specifically allowed then it is denied 4. Apply least privilege, providing the least access as is necessary -6. Log all authorization events -7. Create unit and integration test to document and verify an application's business rules, data types and access +5. Log all authorization events +6. Create unit and integration test to document and verify an application's business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled for restricting function-level, data-specific, and field-level access based on consumer permissions and resource attributes -8. Access Control criteria and/or processes not testable through automated tests should be documented so that they +7. Access Control criteria and/or processes not testable through automated tests should be documented so that they can be manually tested -9. Use only trusted system objects for making access authorization decisions -10. Use a single site-wide component to check authorization -11. Access control should fail securely -12. Deny all access if the application cannot access its security configuration information -13. Segregate privileged logic from other application code -14. Do not hard code access controls that are role based -15. Enforce application logic flows to comply with business rules -16. Server side implementation and presentation layer representations of access control rules should not differ in such a way +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 Management From 3be0ccd96d489a74c4f557486860f4d82fb92267 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 22:59:30 +0200 Subject: [PATCH 88/92] Fix linting --- docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 d5fc2d4c..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,7 @@ 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] and +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, From 4f0840b9c316de96d5aebec5c817ce641fa5007a Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 23:32:00 +0200 Subject: [PATCH 89/92] Fix linting --- docs/en/04-design/02-web-app-checklist/07-access-controls.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 a660ebe0..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 @@ -34,7 +34,8 @@ and use the list below as suggestions for a checklist that has been tailored for 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 +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 From f2b7390b1a07738274119bf29b9a84cd7682c49a Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 23:33:56 +0200 Subject: [PATCH 90/92] Fix prdering --- .../02-web-app-checklist/08-protect-data.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) 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 8b775785..3299a5a9 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 @@ -21,11 +21,11 @@ and use the list below as suggestions for a checklist that has been tailored for 1. Classify data according to the level of sensitivity 2. Implement appropriate access controls for sensitive data -5. Avoid storing sensitive data when at all possible -6. Implement least privilege, restricting access to functionality, data and system information -7. Do not include sensitive information in the URL or query string, such as an API key or session token -8. Disable client side caching on pages containing sensitive information (e.g. Cache-Control: no-store) -9. 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 #### 3. Secret Management @@ -36,8 +36,8 @@ and use the list below as suggestions for a checklist that has been tailored for 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 -8. Scan code repositories to detect accidentally added secrets and credentials -9. Log all authorized access to a secret key for forensic purposes +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 From da2e95e1c940e222a1c1b88c017bc0aac3317c55 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 23:44:07 +0200 Subject: [PATCH 91/92] Fix spelling --- docs/en/04-design/02-web-app-checklist/08-protect-data.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 3299a5a9..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 @@ -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 (e.g., printf, strcat, strcpy etc.) -#### 5. Protct Data at Rest +#### 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. Protct Data in Transit +#### 5. Protect Data in Transit 1. Encrypt data in transit 2. Ensure secure communication channels are properly configured From 3007f67c38f306bcc45241c66ea21dee0e0c5cda Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 17 Jul 2025 23:46:02 +0200 Subject: [PATCH 92/92] Add words --- .wordlist-en.txt | 2 ++ 1 file changed, 2 insertions(+) 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