0

I've done some researches on this topic, and I found this question on SE: Sending session cookie inside the HTTP response body

But this answered my question just in part.

On login, my server will create a httpOnly cookie, and also put this authorization token in the response body. This is because my server handles normal HTTP requests from a browser, and also provides RESTful APIs.

In case of an API request, the client will then find the token in the response body and use it accordingly. (I believe that the cookie won't be received because the request is not made through a normal browser, correct me if I am wrong.)

In case of a browser request, the token will be received as a httpOnly cookie, but also in the response body. My doubt is: wouldn't this just nullify the fact of using an httpOnly cookie, since I'm also sending the token in the response body?

The problem arises because I need to handle also API calls, which is why I send the token in the response body.

I hope my question is clear.

Improve this question

1 Answer 1

Reset to default
1

If you're able to send the token in the request body, it must be stored somewhere script-accessible (probably in session or local storage). If it's stored somewhere script-accessible, then there is literally no point having the cookie be HttpOnly.

HttpOnly is only barely a security measure to begin with - for most exploitation scenarios, it might limit the damage or make exploitation harder, but XSS can still easily be catastrophic for the user - and it only makes sense at all if the cookie value is never exposed to script anywhere else. Since that doesn't apply here, the HttpOnly flag is pointless.

Improve this answer
4
  • Thank you for your answer. It confirms my doubts. At this point, I would ask how to implement it in a secure way, but still being able to handle browser requests and provide RESTful APIs.
    – Kenna
    Jan 21, 2020 at 13:59
  • Maybe sending the token not in the response body but in another way (authorization header?) would solve it.
    – Kenna
    Jan 21, 2020 at 15:02
  • @Kenna Go ahead and ask a new question if you haven't already, but the short answer is that, from a security perspective, sending the token in the body or in a header are both fine. Neither will be leaked to an adversary, both prove that the caller has the secret, neither is vulnerable to CSRF, etc. The only difference I can think of is that using the header with legitimate cross-origin XHR/fetch requires a slightly more complicated CORS configuration, but that's not a security issue.
    – CBHacking
    Jan 21, 2020 at 18:39
  • Ok, if I won't find enough data on my question, I will ask a new question on this subject. I really appreciate your help.
    – Kenna
    Jan 21, 2020 at 18:47

You must log in to answer this question.

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