Is the session management implemented with certain standard components or services? Then reference them here. |
The session management MUST be based on the standard implementation of the application server or web container.
Session IDs MUST be
at least 120 bit strong,
generated with a cryptographically secure pseudorandom number generator (CSPRNG) and be completely random,
transferred encrypted (via TLS/HTTPS) on insecure networks
renewed after every successful user authentication,
NOT be transmitted in URLs.
Session cookies MUST be restricted in respect of their validity:
Set both security attributes „httpOnly
”, „secure
” and „SameSite
”
Avoid persistent cookies (don’t set expire attribute)
Set a path attribute to the base URL in case multiple applications are operated on the same system.
Authenticated server-side sessions:
MUST be invalidated after a user has been logged-in successfully,
MUST be invalidated after an authenticated user has been idle for more than 30 minutes (idle or soft logout),
SHOULD be invalidated after a user session has been active more than 24 hours,
SHOULD only exist once per user. When a user logs on, all existing session object of this user SHOULD be invalidated.
All state-changing operations (create, update, delete) on an authenticated user session MUST be protected against session replay and Cross-site Request Forgery (CSRF).
State-changing operations MUST be protected with a cryptographic random replay token (e.g. as an additional Hidden Fields or as X-header) that is unique for the user session or a specific request and for instance.
State-changing operations MUST be denied if a CSRF token is invalid or missing.
If a web framework provides an own CSRF protection mechanism, then this SHOULD be used.
State-changing operations MUST NOT be possible via HTTP GET.