4 ms·
On this topic, and as a co-maintainer (but not original author) of gorilla/securecookie, which is mentioned in this article: - Setting Secure and HttpOnly attr
by elithrar 8y ago
On this topic, and as a co-maintainer (but not original author) of gorilla/securecookie, which is mentioned in this article:
- Setting Secure and HttpOnly attributes are exactly what I do by default in gorilla/csrf - you have to explicitly override these[1] - CSRF prevention without these is a losing battle. I'm positive many devs miss the docs though, wonder why the library isn't working on their local machine (without HTTPS), and move on to a library that doesn't have these safe defaults. This is a hard thing to fix: docs only go so far.
- securecookie just returns the authenticated, and optionally encrypted, cookie value. It's pretty minimal. I'm already looking at a v2 with some breaking API changes[2], including using an AEAD instead of the original authors' AES+CBC + HMAC construct. This could also be an opportunity to provide a convenience method - WriteCookie - that sets sane defaults for you, ala gorilla/csrf (which I wrote from scratch)
But as per the other comment: "all domains" is not correct. Cookies are still origin-scoped. HttpOnly is the real problem; followed by Secure. The SameSite attribute[3] is another lever to pull here: and, of course, for devs to learn & potentially disable.
[1]: https://godoc.org/github.com/gorilla/csrf#Secure https://godoc.org/github.com/gorilla/csrf#Secure
[2]: https://github.com/gorilla/securecookie/issues/43 https://github.com/gorilla/securecookie/issues/43
[3]: https://github.com/gorilla/sessions/releases/tag/v1.1.2 https://github.com/gorilla/sessions/releases/tag/v1.1.2