go-security-audit

Files (5)

• SKILL.md
• auth-and-transport.md · references/
• crypto.md · references/
• injection.md · references/
• threat-model.md · references/

SKILL.md (first lines)

# 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.

From eduardo-sl/go-agent-skills, MIT.

More from eduardo-sl/go-agent-skills