One of the attack vectors we looked at earlier was session hijacking, which we discussed in the context of HTTP versus HTTPS and the way others can see the types of information that are critical to identity on a website.
Finding this data is incredibly simple on public networks for a lot of non-HTTPS applications that utilize sessions as definitive IDs. In fact, some large applications have allowed session IDs to be passed in URLs
In our application, we've used Gorilla's securecookie
package, which does not rely on HTTPS because the cookie values themselves are encoded and validated using HMAC hashing.
Producing the key itself can be very simple, as demonstrated in our application and the securecookie
documentation:
var hashKey = []byte("secret hash key") var blockKey = []byte("secret-er block key") var secureKey = securecookie.New(hashKey, blockKey)
For more info on Gorilla's securecookie
package see: http://www.gorillatoolkit.org/pkg/securecookie
Presently, our app's server has HTTPS first and secure cookies, which means that we likely feel a little more confident about storing and identifying data in the cookie itself. Most of our create/update/delete operations are happening at the API level, which still implements session checking to ensure our users are authenticated.