Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm writing a multi-tenant application where accounts are scoped by subdomains. This adds considerable complexity and I'm starting to worry about security.

Each user can have several accounts. For example, assuming is my app, and can belong to the same user. When logged in, users can add new accounts, and/or switch contexts to a different account if they already own another one.

I'm using Rails, and I'm using the :cookie_store for my session_store

ACME::Application.config.session_store :cookie_store, key: '_acme_session', domain: :all

When users register, I create a remember_token attribute (different than the password) that gets stored. It value is a random base 64 string. I then create an cookie with that value. This ensures that users are logged in under every context.

  1. When viewing
  2. When switching to or any other domain or subdomain.
  3. When adding a new account

I noticed that other multi-tenant apps scope their session cookies on subdomain basis. So, on UserVoice, logging into and going to requires you log in again.

Am I missing something here and exposing potential vulnerabilities using this approach? I'm afraid I missed something obvious!

My implementation for the cookies:

  • When users register I create a remember_token attribute and store it, and then assign its value to a cookie.
  • I look for this cookie when users return; if it's found, I look up the user based on its value and log them in, otherwise they log in using their username and password.
share|improve this question
Without knowing the answer myself, how "difficult" is it to generate the universe of base64 and spin up X sessions for it as a bot wanting admin? – Woot4Moo Jun 6 '12 at 19:34
Just an aside: have you thought about whether you have appropriate info to guard against CSRF? – Jeff Ferland Jun 6 '12 at 19:35
@JeffFerland, Yes. I have that covered. Rails has a handy controller method called protect_from_forgery which inserts a random token. – Mohamad Jun 6 '12 at 20:08
@Woot4Moo, I can't say I know the answer to that myself. Presumably difficult enough to deter would be attackers. My login system is borrowed from an authoritative reference that has been implemented and tested a plethora of times; and I followed to devotedly, until the issue of subdomains cropped up. – Mohamad Jun 6 '12 at 20:10
up vote 9 down vote accepted

You asked: Am I exposing potential vulnerabilities by exposing the same session cookie to all my users' subdomains?

Answer: It depends, but generally speaking, yes, you could be exposing yourself to some attacks. It depends upon what kind of content you allow on the subdomains (e.g., There are two cases:

  • If you allow Elmer to put arbitrary HTML on the website hosted at his subdomain, then you have a problem. Using the same session cookie on all subdomains is a security hole in this case.

    The attack: A malicious Elmer could set up his site with some Javascript that reads the session cookie of anyone who visits his site and steals it. Then, if poor Bugs Bunny visits (Elmer's site), Elmer learns Bugs Bunny's session cookie. Now Elmer can pretend to be Bugs Bunny when visiting other subdomains (including Bugs' own site). That's no good.

  • If you somehow prevent Elmer from writing arbitrary HTML, Javascript, etc., to the website on his subdomain, then you might be OK. However, be warned this may be tricky to do securely, if you allow the users a lot of control over the content on their subdomain. You'll have to block a lot of stuff (including Javascript, Flash, Java, META tags, and maybe more).

Generally speaking, the reason to use multiple subdomains is to isolate multiple users from each other, so that one malicious user cannot harm other users, and so that a security failure by one user does not harm other users. If that's the reason you are using multiple subdomains, then your practice of using a single session cookie on all domains is insecure and should not be used.

In other words, most folks who are using multiple subdomains are probably in the first case, and thus I would expect that in many cases where multiple subdomains are used, it is not a good idea to expose the session identifier to all subdomains.

A better approach, that doesn't have these problems: Add a login page on When users log in on, give them a session cookie that is scoped to only (no subdomains). This will be the secure session cookie.

When users visit a subdomain, you can do some tricks to authenticate them using their cookie and then give them a new cookie that is specific to the subdomain, without requiring them to log in again. The backend webserver can remember the association between the subdomain-specific cookie and the secure session cookie, so the webserver will be able to manage authentication in a way that the user doesn't notice.

This way, because you are separating your cookies by domain, you get better security. If one subdomain hosts malicious content, it learns only the session identifier for that subdomain, but it doesn't learn the session cookie for or for any other subdomains.

For instance, the secure session identifier for might be 7a3f...90 (cookie: SESSIONID=7a3f...90, scoped to The session identifier for might be 09ac...b3 (cookie: SUBDOMAIN_SESSIONID=09ac...b3, scoped to, generated as SHA1(7a3f...9 || = 09ac...b3. The session identifier for might be f067...85 (cookie: SUBDOMAIN_SESSIONID=f067...85, scoped to, generated as SHA1(7a3f...9 || = f067...85. If is malicious, it cannot learn the secure session identifier or the session identifier for any other subdomain; it can learn the session identifier for its own subdomain, but that doesn't give Elmer any additional powers he didn't already have.

The only tricky bit is how to install these cookies onto the user's computer. I don't think it is a good user experience to ask/expect users to log in again for each subdomain they visit. Therefore, we should look for a technological solution that lets us transfer the session cookies across domains securely, without requiring the user to log in multiple times.

There are ways to achieve this, using iframes, postMessage, and/or redirection between domains. For instance, here is one approach. can have an invisible iframe that loads The latter can use the secure cookie to authenticate the user. Meanwhile, the page can use postMessage to communicate to that iframe and ask it for a new session identifier that's good only for Once receives this new session identifier, it can automatically set a session ID cookie that's scoped to, and now you're good. Here a key fact about postMessage is that the recipient of such a message can verify the domain that sent the message, which prevents spoofing and malicious attacks ( can verify that it is who is requesting a subdomain-specific session identifier and respond with the appropriate session identifier for

See the steps that Livejournal takes to protect its cookies, for an example of this sort of approach deployed in practice. You can also read about the attack that prompted them to implement this defense, to learn about the risks of doing nothing to defend against these threats.

share|improve this answer
Wow, thank you for that thoughtful write up. This is great information! – Mohamad Jun 8 '12 at 19:13

It's hard to figure out exactly what you're trying to do... but sounds like you might be making the problem harder than it needs to be. If I understand this post correctly, it explain how to share the same session between sub-domains, without having to generate your own session cookies. i.e. changing domain: :all to domain: "" might do the trick?

share|improve this answer
@Yoaov, I've actually figured that part out already. It's just making sure it's secure. See accepted answer. Cheers! – Mohamad Jun 8 '12 at 19:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.