I want your help on getting more concrete information on a type of vulnerability that I remember vaguely.

I vaguely remember hearing about a year ago that if you set up a webapp on a subdomain, and that webapp gets compromised, then your main webapp (on the root domain) could be compromised as well, because (and this is the part that's vague in my memory) the browser has some assumptions about the two different webapps being the same entity because they're from the same root domain.

I heard that this why Facebook originally hosted their developer forums on a different domain instead of a subdomain of facebook.com; because the forum app was far, far less extensively audited for security problems than Facebook itself, and they didn't want any security holes in the forums to allow an attacker to gain access to Facebook itself.

(To clarify, these attacks are based on the browser, not on some kind of connection between the two servers.)

My question: Do you have the specifics of what those vulnerabilities are and how I could protect against them so I'd be confident that an attacker getting access to one webapp couldn't get access to a different webapp on the same root domain?

  • Do you mean, that a cookie set on a sub-domain can also be read on the domain itself? Nov 18, 2012 at 21:19
  • I think that's one of the issues, not sure whether it's the only one.
    – Ram Rachum
    Nov 18, 2012 at 22:19

4 Answers 4


The purpose is to ensure that XSS vulnerabilities in one webapp doesn't allow compromise of the other webapp.

If you run them on two separate domains (e.g., facebook.com and facebookdevelopers.com; not facebook.com and developers.facebook.com), then the browser same-origin policy provides isolation between the two webapps.

This has been discussed at length in several other questions here. Rather than repeating all of the technical details, let me refer you to those other questions:


This sounds like an insecure cookie scope. If the application is scoping its cookies to .domain.com then XSS in a sub-domain can lead to an account compromise.

As long the applications are on separate servers, they are not sharing the same database account and cookies are scoped properly there shouldn't be a concern.

  • aah I see that's what he meant. Nov 18, 2012 at 20:52
  • Great, I'll take care of that. Do you think there could be anything besides cookies? Perhaps (just wildly brainstorming here) a browser letting a script from one webapp access info in the iframe of the other webapp because they're the same domain?
    – Ram Rachum
    Nov 18, 2012 at 22:22
  • @RamRachum, Yes, that could happen, too. See my answer.
    – D.W.
    Nov 18, 2012 at 22:59
  • @Ram Rachum that doesn't sound like a SoP abuse, unless you set the x-frame-options...
    – rook
    Nov 19, 2012 at 2:37

It has nothing to do with the domain IIRC. It's just that it's running on the same webserver under the same user. So to get segregation, you would need to run the webapp under a different user with limited rights. The user your one site is running under should have no rights on files or directories your other user is running under.

Anyway, if you think your webapp is going to be insecure. Don't put it online.

  • I guess you do not recall correctly, because cookies are one issue with the domain that has absolutely nothing to do with whether they're run on the same server.
    – Ram Rachum
    Nov 18, 2012 at 22:20
  • Also, all webapps are insecure.
    – Ram Rachum
    Nov 18, 2012 at 22:21
  • Yea, you didn't mention cookies, I thought you were talking about running apps on the same server :) Nov 19, 2012 at 6:20

You might be interested in this S.O. thread discussing cookie scope as @Rook describes.

One way to fix this issue is with Channel Bound Cookies (a pending RFC) that is illustrated in the above link.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .