this post was submitted on 12 Dec 2023
248 points (95.9% liked)
Programmer Humor
32415 readers
938 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's a security thing. The HttpOnly cookie can't be stolen using XSS or something like that, while a bearer token must be stored somewhere where javascript can see it.
Then again, cookie auth is vulnerable to CSRF. Pick your poison.
Although CSRF protection just adds a minor inconvenience, while there is never a guarantee your code is XSS vulnerability free.
That's assuming the client wants to make a web app. They may need to connect something else to that API.
It's perfectly normal to be able to cater to more authentication scenarios than "web app logging in directly to the target API and using its cookies".
If they want to make a web app they should use the cookie mechanism but ultimately each client app is responsible for how it secures its access.
Okay.
So make your webpage send the authtoken in a cookie and leave off the
Authorizationheader, and have your third party (presumably native) clients send anAuthorizationheader but not any cookies, and write your server software to check for both.This seems trivial. What am I missing?
The point of the cookies being HttpOnly is that it makes them completely inaccessible to client side JavaScript, making a whole load of session hijack/XSS attacks impossible.
The request for a bearer token here circumvents this protection because then there's a way for a client to avoid cookies all together, making the API vulnerable again.
Under what circumstance would a web client need to send an
Authorizationheader at all? The browser sends the cookie and the server treats that as equivalent.Malicious JavaScript in that case could theoretically forge a request using an auth token it acquired some other way by sending it as
Authorization: Bearerin addition to the cookie, but 1) this would be extremely easy to defend against (just check for the cookie before you check theAuthorizationheader) and 2) it would still not allow malicious JS code to access the user's auth token which was still stored in an HTTP only cookie, or really do anything that server side code (read: script kiddie scripts) couldn't, apart from sending a request from the web client's IP address.Dude literally said to do this for browser clients, and only support bearer tokens for non browser clients.