Input Validation & Injection Defense

One bug, many names

SQL injection, command injection, XSS, LDAP injection, path traversal, header injection — they’re the same vulnerability wearing different clothes: untrusted data crosses into a context where it’s interpreted as code or control.

graph TD
U["untrusted input"] --> MIX{"mixed into…"}
MIX -->|SQL string| SQLI["SQL injection"]
MIX -->|shell command| CMDI["command injection"]
MIX -->|HTML markup| XSS["cross-site scripting"]
MIX -->|file path| TRAV["path traversal"]
SQLI --> FIX["FIX: separate data from code"]
CMDI --> FIX
XSS --> FIX
TRAV --> FIX

The cure is structural and the same everywhere: keep data out of the code channel. Parameterized queries for SQL, argument arrays for commands, context-aware escaping for HTML, validated paths for files.

SQL injection → parameterized queries

Never build SQL by concatenation. database/sql placeholders send the query and the values on separate channels, so a value can’t change the query:

// ❌ VULNERABLE: user input becomes part of the SQL.
q := fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", name) // name = "' OR '1'='1"
db.Query(q)

// ✅ SAFE: the driver sends ? and the value separately; the value is never parsed as SQL.
db.Query("SELECT * FROM users WHERE name = ?", name)

That’s the whole fix — the ? placeholder. No escaping, no blocklist. (See database/sql.)

Command injection → no shell, argument arrays

// ❌ VULNERABLE: a shell parses the whole string. input = "x; rm -rf /"
exec.Command("sh", "-c", "ping "+input).Run()

// ✅ SAFE: no shell; the argument is one opaque element, never re-parsed.
exec.Command("ping", "-c", "1", input).Run()

os/exec doesn’t use a shell unless you invoke one — pass arguments as separate elements and ; | $() are just literal characters. (See processes & exec.)

See it: XSS defense with html/template

html/template is context-aware — it escapes data correctly for wherever it lands. This runs here: the <script> payload comes out as inert text, not executable markup:

package main

import (
"html/template"
"os"
)

func main() {
// html/template knows {{.}} is in an HTML body and escapes accordingly.
page := template.Must(template.New("p").Parse("<p>Comment: {{.}}</p>"))

// A malicious comment a user submitted.
evil := "<script>steal(document.cookie)</script>"

// The script tags are neutralized into harmless text — XSS defused.
page.Execute(os.Stdout, evil)
}

The output escapes <script> to <script>, so the browser renders it as text instead of running it. text/template would emit it raw — an XSS hole. Always render HTML with html/template.

See it: safe path handling

User-supplied filenames invite path traversal (../../etc/passwd). The fix is to clean the joined path and confirm it stays under your base directory. This runs here:

package main

import (
"fmt"
"path/filepath"
"strings"
)

// safeJoin returns base+name only if the result stays inside base.
func safeJoin(base, name string) (string, bool) {
full := filepath.Clean(filepath.Join(base, name))
cleanBase := filepath.Clean(base)
if full != cleanBase && !strings.HasPrefix(full, cleanBase+string(filepath.Separator)) {
	return "", false
}
return full, true
}

func main() {
base := "/srv/files"
for _, name := range []string{"report.pdf", "sub/data.csv", "../../etc/passwd", "../secret"} {
	if p, ok := safeJoin(base, name); ok {
		fmt.Printf("%-18s -> serve %s\n", name, p)
	} else {
		fmt.Printf("%-18s -> REJECT (escapes base)\n", name)
	}
}
}

The ../ payloads are rejected because the cleaned path no longer lives under /srv/files. Even better when you can: don’t take a path from the user at all — map an ID to a server-side path.

Validate with an allowlist

Beyond the injection-specific fixes, validate every input at the boundary with an allowlist: define exactly what’s valid (type, length, charset, range, enum) and reject the rest. Blocklists (“strip <script>”) always lose to an encoding you didn’t think of.

See also

• Fuzzing for bugs — find the unvalidated boundaries automatically.
• Web security (web track) — XSS, CSRF, security headers in depth.
• database/sql & transactions — parameterized queries in practice.
• Authentication & authorization — the next defensive layer.

Next: deciding who someone is and what they may do — authentication & authorization.

Related topics