I'd like to set up a self-hosted Ghost.org blog for a SaaS. I have two options:

  • example.com/blog
  • blog.example.com

Everywhere I read they recommend the /blog for SEO. However, I'm concerned about the security considerations of such setup.

First, the cookies. Do I have to worry about them?

The existing cookies for the SaaS have:

  • domain not specified
  • path as /
  • HttpOnly
  • Secure
  • SameSite: Lax

Is there any chance that Ghost.org blog at /blog can potentially access or modify the SaaS app's cookies?

My other concern is if someone is able to upload anything into blog. It's not supposed to happen, but there is a member interface for Subscribe/Unsubscribe on Ghost.org, which means that theoretically they could find a way to upload some file. If not today, then maybe in the future.

Anything else I need to be concerned about in the /blog scenario?

  • Welcome to the community. It depends to which path you get the cookies to. Commented May 17 at 15:11

1 Answer 1


From a security perspective, you should definitely run the blog under a subdomain, not a path on the main domain.

The same-origin policy isolates the subdomain from the main domain to some degree. Additionally, you can use the __Host- cookie prefix on the main domain to prevent the subdomain from overwriting cookies. Note that the SameSite attribute is much weaker than the __Host- prefix, because it always allows same-site requests from a subdomain to a parent domain, even if the value is Strict (which you don't have).

A path doesn't provide any isolation in terms of the same-origin policy or cookies, as explained on the Mozilla Developer Network. An attacker who has compromised the blog may very well be able to read, create and overwrite cookies of the main domain.

  • Thanks, I've decided to go with the subdomain approach. One thing about the __Host- prefix: what does it offer what my current solution doesn't? The current cookie is secure + doesn't have domain specified, but it doesn't have a __Host- prefix.
    – hyperknot
    Commented May 17 at 15:33
  • 1
    Without a __Host- prefix, the browser doesn't enforce the domain limitation of the cookie. You may omit the domain in your own cookies, but an attacker on blog.example.com is free to set a cookie with the same name for Domain=example.com . With the prefix, you can be sure the cookie can only ever be set from the current domain.
    – Ja1024
    Commented May 17 at 16:10

You must log in to answer this question.

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