Let's suppose that attacker was able to inject JavaScript into website. Obviously he can do any HTTP request to backend mimicking user actions, unless there's some confirmation like SMS code which required direct interaction from user (even in this case malicious JavaScript could fool user). So, I guess, this attack vector couldn't be reasonably defended. But if attacker steals session, he can impersonate user and do almost anything. So I'm thinking about defense of this vector. Sure, server could check IP address, etc, but it's not always possible.

First thing: storing session in an HTTP-only cookie. JavaScript can't steal it. So far so good. But there's another weakness: 3-rd party website can craft form tag with action from my server and submit this form with user cookie. One could use CSRF tokens, but again they should be available to JavaScript, they could be stolen if JavaScript is compromised, they must be maintained on the webserver, which hurts scalability, etc. I'm thinking about using PUT method for every REST action (well, it won't be a proper REST obviously, let's call it HTTP API). There's no way to trick user into issuing PUT request from 3-rd party website and HTTP-only cookie will prevent stealing of cookie value.

I'm not seeing this usage, so I guess I'm missing something and there should be simpler way to secure endpoints?

  • "One could use CSRF tokens, but again they should be available to JavaScript" - So what? You already admitted that with an XSS vulnerability an attacker can submit pretty much whatever he wants. Sep 27, 2017 at 14:41
  • 2
    REST is a stateless Architecture, sessions shouldn't be involved Sep 27, 2017 at 14:48

1 Answer 1


I think you may be misunderstanding CSRF as a threat vector. A CSRF attack is one where the the attacker does not have access to the DOM, and is able to force the user's browser to submit a request which includes the user's authentication token. XSS is where the attacker is able to manipulate the DOM. If the attacker can manipulate the DOM, he can force the user to submit any requests, and it will include both HTTPOnly cookie values and any anti-CSRF tokens. Any CSRF mitigations put in place can be bypassed if an attacker can control the DOM (XSS).

Given this, the best implementation would include both an HTTPOnly authentication token and an anti-CSRF token which is accessible to JavaScript.

Also, anti-CSRF tokens can be implemented which do not need to be maintained server-side using HttpOnly cookies. You include a randomly generated token in an HTTPOnly cookie, and include the same token in a DOM-accessible fashion. When the client returns the request, include the anti-CSRF token as a header (or through a similar method.) Then, on the server, you validate that both the HTTPOnly token and header tokens match. A CSRF attack will submit the HTTPOnly token, but it cannot submit the the matching header token. An XSS attack will still be able to bypass this, but as we said above, anti-CSRF mitigations will not work if the attacker controls the DOM.

You must log in to answer this question.

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