Security defaults that belong in every Go HTTP server from day one — CORS, security headers, rate limiting, SQL injection prevention, input validation, secrets management, graceful shutdown, and request timeouts.
89
83%
Does it follow best practices?
Impact
99%
1.32xAverage score across 5 eval scenarios
Passed
No known issues
A product team is building a web application where users log in via a username and password form and receive a session cookie. The app is a traditional server-rendered or SPA setup where the browser sends the session cookie with every request. The security team has raised concerns about cross-site request forgery and about whether the session cookies are configured safely.
You need to build a Go HTTP backend that handles login, logout, and a protected profile endpoint. The session must be stored in a secure cookie, and state-changing requests must be protected from cross-site attacks.
Create a Go HTTP server in the ./auth-api/ directory with the following endpoints:
POST /api/auth/login — accepts JSON {"username":"alice","password":"secret"}, sets a session cookie, returns {"ok":true}POST /api/auth/logout — clears the session cookieGET /api/me — returns {"username":"alice"} if the session cookie is valid, else 401POST /api/change-password — protected endpoint that changes the password (can return a stub response)You can use a simple in-memory map for session storage (no real database needed). The session ID should be a cryptographically random value.
Produce a middleware_diagram.md file that documents the middleware chain in order (outermost to innermost handler), explaining why each middleware is placed where it is.