Hacker News Reader

stytchthrowawayon Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

That's really surprising, thank you for following up long after this post has been flagged. That snippet certainly shows the refresh token is accessible client-side.

I remain shocked that an auth company CEO would push a solution without HttpOnly protection. This would not get by our security audits, and Auth0 and many open source tools I've used do not have the same limitation (Auth0 sets it in the SDK rather than a proxy).

OWASP and NIST are aligned that HttpOnly cookie should be used:

[1] https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...

[2] https://pages.nist.gov/800-63-3/sp800-63b.html#711-browser-c...

stytchthrowawayon Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

Of course, I am not concerned that a 5 minute JWT is not HttpOnly. I did not intend to imply that.

However, I am concerned that the refresh mechanism is also not HttpOnly.

Firebase storing access tokens in client-side storage is an example of the former, not the latter. Are they also storing refresh tokens client-side?

FWIW - I am surprised that you would conflate access tokens and refresh tokens like this.

stytchthrowawayon Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

I signed in to stytch.com and see a cookie called "stytch_session_jwt" that is not set with HttpOnly.

It appears to refresh against https://stytch.com/web/sdk/sessions/authenticate with a Basic auth token which is also set on the client-side

Is there any protection to prevent this from leaking during an XSS attack? How does that work?