Don't automatically set a cookie domain

Created on 31 January 2018, over 7 years ago
Updated 20 February 2023, over 2 years ago

Problem/Motivation

In SessionConfiguration we always set a cookie domain even if one is not configured. If the current domain is example.com the cookie domain is set to .example.com and if the domain is www.example.com we set it to .www.example.com. If the cookie domain is set to .example.com then the cookie will also be available on all the sub-domains. It is more secure if it is not.

Note not setting a cookie domain is an OWASP recommendation:

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the β€œDomain” attribute should not be set (restricting the cookie just to the origin server) and the β€œPath” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Proposed resolution

If we don't set a cookie domain then browsers will automatically consider the cookie host-only (i.e. the request's host must exactly match the domain of the cookie).

This means on browsers other than IE and Edge we are more secure but on those browsers we are the same as now. The question is whether or not this normalisation of behaviour is desired on not.

View cookie compliance table for major browsers

Remaining tasks

Manual testing

User interface changes

None

API changes

None

Data model changes

None

πŸ“Œ Task
Status

Needs review

Version

10.1 ✨

Component
BaseΒ  β†’

Last updated about 8 hours ago

Created by

πŸ‡¬πŸ‡§United Kingdom alexpott πŸ‡ͺπŸ‡ΊπŸŒ

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

  • Needs manual testing

    The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024