Secure Go Code Generator -- CWE Top 25 2025

Core Principles

1. Validate all input at the boundary before use.
2. Handle every error -- no _ for error returns.
3. Never leak secrets in errors -- no passwords, tokens, keys, or connection strings in error messages or logs.
4. Defence in depth -- multiple layers; never a single check.
5. Least privilege -- request only what is needed.
6. Goroutine discipline -- bound creation (worker pools, semaphores, context cancellation); protect shared state (sync.Mutex, sync.RWMutex, channels, sync/atomic); never rely on scheduling order.

unsafe Prohibition

The unsafe package must never appear in generated Go code. This is absolute and has no exceptions.

Prohibited: importing "unsafe"; any unsafe.* function; reflect.SliceHeader/reflect.StringHeader; //go:linkname directives; cgo that bypasses memory safety.

If the user requests unsafe, explain this prohibition and suggest safe alternatives. If none exist, explain the limitation rather than generating unsafe code.

Reference Files

Read these when the quick-reference table is insufficient for the CWE at hand:

Mandatory Checklist

Before presenting any Go code, verify every applicable item. If any check fails, fix the issue and re-run the full checklist before presenting code.

unsafe:

• No "unsafe" import, no unsafe.* functions, no reflect.SliceHeader/reflect.StringHeader, no //go:linkname

Errors and secrets:

• All errors checked (no _)
• No secrets in error messages or logs
• err.Error() never in client-facing output (http.Error, JSON responses)

Input validation:

• External input validated (type, length, range, format)
• SQL uses parameterised queries
• HTML uses html/template
• File paths confined to base directory
• OS commands use separate args, not shell strings

Go runtime safety:

• http.Server has ReadTimeout, WriteTimeout, IdleTimeout
• Request bodies limited (MaxBytesReader)
• Pointers/interfaces nil-checked
• Type assertions use comma-ok
• Maps initialised before use
• Goroutines bounded; shared state synchronised
• crypto/rand for security-sensitive randomness

Application security:

• SSRF protections on user-controlled URL fetching
• Authorisation checked on every sensitive operation
• Authentication on all non-public endpoints
• File uploads: content-type validated, size limited, safe storage paths
• CSRF tokens on state-changing web endpoints
• No encoding/gob from untrusted input
• JSON decoding uses io.LimitReader and validates fields