Suppose you bought the domain name “example.com” for your website. Will your visitors enter www.example.com or just the bare domain example.com in their browser’s address bar to access your site?
The general advice is to ensure that both addresses work but to choose one to be your canonical domain. That is, one address will be preferred and the other one will just redirect the user to the preferred one. Typically the redirect is achieved by serving a HTTP 301 response code with the correct Location response header.
Which one should you choose?
The “www” domain is traditional but the bare domain (aka zone apex) is quicker and easier to both say and type. There are numerous arguments one way or the other but there is one reason that I recommend choosing “www” to be the primary.
No, it’s not related to the DNS limitation of bare domains. You may have heard that using a bare domain limits you to using an A record for DNS and you cannot use the CNAME record type required by many service providers, including Section. I don’t worry about this because all modern DNS providers, including Section’s own Hosted DNS, support a DNS record pseudo-type known as an ALIAS or ANAME record which essentially enables CNAME-like behaviour for bare domains.
The reason I recommend “www” is due to cookies and sub-domains and their combined impact on both web security and caching.
Caching
When you prefer the “www” domain, you can ensure your web server specifies that cookies are only applicable to the “www” domain. The browser will then only send the cookies for requests to the “www” domain. If you have other sub-domains, eg images.example.com, blog..., or mail..., the browser will not send the cookies that apply only to “www” in any requests to these sub-domains.
However, if the bare domain is chosen as the canonical site, the cookies should also be scoped to the bare domain. The problem here is that different browsers have different opinions on whether a cookie set at the bare domain should also be sent for sub-domain requests and it varies further depending on whether the domain attribute was included in the Set-Cookie response header or not.
Cookies are a signal to a cache that content may be user-specific and that it might be safest to bypass caching. While Varnish Cache, Section’s caching solution, can be configured to ignore cookies that are known to be cache-safe, it is easier to manage if you can be sure the browser will never send the cookies to the sub-domains at all.
Security
All too often, sub-domains, especially those not considered part of your main website (like web mail or a blog), can be missed in regular patching cycles or security reviews. This means that security vulnerabilities, such as Cross-Site Scripting (XSS) and others, may be present. It is also common that those vulnerabilities are assumed to be less important because the sites on these sub-domains are less critical to the business.
When combined with a main website using the bare domain, vulnerable sub-domains can provide a potential attack vector into the main website itself. If the cookies intended for the main website are unintentionally included in requests to sub-domains (due to the end-user’s browser choice or Set-Cookie header values) then an XSS vulnerability could allow an attacker to steal cookie values intended for the main website and then use those to masquerade as other users on the main website.
Of course, vulnerabilities on sub-domains are not limited to impacting the main website on the bare domain. There are other classes of attacks that can impact the main website even if it uses “www” but by choosing “www” to be preferred you are at least limiting the types of attacks that are possible.
