Last updated April 30, 2024

herokuapp.com is included in the Mozilla Foundation’s Public Suffix List. This list is used in recent versions of several browsers, such as Firefox, Chrome and Opera, to limit how broadly a cookie may be scoped. In other words, in browsers that support the functionality, applications in the herokuapp.com domain are prevented from setting cookies for *.herokuapp.com. Note that *.herokuapp.com cookies can currently be set in Internet Explorer, but this behavior should not be relied upon and may change in the future.

Historical context

Scoping cookies

Normally, a website may set browser cookies scoped either to its own domain, or any higher level DNS domain it belongs to. This is controlled by the “domain” attribute in the server’s Set-Cookie HTTP response header. For example, https://www.cs.berkeley.edu/ can set a cookie in the user’s browser that might be retransmitted to only itself, to all hosts ending in cs.berkeley.edu (e.g., radlab.cs.berkeley.edu), or even all hosts ending in berkeley.edu (e.g., english.berkeley.edu). It can NOT set cookies scoped to all hosts ending in edu (e.g., www.stanford.edu). This is not unique to .edu, but applies to all Top-Level Domains (TLDs), including .com, .org, and .net. The server is, of course, perfectly capable of passing a Set-Cookie header with domain=.edu, but it is not honored by any well-secured browser.

This restriction on cookie setting at the TLD level has been around since the early days of the web. It exists because of security reasons, both to prevent accidentally retransmitting cookies to 3rd parties, and to help provide some partial protection against cookie stuffing and more general types of session fixation attacks. The general reasoning is that web servers within the same DNS subdomain are usually considered to be operated by the same organization (In our earlier example, the University of California, Berkeley), and are thus less likely to attack each other. This is not true at the TLD level, as most TLDs allow any member of the general public to register a subdomain.

Not just a TLD problem

This becomes more complicated when we consider many countries use second-level domains (e.g., .co.uk and .ne.jp) as pseudo TLDs, and have few or no restrictions on who may register subdomains (e.g., amazon.co.uk).

To address that issue, for many years, browser vendors used internally-maintained lists of public domains, regardless of what level those domains fell in the DNS hierarchy. Inevitably, this led to inconsistent behavior across browsers at a very fundamental level.

The Public Suffix List

The Mozilla Foundation eventually began a project known as the Public Suffix List, to record all of these public domains and share them across browser vendors. Not all browsers use the Public Suffix List.

Cedar and herokuapp.com

Because Heroku applications on the Cedar stack are all hosted by default in the herokuapp.com domain, we also deal with the public suffix issue.

We believe the benefit of registering ourselves with the Public Suffix List outweighed the loss of what is a dangerous and minimally useful bit of functionality—being able to share cookies across multiple apps.

While there are many legitimate use cases for sharing cookies across multiple applications in a common domain, this is done better and more safely by using a custom domain for your applications.

For more information

• The Public Suffix List project also has a partial list of other areas where the list is used. This is available at https://publicsuffix.org/learn/.
• The session fixation and cookie hijacking problem, including a good description of how it applies to Heroku specifically, is outlined in the paper Origin Cookies: Session Integrity for Web Applications.
• To learn more about the general browser security model, both for cookies and general, we recommend Michal Zalewski’s excellent book, The Tangled Web.