I want to add commenting functionality in my soon to be published blog, but I’m a bit skeptical about using a 3rd party service like Disqus. Considering that I can’t validate any of the comments on these platforms before they load in the user’s browser, how can I be sure that it won’t expose my blog to XSS vulnerabilities? Most importantly, I want to protect my own auth tokens for the admin app. Does the admin app store auth tokens on the client in a way that would make them vulnerable to malicious XSS code that might have slipped through Disqus’ security?
For any 3rd party service that injects content onto your site you will be reliant on their security to prevent XSS. For well-known and funded services such as Disqus you should be fairly confident that they have good security practices but that’s your call to make 
Admin auth uses a cookie with explicit SameSite=Lax and HttpOnly options. This means injected JS can’t read the session token from the cookie and if you have your front-end and admin on separate domains then any JS requests made from the front-end to the admin will not include the cookie and so won’t be authenticated.
The only other “tokens” that can be made available on the client are Content API keys but they are designed to give access to public content and there are no write privileges available.
2 Likes
Thanks for the response. Is there any way to prevent injected JS from making authenticated requests to the admin client on the same domain?
Unfortunately not. Browsers work on the same-origin policy which is all based around domains, they do not provide any tools to restrict requests to a path on the same-origin domain.
1 Like
In case it wasn’t clear, if you don’t want a completely separate domain then you can utilise subdomains, such as https://mysite.com and https://admin.mysite.com.
In that situation a request from https://mysite.com will not include the admin cookie when making a request to https://admin.mysite.com. Even if you try to include a cookie header it will be blocked by CORS.
Separate front-end and admin (sub)domains can be set in Ghost’s config file, it will treat each as separate sites so https://mysite.com/ghost/* will 404, as would https://admin.mysite.com - the admin would only be available at https://admin.mysite.com/ghost/*
1 Like
I’m still a little confused as to how this would work (Sorry, my knowledge of DNS isn’t that great). I know I can set the admin url in the config file, but would I need to setup the subdomain with my registrar (namecheap)? If so, where would I point the subdomain? Just to the same IP address/nameserver? Would the DNS settings on the registrar need extra configuration to properly route to the admin page, or would Ghost take care of this automatically?
You would need to set up a subdomain A record in your DNS settings that points to the same IP as your main site. On your server you would need to configure nginx to proxy the subdomain to your Ghost instance.
1 Like