Golang Security
Install this when your solo Go API needs agent-guided fixes for sessions, password hashing, and other common backend security traps before you ship.
Overview
golang-security is an agent skill most often used in Ship (also Build) that steers Go HTTP and auth code away from common session, secret, and bcrypt mistakes before solo builders deploy.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-securityWhat is this skill?
- Steers gorilla/sessions setup away from hardcoded keys toward env-loaded auth and encryption keys with HttpOnly, Secure,
- Covers bcrypt’s 72-byte password limit and safer handling for long passwords in Go
- Eval-driven assertions (e.g. gorilla-sessions-hardcoded-key, bcrypt-72-byte-limit) encode traps agents should not fall i
- Focused on Go HTTP handlers and auth-adjacent code paths solo builders actually write
- Complements gosec-style scanning with procedural secure-by-default implementation guidance
- Eval scenario gorilla-sessions-hardcoded-key asserts five requirements including env-loaded keys and cookie option flags
- Eval scenario bcrypt-72-byte-limit targets bcrypt password length behavior in Go
Adoption & trust: 4k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are writing Go login and session code but your agent keeps hardcoding keys, weak cookie flags, or bcrypt usage that breaks on long passwords.
Who is it for?
Solo builders on Go APIs or small services who want the coding agent to follow concrete secure patterns for sessions and passwords instead of copying unsafe examples from the prompt.
Skip if: Teams that only need automated SAST or dependency CVE dashboards without changing how the agent writes Go, or projects that are not Go backends.
When should I use this skill?
Writing or reviewing Go code that handles HTTP sessions, login, password hashing, or other auth-adjacent security-sensitive paths.
What do I get? / Deliverables
After the skill runs, handlers and session setup load secrets from the environment, use separate auth and encryption keys with safe cookie options, and apply bcrypt-aware password handling you can ship with more confiden
- Go handlers and session store configuration that avoid hardcoded secrets and use safe cookie options
- Password hashing code that accounts for bcrypt’s 72-byte limit where applicable
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Secure-session and crypto guidance is where builders catch auth mistakes that become production incidents, so the canonical shelf is Ship before release. The skill targets application-security patterns (cookies, bcrypt, handler hardening), not infra monitoring or generic testing—Security is the right subphase.
Where it fits
Implement a post-login handler with gorilla/sessions while the agent loads keys from os.Getenv and sets HttpOnly, Secure, and SameSite on the store.
Review an existing Go auth package before deploy and fix hardcoded session material and weak cookie defaults.
Wire a third-party identity flow into your Go service and ensure password hashing respects bcrypt’s 72-byte limit for long passphrases.
Patch a production auth bug by regenerating session setup with separate encryption and authentication keys instead of a single literal secret.
How it compares
Procedural Go appsec rules for your agent, not a replacement for gosec or a generic MCP security server.
Common Questions / FAQ
Who is golang-security for?
It is for solo and indie builders using AI coding agents on Go HTTP services, especially when they touch authentication, sessions, or password storage.
When should I use golang-security?
Use it in Ship when hardening auth before release, and in Build/backend while implementing login handlers, gorilla/sessions stores, or bcrypt password flows; also when an eval or review flags hardcoded session keys or missing cookie flags.
Is golang-security safe to install?
Treat it like any third-party agent skill: review the Security Audits panel on this Prism page and your repo policy before enabling it in production workflows.
SKILL.md
READMESKILL.md - Golang Security
{ "skill_name": "golang-security", "evals": [ { "id": 1, "name": "gorilla-sessions-hardcoded-key", "description": "Tests whether the model avoids hardcoding the gorilla/sessions store key and configures both auth and encryption keys", "prompt": "Write a Go HTTP handler that creates a user session using github.com/gorilla/sessions after successful login. Store the user ID and role in the session. Use a secret key 'mysecretkey' for the session store.", "trap": "Model is given a literal key 'mysecretkey' in the prompt. The trap is (1) using it literally instead of loading from env, (2) using only one key (auth only) instead of two (auth + encryption), and (3) missing SameSite/Secure/HttpOnly on the store options.", "assertions": [ {"id": "1.1", "text": "Does NOT hardcode 'mysecretkey' or any literal string as the sessions.NewCookieStore key"}, {"id": "1.2", "text": "Loads session store keys from environment variables (os.Getenv)"}, {"id": "1.3", "text": "Passes at least two keys to NewCookieStore: an authentication key AND a separate encryption key"}, {"id": "1.4", "text": "Configures store.Options with HttpOnly: true and Secure: true"}, {"id": "1.5", "text": "Sets SameSite to Strict or Lax on the store options"} ] }, { "id": 2, "name": "bcrypt-72-byte-limit", "description": "Tests awareness of bcrypt's 72-byte password limit in Go and correct long-password support", "prompt": "Write Go functions HashPassword and VerifyPassword using bcrypt. The system must support passwords up to 1000 characters long.", "trap": "Model might use bcrypt directly without handling long passwords. Go's bcrypt returns an error for passwords over 72 bytes, so a system that must support 1000-character passwords needs Argon2id/scrypt or a deliberate pre-hashing design before bcrypt.", "assertions": [ {"id": "2.1", "text": "Addresses bcrypt's 72-byte password limit explicitly (either via comment, pre-hashing, or choosing Argon2id/scrypt instead)"}, {"id": "2.2", "text": "Either pre-hashes the password with SHA-256/SHA-512 before bcrypt, OR uses Argon2id/scrypt that have no such truncation limit"}, {"id": "2.3", "text": "If using bcrypt directly without pre-hashing, handles the Go bcrypt error for passwords longer than 72 bytes"}, {"id": "2.4", "text": "Uses constant-time comparison — either bcrypt.CompareHashAndPassword or an equivalent that does not short-circuit"}, {"id": "2.5", "text": "Does NOT claim Go bcrypt silently truncates passwords; it either supports long passwords deliberately or returns a clear policy error"} ] }, { "id": 3, "name": "subtle-constant-time-length-oracle", "description": "Tests that ConstantTimeCompare is used correctly — length mismatch still leaks information", "prompt": "Write a Go HTTP middleware that validates a webhook HMAC-SHA256 signature. The incoming request has an X-Signature header containing the hex-encoded HMAC. Validate it against the expected HMAC computed from the request body and a secret key.", "trap": "Model might compute both HMACs and compare with subtle.ConstantTimeCompare — but if the lengths differ (e.g., attacker sends a 1-byte signature), ConstantTimeCompare returns 0 immediately without constant-time behavior on length. The correct approach is hmac.Equal, which is designed for this, or ensuring equal-length encoding before comparison.", "assertions": [ {"id": "3.1", "text": "Uses hmac.Equal for comparing the HMAC signatures (preferred), OR ensures both values are always the same length before calling subtle.ConstantTimeCompare"}, {"id": "3.2", "text": "Computes the expected HMAC server-side from the request body using crypto/hmac and sha256"}, {"id": "3.3", "text": "Does NOT use == or bytes.Equal for signature comparison"}, {"id": "3.4", "text": "Reads th