For example, Firebase Authentication, by default, stores your tokens in local storage (actually, it stores in IndexedDB, but if an XSS can access localStorage, it can also access IndexedDB). Does it mean that Firebase Authentication is “insecure by default” and “wrong”? Does it imply that people should never use Firebase because it handles authentication in a way that a token can be leaked via an XSS?
I saw so many articles across the web about how it is “wrong” to store JWT in client-side storage. Yet to this day, I did not see anyone complain about it on firebase/firebase-js-sdk issue tracker.
I’d echo @dividedbynil
’s opinion — I think storing tokens in client-side storage is fine if developers know how to handle the risk.
"if developers know how to handle the risk." . IMHO, I don't think our perception of our skills can be an excuse or a pass for us to ignore security measures recommended by industry experts.
As for firebase, I would need more time to investigate that claim.
I don’t think that security measure is ignored. It’s heeding the warning, but after taking context into consideration, decide that it is irrelevant, or not worth the effort.
For example, there are client-side libraries that tries to protect from XSS by default. As well as browser’s security features such as content-security-policy and XSS protection. If we use that and do not do anything dangerous, that the arguments about XSS becomes less risky.
If a JWT is short-lived, it will expire, limiting the impact when a JWT is compromised. (Refresh tokens, on the other hand, become a more serious issue if compromised, and may need more security measures.) The thing is, context matters.
Then there are economics factor. Implementing server-side authentication may cost more (in terms of development effort) than just storing a JWT client-side. If I’m building a simple web-based client-side game with a leaderboard (no sensitive information is stored) using a secure-by-default library, then the benefits doesn’t outweigh the costs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It is the security-convenience tradeoff.
For example, Firebase Authentication, by default, stores your tokens in local storage (actually, it stores in IndexedDB, but if an XSS can access localStorage, it can also access IndexedDB). Does it mean that Firebase Authentication is “insecure by default” and “wrong”? Does it imply that people should never use Firebase because it handles authentication in a way that a token can be leaked via an XSS?
I saw so many articles across the web about how it is “wrong” to store JWT in client-side storage. Yet to this day, I did not see anyone complain about it on firebase/firebase-js-sdk issue tracker.
I’d echo @dividedbynil ’s opinion — I think storing tokens in client-side storage is fine if developers know how to handle the risk.
"if developers know how to handle the risk." . IMHO, I don't think our perception of our skills can be an excuse or a pass for us to ignore security measures recommended by industry experts.
As for firebase, I would need more time to investigate that claim.
This sounds like textbook argument from authority to me…
I don’t think that security measure is ignored. It’s heeding the warning, but after taking context into consideration, decide that it is irrelevant, or not worth the effort.
For example, there are client-side libraries that tries to protect from XSS by default. As well as browser’s security features such as content-security-policy and XSS protection. If we use that and do not do anything dangerous, that the arguments about XSS becomes less risky.
If a JWT is short-lived, it will expire, limiting the impact when a JWT is compromised. (Refresh tokens, on the other hand, become a more serious issue if compromised, and may need more security measures.) The thing is, context matters.
Then there are economics factor. Implementing server-side authentication may cost more (in terms of development effort) than just storing a JWT client-side. If I’m building a simple web-based client-side game with a leaderboard (no sensitive information is stored) using a secure-by-default library, then the benefits doesn’t outweigh the costs.