> HttpOnly Attribute: Prevents client-side JavaScript from accessing the cookie, neutralizing XSS attacks
Just a note that ‘HttpOnly’ doesn’t neutralize XSS.(although this is not the main point of this blog)
This is dangerously misleading. HttpOnly prevents cookie theft, but it absolutely doesn't "neutralize" XSS.
First, even with HttpOnly cookies, malicious JS can still make requests on behalf of the user - the browser happily attaches all cookies (including HttpOnly ones) to XHR/fetch requests. So an attacker can still
or delete data, transfer funds, whatever the victim is authorized to do. They don't need to read the cookie, they just need the browser to send it.
This is why many apps ask for your password to change your email or reauthenticate you/trigger an MFA workflow when doing certain things.
Second, tons of XSS attacks don't even care about your cookies. They can rewrite the DOM with a fake login page and harvest credentials directly. They can keylog everything you type. They can steal data that's already on the page, redirect you to phishing sites, or mine crypto with your CPU.
HttpOnly is a good defense-in-depth measure, but calling it a neutralizer for XSS is like saying a seatbelt neutralizes car accidents. You still need proper input validation, (contextual) output encoding, CSP etc.
johnduhart · 3h ago
> I won’t get sucked into the session ID vs. JWT argument, but honestly, using JWTs in cookies is a win because you don’t have to fuss with storing session data on the server.
Okay, but then you implement storage of the refresh token and build this bespoke JWT re-issuance logic. So where's the win here? Just use sessions.
maz1b · 2h ago
What's wrong with storing JWTs in httponly cookies? Having a way to validate and track JWTs is a valid use case.
ripley12 · 5h ago
This is very useful, thanks. I've implemented similar authentication with tower_cookies in a home project, and it took me a long time to figure out; Axum is powerful but not always the most intuitive. It was a great learning experience, but I'd love to offload more of this to a crate next time.
Rust ORMs still don't feel great. They're verbose, the tooling is flaky, and they feel fly-by-night. They're surprisingly not very type safe either. I'd rather use Rust's sqlx until the Rust ORM situation improves.
Axum and Actix are already drop in replacements for something like Flask. They're mature and good at what they do.
The dream of a Rails or Django in Rust is still really far off. I'm glad the Loco folks are trying, but it needs a lot more magic and maturity to truly bear that comparison.
Spartan-S63 · 2h ago
Back when SeaORM first released, I was excited about another ORM that supported async (as Diesel didn't have an async shim at the time), but man does it have some weird design decisions.
The underlying query builder's API is just downright odd. The ActiveRecord pattern is fine for SeaORM, but it's just... weird. The ergonomics aren't right.
It's sent me down the path of wanting to design an ORM for myself that has the ergonomics I want. Nothing really to show yet at this point, but still something I want to build out someday.
tonyhart7 · 4h ago
wdym magic, its rust
there is no magic only a lot of macros, and someone must write them
if you talking about mature, of course 20+ years web framework is more mature + have more feature than loco. what kinda comparison is that
Just a note that ‘HttpOnly’ doesn’t neutralize XSS.(although this is not the main point of this blog)
This is dangerously misleading. HttpOnly prevents cookie theft, but it absolutely doesn't "neutralize" XSS.
First, even with HttpOnly cookies, malicious JS can still make requests on behalf of the user - the browser happily attaches all cookies (including HttpOnly ones) to XHR/fetch requests. So an attacker can still
`fetch('/api/admin/add-user', {method: 'POST', body: JSON.stringify({email: 'attacker@evil.com', role: 'admin'})})`
or delete data, transfer funds, whatever the victim is authorized to do. They don't need to read the cookie, they just need the browser to send it.
This is why many apps ask for your password to change your email or reauthenticate you/trigger an MFA workflow when doing certain things.
Second, tons of XSS attacks don't even care about your cookies. They can rewrite the DOM with a fake login page and harvest credentials directly. They can keylog everything you type. They can steal data that's already on the page, redirect you to phishing sites, or mine crypto with your CPU.
HttpOnly is a good defense-in-depth measure, but calling it a neutralizer for XSS is like saying a seatbelt neutralizes car accidents. You still need proper input validation, (contextual) output encoding, CSP etc.
Okay, but then you implement storage of the refresh token and build this bespoke JWT re-issuance logic. So where's the win here? Just use sessions.
Axum and Actix are already drop in replacements for something like Flask. They're mature and good at what they do.
The dream of a Rails or Django in Rust is still really far off. I'm glad the Loco folks are trying, but it needs a lot more magic and maturity to truly bear that comparison.
The underlying query builder's API is just downright odd. The ActiveRecord pattern is fine for SeaORM, but it's just... weird. The ergonomics aren't right.
It's sent me down the path of wanting to design an ORM for myself that has the ergonomics I want. Nothing really to show yet at this point, but still something I want to build out someday.
there is no magic only a lot of macros, and someone must write them
if you talking about mature, of course 20+ years web framework is more mature + have more feature than loco. what kinda comparison is that
No comments yet