Security best practices for Golang — injection (SQL, command, XSS), cryptography, filesystem safety, network security, cookies, secrets, memory safety, logging. Apply when writing, reviewing, or auditing Go code for security, or on risky code involving crypto, I/O, secrets, user input, auth.
Instrucciones de origen · Vista previa de solo lectura
name
golang-security
description
Security best practices for Golang — injection (SQL, command, XSS), cryptography, filesystem safety, network security, cookies, secrets, memory safety, logging. Apply when writing, reviewing, or auditing Go code for security, or on risky code involving crypto, I/O, secrets, user input, auth.
user-invocable
true
license
MIT
compatibility
Designed for Claude Code, Codex or similar harness, and for projects using Golang.
Persona: You are a senior Go security engineer. You apply security thinking both when auditing existing code and when writing new code — threats are easier to prevent than to fix.
Thinking mode: Reason as thoroughly as possible for security audits and vulnerability analysis — security bugs hide in subtle interactions and deep reasoning catches what surface-level review misses. On Claude Code, use ultrathink to trigger extended thinking explicitly.
Orchestration mode: Fan out the five vulnerability-domain sub-agents described in Audit mode as a fan-out-then-synthesize workflow for a full-codebase security audit. Parallelism covers more attack surface per pass; the synthesis step deduplicates findings and ranks them by severity. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.
Modes:
Review mode — reviewing a PR for security issues. Start from the changed files, then trace call sites and data flows into adjacent code — a vulnerability may live outside the diff but be triggered by it. Sequential.
Audit mode — full codebase security scan. Launch up to 5 parallel sub-agents, each covering an independent vulnerability domain: (1) injection patterns, (2) cryptography and secrets, (3) web security and headers, (4) authentication and authorization, (5) concurrency safety and dependency vulnerabilities. Aggregate findings, score with DREAD, and report by severity. A large audit produces many independent findings — apply each fix/improvement in its own isolated worktree, so one fix = one worktree = one focused, reviewable, independently revertible PR, instead of one large mixed-concern change.
Coding mode — use when writing new code or fixing a reported vulnerability. Follow the skill's sequential guidance. Optionally launch a background agent to grep for common vulnerability patterns in newly written code while the main agent continues implementing the feature.
Dependencies:
govulncheck: go install golang.org/x/vuln/cmd/govulncheck@latest
Go Security
Overview
Security in Go follows the principle of defense in depth: protect at multiple layers, validate all inputs, use secure defaults, and leverage the standard library's security-aware design. Go's type system and concurrency model provide some inherent protections, but vigilance is still required.
Security Thinking Model
Before writing or reviewing code, ask three questions:
What are the trust boundaries? — Where does untrusted data enter the system? (HTTP requests, file uploads, environment variables, database rows written by other services)
What can an attacker control? — Which inputs flow into sensitive operations? (SQL queries, shell commands, HTML output, file paths, cryptographic operations)
What is the blast radius? — If this defense fails, what's the worst outcome? (Data leak, RCE, privilege escalation, denial of service)
Severity Levels
Level
DREAD
Meaning
Critical
8-10
RCE, full data breach, credential theft — fix immediately
High
6-7.9
Auth bypass, significant data exposure, broken crypto — fix in current sprint
Medium
4-5.9
Limited exposure, session issues, defense weakening — fix in next sprint
Low
1-3.9
Minor info disclosure, best-practice deviations — fix opportunistically
Before flagging a security issue, trace the full data flow through the codebase — don't assess a code snippet in isolation.
Trace the data origin — follow the variable back to where it enters the system. Is it user input, a hardcoded constant, or an internal-only value?
Check for upstream validation — look for input validation, sanitization, type parsing, or allow-listing earlier in the call chain.
Examine the trust boundary — if the data never crosses a trust boundary (e.g., internal service-to-service with mTLS), the risk profile is different.
Read the surrounding code, not just the diff — middleware, interceptors, or wrapper functions may already provide a layer of defense.
Severity adjustment, not dismissal: upstream protection does not eliminate a finding — defense in depth means every layer should protect itself. But it changes severity: a SQL concatenation reachable only through a strict input parser is medium, not critical. Always report the finding with adjusted severity and note which upstream defenses exist and what would happen if they were removed or bypassed.
When downgrading or skipping a finding: add a brief inline comment (e.g., // security: SQL concat safe here — input is validated by parseUserID() which returns int) so the decision is documented, reviewable, and won't be re-flagged by future audits.
Threat Modeling (STRIDE)
Apply STRIDE to every trust boundary crossing and data flow in your system: Spoofing (authentication), Tampering (integrity), Repudiation (audit logging), Information Disclosure (encryption), Denial of Service (rate limiting), Elevation of Privilege (authorization). Score each threat using DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) to prioritize remediation — Critical (8-10) demands immediate action.
For the full methodology with Go examples, DFD trust boundaries, DREAD scoring, and OWASP Top 10 mapping, see Threat Modeling Guide.
Quick Reference
Severity
Vulnerability
Defense
Standard Library Solution
Critical
SQL Injection
Parameterized queries separate data from code
database/sql with ? placeholders
Critical
Command Injection
Pass args separately, never via shell concatenation
exec.Command with separate args
High
XSS
Auto-escaping renders user data as text, not HTML/JS
html/template, text/template
High
Path Traversal
Scope untrusted file access to an allowed root
Go 1.24+: use os.Root. Pre-Go 1.24: use filepath.IsLocal + filepath.Rel + separator-aware checks; never rely on filepath.Clean + strings.HasPrefix alone.
For the full security review checklist organized by domain (input handling, database, crypto, web, auth, errors, dependencies, concurrency), see Security Review Checklist — a comprehensive checklist for code review with coverage of all major vulnerability categories.
Tooling & Verification
Static Analysis & Linting
Security-relevant linters: bodyclose, sqlclosecheck, nilerr, errcheck, govet, staticcheck. See the samber/cc-skills-golang@golang-lint skill for configuration and usage.
For deeper security-specific analysis:
# Go security checker (SAST)
go get -tool github.com/securego/gosec/v2/cmd/gosec@latest
go tool gosec ./...
# Vulnerability scanner — see golang-dependency-management for full govulncheck usage
go get -tool golang.org/x/vuln/cmd/govulncheck@latest
go tool govulncheck ./...
To check the known CVEs of a specific module or version without scanning the whole tree (e.g. when vetting a dependency on pkg.go.dev), → See samber/cc-skills-golang@golang-pkg-go-dev skill.
Security Testing
# Race detector
go test -race ./...
# Fuzz testing
go test -fuzz=Fuzz
Common Mistakes
Severity
Mistake
Fix
High
math/rand for tokens
Output is predictable — attacker can reproduce the sequence. Use crypto/rand
Critical
SQL string concatenation
Attacker can modify query logic. Parameterized queries keep data and code separate
