Are there any security reasons against "drop-www" (using example.com instead of www.example.com)?

Question

Are there any security reasons against "drop-www"?

In other words, are there any security reasons against using an apex [1] domain name such as example.com instead of a subdomain such as www.example.com?

Quote https://www.bjornjohansen.com/www-or-not

Cookies are passed down to subdomains Cookies set from a hostname, will also be sent to all subdomains. I.e. if the website on “example.com” sets a cookie, the browser will also send this cookie when visiting “www.example.com”. Sounds like a good thing, since it’s the same website anyway, right? But the cookie will also be sent to “cdn.example.com”, to “email.example.com”, to “intranet.example.com”, to thirdpartyservice.example.com and so on. And a lot of third party services let you use your domain exactly like this.

A cookie set from “www.example.com” will not be sent to any “sibling” hosts like above. Your browser understands that they are not “subservices” but completly different services, and should not get access to your cookies.

Is this still the case? Can this be solved?

Are there other non-cookie related security issues with using the apex domain name instead of a subdomain?

---

[1]

• github says

  • An apex domain is a custom domain that does not contain a subdomain, such as example.com.

• https://stackoverflow.com/questions/55461299/what-is-the-correct-term-or-apex-naked-bare-root-domain-names

Answer 1

Are there any security reasons against "drop-www"?

TL;DR - Yes, sending cookies to a vulnerable server could be used to harvest cookies.

The article you referenced does a decent job of explaining this but doesn't provide many details about why it's a security concern.

For example, say you are using example.com and I run a service on blah.example.com for you. A user logs in to example.com and gets a session cookie. They are then directed by you to my service. They will send me their cookie with the session information. I could then use that for access to example.com.

Note that this isn't limited to using just the domain. If you set your cookie domain attribute incorrectly you can have the same issue.

This is an OWASP explanation of it:

If there was a vulnerable server on a subdomain (for example, otherapp.mydomain.com) and the domain attribute has been set too loosely (for example, mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens) across the full scope of mydomain.com.

It may be better to leave Domain empty, in which case it would point to the current server than to incorrectly set the Domain attribute.

There have been similar exploits done by browser extensions.

Bottom line, there are security reasons against using a naked domain, but like all things security, it depends on your risk tolerance, threat model, etc.

References
RFC-6265
Chrome Extensions Harvesting Cookies
Testing for Cookies Attributes

Answer 2

Cookies set from a hostname, will also be sent to all subdomains

This is not necessarily true.

From Using HTTP cookies - HTTP | MDN:

The Domain attribute specifies which hosts can receive a cookie. If the server does not specify a Domain, the browser defaults the domain to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included.

This property can be further enforced with a __Host- cookie prefix, making it impossible for subdomains to set cookies for the apex domain.

So it is possible to get similar security on the apex domain, if care is taken to configure cookies correctly.