Secure Session Management for Go Applications

Table of Contents

1. Challenge

   Introduction

   Welcome to this Code Lab on secure session management in Go! You will start from a small web app that puts the logged-in username directly in a cookie, which means anyone who can read or forge that cookie can impersonate a user.

   Your goal is to replace that pattern with a server-side session store and an opaque session ID in the browser. The starter code already includes a Session struct so your project compiles while you work. info> This lab experience was developed by the Pluralsight team using Forge, an internally developed AI tool utilizing Gemini technology. All sections were verified by human experts for accuracy prior to publication. For issue reporting, please contact us.

2. Challenge

   Implement a Session Store

   When you keep session state in the browser (for example in a cookie you treat as data), a user—or an attacker—can inspect or tamper with it. You will instead keep session records on the server and give the browser only an unguessable session ID.

   In this step, you will build the foundation for your store: a thread-safe in-memory map for active sessions, plus a helper that generates strong session IDs.

3. Challenge

   Create and Manage Sessions

   Now that you have a place to store sessions, you will wire login so that a successful sign-in creates a session on the server and sends only the session ID back to the browser in a cookie.

   In this step, you will replace the insecure "username in a cookie" shortcut with a real session flow.

4. Challenge

   Secure Session Cookies

   You will still send your session ID in a cookie, but you should treat that cookie like a credential. Modern browsers give you attributes that harden how the cookie is stored, sent, and replayed.

   As you work through this step, you will set attributes so your session_token cookie is harder to steal or misuse:

   • When you set HttpOnly, you hide the cookie from JavaScript, which reduces how easily an XSS bug can read it.
   • When you set Secure, you tell the browser to send the cookie only over HTTPS (you will still see the attribute validated in unit tests via httptest).
   • When you set SameSite, you give the browser hints about when to include the cookie on cross-site requests, which helps you reduce CSRF risk.
   • When you set MaxAge (or Expires), you control how long the cookie lives in the browser alongside the expiry you store in your server-side Session. > Note: Secure means real browsers only send the cookie over HTTPS. In this lab, your unit tests still assert the attributes through httptest, so you can validate the behavior without running TLS locally.
5. Challenge

   Protect Routes and Handle Logout

   Issuing sessions is only half of the story—you also need a consistent way to require a valid session before you run sensitive handlers. In Go, middleware fits that role well because you write the check once and reuse it across routes.

   In this step, you will add middleware that validates your session_token, and you will implement logout so a user can end a session cleanly on both the server and the client.

6. Challenge

   Prevent Session Fixation

   In your final step, you will harden login against session fixation: if you reuse whatever session ID the browser already had, an attacker who planted that ID could ride along after the user authenticates. You will instead make sure a successful login gives the user a fresh session ID and invalidates the old one on your server when appropriate.

   You will implement that behavior in loginHandler after you verify the user. Start the application by running the following command in the Terminal:

   go run .
   

   Once it's running, visit the application.