danielyan-consulting/dancon-secure-coder-go
dancon-secure-coder-go/SKILL.md
ALWAYS use this skill whenever generating, writing, reviewing, editing, or modifying Go (.go) code in any context. This skill ensures all generated Go code avoids the CWE Top 25 2025 weaknesses that apply to Go, and that every piece of Go code includes appropriate input validation, thorough error handling, and safe error messages that never leak passwords, tokens, API keys, or other secrets. The Go `unsafe` package is absolutely prohibited and must never appear in generated code. Trigger on ANY Go code generation -- there are no exceptions. Even trivial examples and one-off snippets must follow these rules. If the user asks for Go code, read this skill first.
development
Updated Apr 25, 2026
$ install --global
skillsauthnpx skillsauth add danielyan-consulting/skills dancon-secure-coder-goInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 25, 2026, 8:00 PM120.8s4 files scanned
SKILL.md
- name:
- dancon-secure-coder-go
- description:
- >
Secure Go Code Generator -- CWE Top 25 2025
By Danielyan Consulting: https://danielyan.consulting
Mandatory for ALL Go code generation. Apply these rules before writing any Go code.
Quick-Reference Rules
This table is the primary lookup. For edge cases or unfamiliar CWEs, read the relevant reference file.
| CWE | Rule | Detail |
|---------|---------------------------------------------------------------|--------|
| CWE-79 | html/template only; never concatenate user input into HTML | [cwe-web.md] |
| CWE-89 | Parameterised queries only; never string-build SQL | [cwe-web.md] |
| CWE-352 | CSRF tokens on all state-changing endpoints | [cwe-web.md] |
| CWE-862/863/284/639 | Derive identity from session; check ownership server-side | [cwe-web.md] |
| CWE-306 | Authentication middleware on every non-public endpoint | [cwe-web.md] |
| CWE-434 | http.DetectContentType + MIME allowlist; limit size | [cwe-web.md] |
| CWE-918 | Allowlist target hosts; block private IPs; resolve DNS first | [cwe-web.md] |
| CWE-22 | filepath.Abs + strings.HasPrefix against base dir | [cwe-system.md] |
| CWE-78/77 | exec.Command(name, arg1, arg2); never shell strings | [cwe-system.md] |
| CWE-94 | Never let user input define template content or plugin paths | [cwe-system.md] |
| CWE-476 | Nil-check pointers/interfaces; comma-ok all type assertions | [cwe-system.md] |
| CWE-502 | io.LimitReader + DisallowUnknownFields; concrete structs; no gob from untrusted | [cwe-system.md] |
| CWE-20 | Validate type, length, range, format at boundary; allowlists | [cwe-system.md] |
| CWE-200 | Generic errors to clients; log detail server-side; never expose err.Error() | [cwe-system.md] |
| CWE-770 | http.Server timeouts; MaxBytesReader; bound goroutines; crypto/rand for secrets | [cwe-system.md] |
Core Principles
- Validate all input at the boundary before use.
- Handle every error -- no
_for error returns. - Never leak secrets in errors -- no passwords, tokens, keys, or connection strings in error messages or logs.
- Defence in depth -- multiple layers; never a single check.
- Least privilege -- request only what is needed.
- 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:
| File | Contents |
|------|----------|
| references/cwe-web.md | CWE-79, 89, 352, 862/863/284/639, 306, 434, 918: web-facing vulnerabilities with Go-idiomatic ALWAYS/NEVER rules and one example each |
| references/cwe-system.md | CWE-22, 78/77, 94, 476, 502, 20, 200, 770: system-level and data-handling vulnerabilities with Go-idiomatic ALWAYS/NEVER rules and one example each |
| references/error-and-input.md | Mandatory error handling rules (wrapping, secrets, logging, cleanup) and input validation patterns (HTTP handlers, CLI, libraries) |
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, nounsafe.*functions, noreflect.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.ServerhasReadTimeout,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/randfor 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/gobfrom untrusted input - [ ] JSON decoding uses
io.LimitReaderand validates fields
Related Skills
danielyan-consulting/dancon-secure-cfworker
development
VerifiedTrustedCommunity
Generate secure Cloudflare Worker code in TypeScript that avoids all weaknesses covered by OWASP Top 10 (2025) and CWE Top 25 (2025). Use this skill whenever the user asks to create, write, scaffold, or generate a Cloudflare Worker, CF Worker, edge function, or serverless function on Cloudflare. Also trigger when the user asks to build a secure API, secure endpoint, secure webhook handler, or any TypeScript code targeting the Workers runtime. Always use this skill over generic code generation when the target is Cloudflare Workers.
SKILL.mdUpdated Apr 25, 2026
danielyan-consulting/dancon-owasp10-review
development
VerifiedTrustedCommunity
Parallel OWASP Top 10:2025 security review of a web application codebase using 10 specialist agents. Trigger whenever the user asks for a security review, security audit, OWASP review, vulnerability assessment, code security scan, or threat analysis of a web app codebase. Also trigger on mentions of "OWASP Top 10", "security vulnerabilities", "code audit", "AppSec", or requests to check code for injection, XSS, access control, auth, or crypto issues. Trigger for casual requests like "is my code secure?", "check for vulnerabilities", or "any security issues?". Launches 10 parallel agents (one per OWASP category) producing a report with context-sensitive remediations. Secrets found are flagged but always shown as REDACTED.
SKILL.mdUpdated Apr 25, 2026
danielyan-consulting/dancon-input-validation
development
VerifiedTrustedCommunity
Scan a codebase to find every instance of missing or inadequate input validation for data from external or untrusted sources, then propose context-appropriate fixes using whitelisting, regex, type coercion, size/range checks, encoding, etc. Use whenever the user asks to audit, review, or harden input validation in any codebase regardless of language. Trigger on: "check my inputs", "find injection risks", "validate user input", "security audit inputs", "input sanitisation review", "taint analysis", "harden my API inputs", "check for missing validation", "is my app safe from injection?". Platform- and language-independent.
SKILL.mdUpdated Apr 25, 2026
danielyan-consulting/dancon-error-handling
development
VerifiedTrustedCommunity
Scan a codebase for missing or inadequate security-aware error handling and propose context-appropriate fixes. Use when the user asks to audit, review, scan, or check error handling in code; mentions "error handling audit", "exception handling review", "security error handling"; uploads a codebase wanting a security review focused on error handling; or says things like "find missing try/catch", "check for unhandled exceptions", "detect empty catch blocks", "identify information leakage in error messages", or "make my error handling more secure".
SKILL.mdUpdated Apr 25, 2026