3 ms·

> Random code from the Internet shouldn't have any chance to touch user credentials One thing that helps with this are HttpOnly cookies. "A cookie with the Ht

by hu3 2y ago

> Random code from the Internet shouldn't have any chance to touch user credentials One thing that helps with this are HttpOnly cookies. "A cookie with the HttpOnly attribute can't be accessed by JavaScript, for example using Document.cookie; it can only be accessed when it reaches the server. Cookies that persist user sessions for example should have the HttpOnly attribute set — it would be really insecure to make them available to JavaScript. This precaution helps mitigate cross-site scripting (XSS) attacks." https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

mjevans 2y ago
That does nothing to address Credentialing and Authorization issues.
- hu3 2y ago
  How so? Cookies are the most common way to implement persistent user sessions and by consequence, authn/authz. If it can't be accessed by JS, then it at least does something, to say the least. Could you expand your reasoning?
blincoln 2y ago
HttpOnly is mostly a vestigial artifact of the 2000s. As soon as web apps began relying on JS in the browser making calls to APIs, that same JS started needing access to the session token, or credentials equivalent to the session token. If you maintain an app that can get away with an HttpOnly session token cookie, it's a good idea, but unless it's legacy code, it will probably break something, or the JS is getting creds another way and the cookie having the flag set is giving you a false sense of security.
- ndriscoll 2y ago
  Httponly cookies are still added automatically to js initiated requests. It is not a legacy feature. You don't need to get it another way because you don't need to get it at all in js. It prevents XSS from stealing the cookie and sending it elsewhere (though a successful XSS could still use the cookie while the user is on the page).
  - hu3 2y ago
    Thank you. It's impressive how much misinformation there is in our field. Some people read 1 paragraph from documentation and assume Httponly cookies are useless for SPAs.

by hu3 2y ago

mjevans 2y ago

That does nothing to address Credentialing and Authorization issues.

hu3 2y ago
How so? Cookies are the most common way to implement persistent user sessions and by consequence, authn/authz. If it can't be accessed by JS, then it at least does something, to say the least. Could you expand your reasoning?

blincoln 2y ago

HttpOnly is mostly a vestigial artifact of the 2000s. As soon as web apps began relying on JS in the browser making calls to APIs, that same JS started needing access to the session token, or credentials equivalent to the session token. If you maintain an app that can get away with an HttpOnly session token cookie, it's a good idea, but unless it's legacy code, it will probably break something, or the JS is getting creds another way and the cookie having the flag set is giving you a false sense of security.

ndriscoll 2y ago
Httponly cookies are still added automatically to js initiated requests. It is not a legacy feature. You don't need to get it another way because you don't need to get it at all in js. It prevents XSS from stealing the cookie and sending it elsewhere (though a successful XSS could still use the cookie while the user is on the page).
- hu3 2y ago
  Thank you. It's impressive how much misinformation there is in our field. Some people read 1 paragraph from documentation and assume Httponly cookies are useless for SPAs.