Golang Security

Samuel BertheCommunityCreated by samberDistributed by Samuel Berthe

Skill
Guidelines
Security
MIT
Medium risk

From the author

Security best practices and vulnerability prevention for Golang — injection (SQL, command, XSS), cryptography, path traversal, SSRF and HTTP security headers, cookies, secrets management, memory safety, PII in logs, STRIDE/DREAD threat modeling, plus `gosec` SAST, race detection, and fuzz testing. Apply when writing, reviewing, or auditing Go code for security, or when touching crypto, file or network I/O, secrets, user input, or authentication. Not for non-exploitable defensive bugs such as nil panics or slice aliasing (→ See `samber/cc-skills-golang@golang-safety` skill), dependency vulnerability scanning with govulncheck (→ See `samber/cc-skills-golang@golang-dependency-management` skill), or wiring security scanners into CI pipelines (→ See `samber/cc-skills-golang@golang-continuous-integration` skill).

— the description by samber

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The golang-security skill provides a structured approach to identifying and preventing vulnerabilities in Go applications. It acts as a senior security engineer persona, offering guidance on secure coding, threat modeling using STRIDE/DREAD, and deep-dive auditing techniques. The skill covers critical domains including injection prevention, cryptography, web security, and concurrency safety, while providing a clear methodology for tracing data flows and assessing trust boundaries.

What it does

Provides a structured security review checklist for Go applications.
Offers guidance on threat modeling using STRIDE and DREAD scoring.
Supports full codebase security audits through parallelized sub-agent orchestration.
Includes best practices for cryptography, input validation, and memory safety.
Integrates with standard Go security tools like gosec and govulncheck.
Defines clear severity levels for prioritizing security findings.

When to use it

During code reviews to identify potential security vulnerabilities in PRs.
When performing a full security audit of a Go codebase.
When writing new Go code that handles sensitive data, authentication, or network I/O.
When assessing the security posture of cryptographic implementations or file system operations.

Advantages

Promotes a defense-in-depth security architecture.
Reduces the risk of common vulnerabilities like SQL injection and path traversal.
Standardizes security reporting with DREAD scoring.
Facilitates isolated, reviewable fixes for identified security issues.
Encourages proactive security thinking at trust boundaries.

Usage examples

“Perform a security audit on this repository.”: The agent will initiate a multi-agent scan across five vulnerability domains, aggregate findings, score them by severity, and provide a prioritized remediation plan.
“Review this PR for potential SQL injection vulnerabilities.”: The agent will trace data flows from user input to database queries, checking for proper parameterization and upstream validation.
“How should I handle file paths securely in Go?”: The agent will provide guidance on using os.Root or filepath.IsLocal to prevent path traversal, along with code examples.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/samber/golang-security/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip golang-security.zip -d .agents/skills

Documentation by samber

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

Levels align with DREAD scoring.

Research Before Reporting

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.
Medium	Timing Attacks	Constant-time comparison avoids byte-by-byte leaks	`crypto/subtle.ConstantTimeCompare`
High	Crypto Issues	Use vetted algorithms; never roll your own	`crypto/aes`, `crypto/rand`
Medium	HTTP Security	TLS + security headers prevent downgrade attacks	`net/http`, configure TLSConfig
Low	Missing Headers	HSTS, CSP, X-Frame-Options prevent browser attacks	Security headers middleware
Medium	Rate Limiting	Rate limits prevent brute-force and resource exhaustion	`golang.org/x/time/rate`, server timeouts
High	Race Conditions	Protect shared state to prevent data corruption	`sync.Mutex`, channels, avoid shared state

Detailed Categories

For complete examples, code snippets, and CWE mappings, see:

Cryptography — Algorithms, key derivation, TLS configuration.
Injection Vulnerabilities — SQL, command, template injection, XSS, SSRF.
Filesystem Security — Path traversal, zip bombs, file permissions, symlinks.
Network/Web Security — SSRF, open redirects, HTTP headers, timing attacks, session fixation.
Cookie Security — Secure, HttpOnly, SameSite flags.
Third-Party Data Leaks — Analytics privacy risks, GDPR/CCPA compliance.
Memory Safety — Integer overflow, memory aliasing, unsafe usage.
Secrets Management — Hardcoded credentials, env vars, secret managers.
Logging Security — PII in logs, log injection, sanitization.
Threat Modeling Guide — STRIDE, DREAD scoring, trust boundaries, OWASP Top 10.
Security Architecture — Defense-in-depth, Zero Trust, auth patterns, rate limiting, anti-patterns.

Code Review Checklist

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
Critical	`exec.Command("bash -c")`	Shell interprets metacharacters (`;`, `\|`, `). Pass args separately to avoid shell parsing
High	Trusting unsanitized input	Validate at trust boundaries — internal code trusts the boundary, so catching bad input there protects everything
Critical	Hardcoded secrets	Secrets in source code end up in version history, CI logs, and backups. Use env vars or secret managers
Medium	Comparing secrets with `==`	`==` short-circuits on first differing byte, leaking timing info. Use `crypto/subtle.ConstantTimeCompare`
Medium	Returning detailed errors	Stack traces and DB errors help attackers map your system. Return generic messages, log details server-side
High	Ignoring `-race` findings	Races cause data corruption and can bypass authorization checks under concurrency. Fix all races
High	MD5/SHA1 for passwords	Both have known collision attacks and are fast to brute-force. Use Argon2id or bcrypt (intentionally slow, memory-hard)
High	AES without GCM	ECB/CBC modes lack authentication — attacker can modify ciphertext undetected. GCM provides encrypt+authenticate
Medium	Binding to 0.0.0.0	Exposes service to all network interfaces. Bind to specific interface to limit attack surface

Security Anti-Patterns

Severity	Anti-Pattern	Why It Fails	Fix
High	Security through obscurity	Hidden URLs are discoverable via fuzzing, logs, or source	Authentication + authorization on all endpoints
High	Trusting client headers	`X-Forwarded-For`, `X-Is-Admin` are trivially forged	Server-side identity verification
High	Client-side authorization	JavaScript checks are bypassed by any HTTP client	Server-side permission checks on every handler
High	Shared secrets across envs	Staging breach compromises production	Per-environment secrets via secret manager
Critical	Ignoring crypto errors	`_, _ = encrypt(data)` silently proceeds unencrypted	Always check errors — fail closed, never open
Critical	Rolling your own crypto	Custom encryption hasn't been analyzed by cryptographers	Use `crypto/aes` GCM, `golang.org/x/crypto/argon2`

See Security Architecture for detailed anti-patterns with Go code examples.

Cross-References

See samber/cc-skills-golang@golang-database, samber/cc-skills-golang@golang-safety, samber/cc-skills-golang@golang-observability, samber/cc-skills-golang@golang-continuous-integration skills.

→ See samber/cc-skills-golang@golang-continuous-integration skill for automated AI-driven code review in CI using these guidelines

Additional Resources

Files

ATTRIBUTION.mdAdded by AutoGineer902 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md14.0 KiB
evals/evals.json49.0 KiB
references/architecture.md10.4 KiB
references/checklist.md4.0 KiB
references/cookies.md4.8 KiB
references/cryptography.md11.0 KiB
references/filesystem.md6.8 KiB
references/injection.md7.3 KiB
references/logging.md3.9 KiB
references/memory-safety.md5.1 KiB
references/network.md6.3 KiB
references/secrets.md4.8 KiB
references/third-party.md4.9 KiB
references/threat-modeling.md8.4 KiB

references/third-party.md

Third-Party Data Leak Rules

Third-party monitoring and analytics services can inadvertently transmit sensitive user data to external systems.

Rules:

PII MUST be filtered before sending to third-party services.
Error tracking MUST NOT receive raw user data — use BeforeSend hooks to redact.

Overview
Common Vulnerable Services
Error Tracking Services — Medium
Analytics/Monitoring Services — Medium
Data Filtering Layer
Review Checklist
CWE References

Overview

These rules detect Go code that sends data to third-party services. Always review what data is being transmitted and ensure it complies with privacy regulations (GDPR, CCPA, etc.).

Common Vulnerable Services

Service	Risk
Airbrake	Error tracking - sensitive data may be sent
Bugsnag	Error tracking - sensitive data exposure
Sentry	Error tracking - sensitive data in breadcrumbs/events
Rollbar	Error tracking - sensitive data leaks
Honeybadger	Error tracking - sensitive data leaks
New Relic	Monitoring - sensitive data exposure
Datadog	Monitoring - sensitive data in telemetry
OpenTelemetry	Observability - sensitive data in traces/metrics
Google Analytics	Analytics - PII tracking risks
Algolia	Search API - data exfiltration risks
Segment	Analytics - PII tracking risks
BigQuery	Analytics - sensitive data in queries
ClickHouse	Database - sensitive data queries
Elasticsearch	Search engine - sensitive data in queries

Error Tracking Services — Medium

Bad:

import "github.com/getsentry/sentry-go"

sentry.CaptureException(err) // DON'T: Captures full request context

Good:

sentry.Init(sentry.ClientOptions{
    Dsn: "https://[email protected]/123",
    RequestHeaders: []string{"Accept", "User-Agent"},
    BeforeSend: func(event *sentry.Event, hint *sentry.EventHint) *sentry.Event {
        // Remove sensitive headers
        if event.Request != nil {
            delete(event.Request.Headers, "Authorization")
            delete(event.Request.Headers, "Cookie")
        }
        return event
    },
})

Analytics/Monitoring Services — Medium

Bad:

analytics.Track("user_signed_up", analytics.Properties{
    "email":   user.Email,   // DON'T: PII!
    "phone":   user.Phone,   // DON'T: PII!
    "address": user.Address, // DON'T: PII!
})

Good:

analytics.Track("user_signed_up", analytics.Properties{
    "user_id":        user.ID,          // OK: Internal identifier
    "plan":           user.Plan,        // OK: Business data
    "country":        user.CountryCode, // OK: Non-identifying
})

// Hash PII for correlation
func hashEmail(email string) string {
    h := sha256.New()
    h.Write([]byte(email))
    return hex.EncodeToString(h.Sum(nil))[:8]
}

Data Filtering Layer

type DataFilter struct {
    sensitiveFields []string
}

func NewDataFilter() *DataFilter {
    return &DataFilter{
        sensitiveFields: []string{
            "password", "token", "secret", "key", "email",
            "phone", "address", "ssn", "credit_card", "bank_account",
        },
    }
}

func (f *DataFilter) Filter(data map[string]interface{}) map[string]interface{} {
    result := make(map[string]interface{})
    for k, v := range data {
        keyLower := strings.ToLower(k)
        isSensitive := false
        for _, field := range f.sensitiveFields {
            if strings.Contains(keyLower, field) {
                isSensitive = true
                break
            }
        }
        if isSensitive {
            result[k] = "[REDACTED]"
        } else {
            result[k] = v
        }
    }
    return result
}

Review Checklist

Before integrating any third-party service:

[ ] Identify what data is being sent
[ ] Remove any PII/PHI from transmitted data
[ ] Review data residency requirements
[ ] Implement data retention policies
[ ] Set up data export logging/auditing
[ ] Configure error handling to avoid data exposure
[ ] Review terms of service for data usage
[ ] Implement user consent management
[ ] Support data deletion requests
[ ] Conduct regular data flow audits

CWE References

CWE-200: Exposure of Sensitive Information
CWE-359: Exposure of Private Personal Information
CWE-201: Information Exposure Through Sent Data

Requirements and compatibility

Written for: Claude Code, OpenAI Codex

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Claude Code frontmatter

The author says: Designed for Claude Code, Codex or similar harness, and for projects using Golang.

Security

What our scanner noticed· Medium risk

References to credential files

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

samber

Publisher

Samuel Berthe (Community)

Distributed by

Samuel Berthe

Source

samber/cc-skills-golang · skills/golang-security · commit bb1d43d

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by samber or Samuel Berthe.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download golang-security.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by samber

Go Security

Overview

Security Thinking Model

Severity Levels

Research Before Reporting

Threat Modeling (STRIDE)

Quick Reference

Detailed Categories

Code Review Checklist

Tooling & Verification

Static Analysis & Linting

Security Testing

Common Mistakes

Security Anti-Patterns

Cross-References

Additional Resources

Files

references/third-party.md

Third-Party Data Leak Rules

Table of Contents

Overview

Common Vulnerable Services

Error Tracking Services — Medium

Analytics/Monitoring Services — Medium

Data Filtering Layer

Review Checklist

CWE References

Requirements and compatibility

Security

Attribution and licence

Related skills

Security Audit

Sast Configuration

Firmware Analyst

Policy Enforcer

Backend Development Security Auditor

Memory Forensics

Download ZIP