Skip to main content
skill CX Codex

go-security-audit — Claude Code skill: what it does, how to install

Audits Go code for OWASP Top 10 issues, injections, SSRF, and authentication flaws. Runs read-only checks across your repository or pull request diffs.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add eduardo-sl/go-agent-skills --skill go-security-audit -a claude-code
Open on GitHub

What go-security-audit does

The skill inspects Go code across three modes: targeted reviews of specific functions, PR diff checks, or a complete repository sweep. It searches for SQL injection, command execution, path traversal, archive decompression bombs, insecure JWT handling, and password hashing mistakes. The skill operates strictly in read-only mode, reporting vulnerabilities without editing source files.

If available, automated scanners like govulncheck, gosec, and go vet run first, after which the agent performs manual logic checks. Every finding states the file path, the line number, the exploit path from input to sink, and a patch recommendation sorted by severity. Without the Go toolchain installed, the skill cannot run standard toolchain checks, while scanners like gosec and gitleaks remain optional.

What it helps with

  • Detect SQL injections and unsafe query formatting in Go handlers
  • Verify HTTP request validation and guard against SSRF or directory traversal
  • Identify flaws in JWT verification, password hashing, and cookie configuration
  • Generate a prioritized audit report citing exact file locations and remediations

Example prompts for the agent

  • Run a security review on this Go service before deployment
  • Check our authentication middleware for JWT and session flaws
  • Audit this pull request diff for SQL injection and path traversal

How to install go-security-audit

1Skills CLI (Vercel)

npx skills add eduardo-sl/go-agent-skills --skill go-security-audit -a claude-code

2Manually: put the files in place

~/.claude/skills/go-security-audit/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/go-security-audit/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about go-security-audit

How to install go-security-audit in Claude Code?

Run npx skills add eduardo-sl/go-agent-skills --skill go-security-audit -a claude-code in your terminal.

What does go-security-audit do?

It audits Go source code for OWASP Top 10 vulnerabilities, injection flaws, and authentication mistakes. It outputs prioritized findings with exact code references and concrete fixes without modifying files.

What prerequisites does this skill require?

The Go toolchain is required. Scanners such as govulncheck, gosec, and gitleaks are optional; the skill skips missing binaries and continues with manual inspection passes.

Source text

SKILL.md · MIT
---
name: go-security-audit
description: >
  Security review for Go applications: input validation, SQL and command
  injection, SSRF, path traversal, auth, secrets, cryptography, TLS, CSRF and
  cookies, OWASP Top 10. Use when performing security reviews, checking for
  vulnerabilities, hardening Go services, or reviewing auth implementations.
  Trigger examples: "security review", "check vulnerabilities", "OWASP",
  "SQL injection", "input validation", "secrets management", "auth review".
  Not for: dependency CVEs (go-dependency-audit), concurrency safety
  (go-concurrency-review).
user-invocable: true
license: MIT
compatibility: Designed for Claude Code or similar AI coding agents working on Go projects. Requires the Go toolchain. govulncheck, gosec and gitleaks are optional. Read-only: this skill reports findings, it does not edit code.
allowed-tools: Read Glob Grep Bash(go:*) Bash(gofmt:*) Bash(govulncheck:*) Bash(gosec:*) Bash(gitleaks:*)
metadata:
  author: eduardo-sl
  version: "1.8.0"
---

# Go Security Audit

Security is not a feature — it's a property. Every line of code either
maintains it or degrades it.

## Operating Modes

Pick the mode that matches the request before starting:

- **Targeted check** — a single concern ("is this query injectable?",
  "review this auth middleware"). Apply only the relevant sections.
- **Diff audit** — audit the changed lines of a PR or working tree for
  every concern below.
- **Full audit** (default for "security review the service") — sweep the
  codebase using the parallel passes in "Auditing Large Codebases".

## Research Before Reporting

- Trace each suspicious sink back to an entry point (go-semantic-tools:
  references, call hierarchy). A sink fed only by constants or internal
  values is not a vulnerability.
- Check what upstream already enforces — type parsing, allowlists,
  middleware. It lowers severity; it does not delete the finding.
- 🔴 BLOCKER: exploitable today by whoever controls the input. 🟡 WARNING:
  needs a second failure or a privileged caller. 🟢 SUGGESTION: hardening.
- Every finding states file:line, the entry → sink path, a one-sentence
  exploit, and the fix.

Trust boundaries, STRIDE checks and the finding template:
`references/threat-model.md`.

## Run the Scanners First

Before manual review, run the automated scanners and fold their output
into the findings (skip any that is not installed and note it):

```bash
govulncheck ./...       # known CVEs actually reachable from your code
gosec ./...             # static analysis for insecure patterns
go vet ./...            # includes some security-relevant checks
```

Scanners find the known patterns; the manual passes below find the
logic flaws they cannot.

## Auditing Large Codebases

Each numbered section below is an independent audit pass. For codebases
beyond ~20 files:

1. Locate the attack surface first: HTTP/gRPC handlers, CLI entry
   points, queue consumers, and anything parsing external input.
2. Run one pass per concern: (a) input validation + SQL and other
   injection (command, SSRF, paths, archives, templates),
   (b) authentication/authorization, (c) secrets + crypto,
   (d) TLS + security headers + rate limiting, (e) logging hygiene.
3. If your environment supports delegating work to parallel sub-agents
   or tasks, assign each pass to one — the passes don't overlap.
   Otherwise run them sequentially.
4. Every finding must cite `file.go:line`, the vulnerable input path,
   and a concrete fix. Aggregate into one report sorted by severity.

Detailed reference material, loaded on demand:

- `references/injection.md` — boundary validation, sanitization,
  parameterized and dynamic queries, command injection, SSRF, path
  traversal, archives, templates, open redirects, log injection.
- `references/auth-and-transport.md` — passwords, JWT, authorization
  middleware, secrets, headers, cookies, CSRF, CORS, TLS, rate limiting.
- `references/threat-model.md` — trust boundaries, STRIDE per boundary,
  severity definitions, finding template.
- `references/crypto.md` — randomness, constant-time comparison, password
  hashing, AEAD encryption, hashes and KDFs, signatures, FIPS mode.

Read a reference file only when the section below is not enough.

## 1. Input Validation

Validate at the boundary, before the value reaches any business code:

- Cap the request body with `http.MaxBytesReader` — an unbounded decoder is
  a memory exhaustion vector.
- Decode into a typed struct, then validate it. A decode that succeeds is not
  a value that is valid.
- Reject rather than repair. Reply with the status code, not with the
  internal error text.
- Sanitize anything rendered back as HTML (`bluemonday`), parse emails with
  `net/mail`, and reject URLs whose scheme is not `http`/`https`.

Examples in `references/injection.md`.

## 2. SQL Injection Prevention

ALWAYS pass values as query parameters. There is no safe amount of string
concatenation:

```go
// ✅ Good — parameterized
row := db.QueryRowContext(ctx, "SELECT id, name FROM users WHERE email = $1", email)

// ❌ CRITICAL — SQL injection
query := "SELECT * FROM users WHERE email = '" + email + "'"
query := fmt.Sprintf("SELECT * FROM users WHERE id = %s", id)
```

Dynamic filters are built by appending placeholders (`$1`, `$2`, …) and
collecting the values into an `args` slice — never by interpolating the value
itself. Table and column names cannot be parameterized: allowlist them
against a fixed set.

Examples in `references/injection.md`.

## 3. Injection Beyond SQL

- **Command** — `exec.CommandContext(ctx, "tool", "--", arg)`: no shell,
  `--` before input. Input never selects the binary.
- **SSRF** — server-side fetches of caller URLs go through a client whose
  dialer rejects loopback, private, link-local and metadata addresses
  *after* DNS resolution, with proxies disabled.
- **Paths** — `os.Root` (Go 1.24+) for any user-influenced path;
  `filepath.Join` + `HasPrefix` misses symlinks.
- **Archives** — reject non-local entry names (zip slip), cap entry count,
  declared size and bytes actually read (decompression bombs).
- **HTML** — `html/template` only; `template.HTML(input)` disables escaping.
- **Redirects** — only same-site relative paths or allowlisted hosts.

Examples in `references/injection.md`.

## 4. Authentication & Authorization

- Hash passwords with `bcrypt` (or argon2id). NEVER store plaintext, NEVER
  use MD5/SHA — they are fast, which is the wrong property here.
- Compare with `bcrypt.CompareHashAndPassword`, which is constant-time.
  Hand-rolled comparisons leak timing.
- Validate every JWT claim that matters: signature with the expected
  algorithm, `exp`, `iss`, `aud`. Reject `alg: none` and never hardcode the
  signing key.
- Authorize per request in middleware, reading the identity from the request
  context. An endpoint with no role check is a public endpoint.
- Check ownership, not only role: a valid token for user A must not read
  user B's row.

Examples in `references/auth-and-transport.md`.

## 5. Secrets Management

- 🔴 NEVER hardcode secrets, tokens, or API keys in source code
- 🔴 NEVER commit secrets to git (even in "test" files)
- 🔴 NEVER log secrets, tokens, or passwords

Read them from the environment or a secrets manager, keep `.env`, `*.pem`,
`*.key` and `credentials.json` in `.gitignore`, and run `gitleaks detect` in
CI so a leak fails the build instead of ageing in history.

Examples in `references/auth-and-transport.md`.

## 6. Cryptography and Randomness

- `crypto/rand` for anything that must not be guessed — tokens (`rand.Text`,
  Go 1.24+), nonces, salts. `math/rand` never.
- Compare secrets with `subtle.ConstantTimeCompare` / `hmac.Equal`.
- Encrypt with AES-GCM via `cipher.NewGCMWithRandomNonce` (Go 1.24+), so
  no nonce is ever reused. No ECB, no unauthenticated modes.
- SHA-256/SHA-3 for integrity, HMAC for authentication, HKDF to derive keys,
  Ed25519 for signatures. MD5 and SHA-1 never protect anything.
- FIPS environments build with `GOFIPS140` (Go 1.24+).

Examples in `references/crypto.md`.

## 7. Transport, Headers and Rate Limiting

- Set `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, a
  `Content-Security-Policy`, and HSTS on every response.
- TLS: raise `MinVersion` to `tls.VersionTLS12` (or 1.3) and keep Go's
  default cipher suites — a hand-picked list only goes stale.
  NEVER `InsecureSkipVerify: true` outside a test.
- Rate limit auth endpoints, public APIs, and anything expensive, keyed per
  client rather than globally.
- Browser-facing: session cookies `Secure`, `HttpOnly`, `SameSite`, with a
  `__Host-` prefix; CSRF via `http.CrossOriginProtection` (Go 1.25+), with
  no state change on GET; CORS from an exact-origin allowlist, never `*`
  on authenticated APIs.
- pprof and other debug handlers only on an internal listener.

Examples in `references/auth-and-transport.md`.

## 8. Logging Security

Log the identifier, never the credential:

```go
// ❌ CRITICAL
log.Printf("user login: email=%s password=%s", email, password)
log.Printf("request body: %v", req) // may contain secrets

// ✅ Good — redacted
logger.Info("auth completed", slog.String("user_id", userID))
```

Whole-struct logging is the common leak: a `%v` on a request struct prints
whatever field someone adds next sprint.

## Security Audit Checklist

### Critical (🔴 BLOCKER)
- No SQL injection vectors (all queries parameterized)
- No shell invocation with input; no user-controlled path outside an `os.Root`
- Server-side fetches of user URLs blocked from private/metadata addresses
- No hardcoded secrets/keys/tokens
- No plaintext password storage
- No `math/rand` for tokens, IDs or nonces; no `==` on secrets
- No disabled TLS certificate verification
- Request body size limited
- JWT signature verified, `alg: none` rejected

### Important (🟡 WARNING)
- Input validation on all external data
- Rate limiting on auth and public endpoints
- Security headers set on all responses
- CORS configured restrictively
- Error messages don't leak internals
- Audit logging for auth events

### Recommended (🟢 SUGGESTION)
- `govulncheck` in CI pipeline
- `gitleaks` for secret scanning
- Structured logging with redaction
- Dependency pinning with verified checksums

© eduardo-sl · MIT · eduardo-sl/go-agent-skills

Similar skills

All skills for Security →

From the same set34

git-commit A skill that makes your agent write commit messages in Conventional Commits style: typed, scoped, imperative. Useful when the repo history has turned into noise. CX Codex +1 ★ 83repo stars go-test-table-driven Guides coding agents when writing and refactoring Go table-driven tests. It enforces clean test structs, clear subtest names, and lean loop bodies. CX Codex +1 ★ 83repo stars go-test-quality Get guidance on Go test design, coverage checks, and concurrency tests. Use it when adding tests, reviewing existing ones, or investigating flaky behavior. CX Codex +1 ★ 83repo stars go-troubleshooting A skill that walks the agent through Go runtime diagnosis: panics, deadlocks, goroutine and memory leaks, race reports. Useful when a program crashes or hangs and the cause is unclear. CX Codex +1 ★ 83repo stars go-performance-review Find Go performance bottlenecks and check proposed changes with benchmarks and profiles. Use it to review hot paths or reduce allocations. CX Codex +1 ★ 83repo stars go-observability A skill that sets conventions for Go service telemetry: structured logs with log/slog, OpenTelemetry traces and metrics, SLO alerts. Useful once a service runs in production and you need to see what it does. CX Codex +1 ★ 83repo stars go-defensive-coding Stops panics, slice aliasing, and subtle runtime bugs in Go: typed-nil interfaces, numeric truncation, and loop defer hazards. CX Codex +1 ★ 83repo stars go-concurrency-review Review Go concurrency or build safer concurrent code with checks for goroutine lifecycles, channels, shared state, and context cancellation. CX Codex +1 ★ 83repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor