3 ms·
You really don't want to give some random SaaS tool full permission on your production web origin. If I'm Example Ltd. and my customers are trusting me to keep
by dpifke 4y ago
You really don't want to give some random SaaS tool full permission on your production web origin.
If I'm Example Ltd. and my customers are trusting me to keep their data on example.com safe, and I use example.blog for my blog hosted by Jimbo's Blogging Service, I don't need to worry about Jimbo or his employees or hackers targeting my blog getting access to example.com's cookies, local storage, etc.
Cf. It's really hard—in some cases impossible, without use of the Public Suffix List[0]—to completely wall off blog.example.com from example.com.
[0] https://publicsuffix.org/ https://publicsuffix.org/
- nokya 4y agoIsn't that why we have subdomains?
- chias 4y agoWhy not just use a subdomain? This is, arguably, what subdomains are for.
- mschuster91 4y agoSubdomains usually get all the cookies from the main domain (or at least they used to, didn't follow up on that issue for some years).
- cuttysnark 4y agoIt's the opposite. Set-Cookie takes the optional Domain attribute and "If omitted, this attribute defaults to the host of the current document URL, not including subdomains." However, perhaps you're remembering "Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included." [0] [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#domaindomain-value https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...
- deleted 4y ago[deleted]
- getcrunk 4y agoCan you give an example of what it means for a subdomain to not be walled off?
- kadoban 4y agoOne thing you'd really want to do in particular is stop blog.example.com from either setting or reading any cookies from example.com
- deleted 4y ago[deleted]