From 04e6e19af7072084839a77d876a79e088963b3ae Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 4 Aug 2025 15:58:38 +0200 Subject: [PATCH 1/4] Update 07-access-controls.md --- 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 dd2f0e07..c5ff6232 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 @@ -27,7 +27,7 @@ and use the list below as suggestions for a checklist that has been tailored for 15. Server side implementation and presentation layer representations of access control rules should not differ in such a way that they allow for business functionality and rules to be compromised -#### 2. Access control Management +#### 2. Session- and Access control Management 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 @@ -46,6 +46,7 @@ and use the list below as suggestions for a checklist that has been tailored for multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis 11. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +12. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users should be able to terminate their active sessions #### References From b8031dce4333fd2be051514a97446013a25bd1f7 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 4 Aug 2025 16:26:20 +0200 Subject: [PATCH 2/4] Move session management to digital identity --- .../07-access-controls.md | 21 ++++++++----------- 1 file changed, 9 insertions(+), 12 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 c5ff6232..0a0d941b 100644 --- a/docs/en/04-design/02-web-app-checklist/07-access-controls.md +++ b/docs/en/04-design/02-web-app-checklist/07-access-controls.md @@ -27,26 +27,23 @@ and use the list below as suggestions for a checklist that has been tailored for 15. Server side implementation and presentation layer representations of access control rules should not differ in such a way that they allow for business functionality and rules to be compromised -#### 2. Session- and Access control Management +#### 2. Access control Management 1. Limit the number of transactions a single user or device can perform in a given period of time, low enough to deter automated attacks but above the actual business requirement -2. If long authenticated sessions are allowed, periodically re-validate a user's authorization -3. Implement account auditing and enforce the disabling of unused accounts -4. A new account should have minimal or no access by default -5. For highly sensitive accounts implement Just in Time (JIT), Just Enough Access (JEA) management and avoid the use +2. Implement account auditing and enforce the disabling of unused accounts +3. A new account should have minimal or no access by default +4. For highly sensitive accounts implement Just in Time (JIT), Just Enough Access (JEA) management and avoid the use of admin accounts with global access -6. The application must support termination of sessions when authorization ceases -7. Restrict function-level access to consumers with explicit permissions -8. Restrict direct object references to only authorized users with explicit permissions to specific data items +5. Restrict function-level access to consumers with explicit permissions +6. Restrict direct object references to only authorized users with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA) -9. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken +7. Restrict access to user and data attributes to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA) -10. Restrict access security-relevant configuration information to only authorized users who have been allowed access through +8. Restrict access security-relevant configuration information to only authorized users who have been allowed access through multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis -11. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible -12. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users should be able to terminate their active sessions +9. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible #### References From daf5cf4261c931a75f4a5add6344625aff1da13c Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 4 Aug 2025 16:27:43 +0200 Subject: [PATCH 3/4] Move session management requirements to digital identity --- .../en/04-design/02-web-app-checklist/06-digital-identity.md | 5 ++++- 1 file changed, 4 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 8546522d..3d777f6c 100644 --- a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md @@ -81,7 +81,7 @@ and use the list below as suggestions for a checklist that has been tailored for 17. Set cookies with the `HttpOnly` attribute, unless you specifically require client-side scripts within your application to read or set a cookie value -#### 4. Session Generation and Expiration +#### 4. Session Management 1. Ensure that the session id is long, unique and random, i.e., is of high entropy 2. Generate a new session during authentication and re-authentication @@ -91,6 +91,9 @@ and use the list below as suggestions for a checklist that has been tailored for which users must re-authenticate 6. Supplement standard session management for sensitive server-side operations, like account management, by requiring and validating anti-forgery tokens (CSRF tokens) for each request that may change application state or execute an action +7. If long authenticated sessions are allowed, periodically re-validate a user's authorization +8. The application must support termination of sessions when authorization ceases +9. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users should be able to terminate their active sessions #### References From c890a558a4cd34ce8a8d13f7e48101304629f69d Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 4 Aug 2025 16:51:32 +0200 Subject: [PATCH 4/4] Fixes 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 3d777f6c..c13f84c0 100644 --- a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md @@ -93,7 +93,8 @@ and use the list below as suggestions for a checklist that has been tailored for validating anti-forgery tokens (CSRF tokens) for each request that may change application state or execute an action 7. If long authenticated sessions are allowed, periodically re-validate a user's authorization 8. The application must support termination of sessions when authorization ceases -9. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users should be able to terminate their active sessions +9. Application administrators should be able to terminate active sessions and authentication codes and -tokens and users + should be able to terminate their active sessions #### References