HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
gorilla
securecookie
Go2013–2024
gorilla / securecookie

securecookie

Package gorilla/securecookie encodes and decodes authenticated and optionally encrypted cookie values for Go web applications.

Web DevelopmentSecurity & Privacy
Explore on GitHubRead Hacker News discussions
7Distinct people
7Mentions
0Explicit recommenders
733GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Package gorilla/securecookie encodes and decodes authenticated and optionally encrypted cookie values for Go web applications.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2013-01-01 05:37:44 UTC to 2024-07-02 00:19:26 UTC.

0122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC202
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

7 sources
jerf·Nov 29, 2022
"You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now." In Go, not necessarily, because net/http actually is what many languages would call a "minimalist framework". There's a sense in which pretty much everyone here is right. You do need a framework in the general sense; you can't expect to just throw someone a TCP socket and get reasonable work out of them because the web is very complicated nowadays. But the reason why you can "do without a framework" in Go is that it is already a minimal one of its own, and in particular, that "minimality" focuses on providing a mechanism for composing various bits of HTTP code together. So, do you need CSRF protection? Go grab this: https://pkg.go.dev/github.com/gorilla/csr
Read the rest
f It operates with the integrated net/http Go framework to provide CSRF protection. You are objectively not abandoning the ability to have community-written CSRF protection when you go "frameworkless" in Go. Gorilla in general provides lots of mix-and-match pieces: https://www.gorillatoolkit.org/ , like cookie signing: https://pkg.go.dev/github.com/gorilla/securecookie I think calling Go "no framework" is kind of misleading, because I get what you're saying, but the standard library is not the "no framework" option. The "no framework" option is more like using https://github.com/valyala/fasthttp , which is its own server implementation with an incompatible API that does in fact remove you from the community code, other than the code that works only with that server. Don't over-read my post. I am merely saying that Go essentially ships with a minimal framework and so it is misleading to say or think of it as being "frameworkless" (and that is a criticism of the original link, yes), not that it is mandatory to use only that "minimal framework" and all other things on top of it are a bad idea. There are times and places to want large, preconfigured packages of additional functionality. But if there are times and places where it is not desirable, Go does come with a minimalist option by default. It is a pretty good, not-very-opionated option suitable for a standard library, where development is slow and there's not much room for experimentation in what a "full" web framework should look like. The standard library minimalist framework even makes the other frameworks pluggable. You can, for instance, write an API website, then realize that if you need a conventional HTML website, you can plug in a framework for that part, but leave the API part as-is, simply by routing the API URLs to the existing API code while routing the HTML website to the http.Handler provided by the framework. Even "not using an additional framework" is not the commitment it may be in other environments, because the net/http foundation is still there.
In The best Go framework: no framework?
whateveracct·Nov 12, 2021
Sign it as well! For instance: https://github.com/gorilla/securecookie Unless I'm missing something and the payload is effectively signed. Either way, I still like to have signing generically done at this level of abstraction. Then I can put whatever in there. Sometimes the encrypted payload is also signed too - maybe with a per-user secret. Now "log out everywhere" is as simple as scrambling the user's secret, thus invalidating their cookies. Simple.
In Using OAuth to add authentication to a React app
elithrar·Sep 14, 2018
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 con
Read the rest
venience 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 [2]: https://github.com/gorilla/securecookie/issues/43 [3]: https://github.com/gorilla/sessions/releases/tag/v1.1.2
In Securing cookies in Go
4ydx·May 8, 2015
You could always, you know, change the code (which is simple) so that an "infinite" expiry date is no longer valid. Line 215. https://github.com/gorilla/securecookie/blob/master/secureco... As for "impossible to revoke" well if you have control over your server you can do whatever you like so this falls into the very not-at-all-impossible category. As a baseline as long as there is no personal information in the "secure cookie" there really is no issue at all.
In Go-bootstrap: Generates a lean and mean Go web project

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.