Security

Use what the project already has. If it has a validation library, use it. If it has an auth middleware, apply it. Never introduce a parallel security mechanism alongside an existing one.

Map the trust boundaries before writing:

• Trusted: your own validated, sanitised output; values you generated internally
• Untrusted: everything else — HTTP bodies, query params, headers, uploaded files, CLI args, environment input, database values that users wrote, third-party API responses, IPC messages

The Golden Rule

Never trust data you did not create yourself.

Treat all external input as hostile until it has been explicitly validated against a strict allowlist of what is acceptable. Reject anything that doesn't match. Never try to sanitise your way out of a validation failure — reject it outright.

1. Input Validation and Injection

Validate at the boundary — before any use

Every entry point that accepts external data must validate it before passing it anywhere:

• Type — is it the right type? (string, integer, boolean — not just "any value")
• Format — does it match the expected pattern? (UUID, email, filename, URL)
• Range / length — is it within acceptable bounds?
• Allowlist — if it must be one of a known set of values, check against that set

Reject inputs that don't pass. Never attempt to fix or coerce invalid input from untrusted sources.

SQL injection — parameterised queries, always

Never interpolate external data into query strings. Use parameterised queries or prepared statements in every language and every database driver:

# ❌ Any language — string interpolation in SQL
"SELECT * FROM users WHERE email = '" + email + "'"
f"SELECT * FROM users WHERE email = '{email}'"
`SELECT * FROM users WHERE email = '${email}'`

# ✅ Parameterised — the driver handles escaping, input is never interpreted as SQL
db.query("SELECT * FROM users WHERE email = ?", [email])        # MySQL style
db.query("SELECT * FROM users WHERE email = $1", [email])       # PostgreSQL style
db.execute("SELECT * FROM users WHERE email = :email", {email}) # named params

This applies to every query — SELECT, INSERT, UPDATE, DELETE. No exceptions. If using an ORM, use its query builder. Never drop to raw string SQL with user data.

Path traversal — confine file access to a known base directory

Never use unsanitised user input to construct file paths. An attacker who controls a path can read or write any file the process has access to, including config files and credentials.

The fix is always the same regardless of language:

1. Resolve the user-supplied path relative to a safe base directory
2. Verify the resolved absolute path still starts with the base directory
3. Reject anything that doesn't

# ❌ User controls where on the filesystem you read/write
read_file("/uploads/" + user_supplied_filename)

# ✅ Resolve and verify confinement — pseudocode applicable to any language
base = resolve("/uploads")
requested = resolve(base + "/" + user_supplied_filename)
if not requested.starts_with(base + separator):
    reject("Invalid path")
read_file(requested)

Shell injection — never pass user data through a shell

Any use of exec, system, popen, subprocess, or equivalent with a shell-interpolated string containing external data is a critical vulnerability. The attacker can terminate your command and run arbitrary commands instead.

# ❌ Shell interprets the full string — attackable
system("convert " + filename + " output.png")
exec(`ffmpeg -i ${input} out.mp4`)

# ✅ Pass arguments as a list/array — no shell involved
execFile("convert", [filename, "output.png"])
subprocess.run(["ffmpeg", "-i", input, "out.mp4"])

If the language and library support an array/list form that bypasses the shell — always use it. Better still, use a native library for the operation instead of shelling out at all.

Other injection classes — same principle, different context

• Template injection: never render user-supplied strings as templates
• LDAP injection: use parameterised LDAP queries or escape per RFC 4515
• XML/XXE: disable external entity processing in XML parsers; use JSON where possible
• Deserialization: never deserialise untrusted data with a general-purpose deserialiser (Java ObjectInputStream, Python pickle, Ruby Marshal) — use language-agnostic formats (JSON, Protobuf, MessagePack) with explicit schema validation instead

2. Authentication and Authorisation

Authentication principles

• Verify identity on every request — never assume a session is still valid; re-check tokens
• Use constant-time comparison for all token and secret comparisons — standard == leaks timing information that can be used to forge valid tokens character by character
• Pin token signing algorithms — when using JWTs, always specify which algorithms are acceptable; leaving it unspecified allows algorithm confusion attacks (none, RS→HS swap)
• Expire tokens — sessions and tokens must have a finite lifetime; implement revocation for sensitive operations
• Hash passwords with a purpose-built algorithm — argon2id is the current recommendation; bcrypt and scrypt are acceptable; SHA-* alone, MD5, and plain storage are never acceptable regardless of iteration count

Authorisation principles

• Check ownership on every operation — verify that the authenticated user is allowed to act on the specific resource, not just that they are authenticated
• Server-side always — never rely on the client to restrict what it requests; any client can send any request regardless of what the UI shows
• Principle of least privilege — a service account, API key, or user session should have exactly the permissions it needs for its function, nothing more
• Default deny — if an authorisation check is missing or fails, the default outcome must be denial, not permission

# ❌ Checks authentication but not authorisation — any logged-in user can delete any file
delete_file(file_id)

# ✅ Ownership enforced in the data access layer
file = db.find(file_id, owner_id=current_user.id)  # returns nothing if not owned
if not file: reject(404)
delete_file(file.id)

Session management

• Generate session IDs with a cryptographically secure random source (see section 4)
• Regenerate session IDs after privilege changes (login, role change)
• Invalidate server-side on logout — don't rely only on deleting the client cookie
• Set cookies with HttpOnly, Secure, and SameSite=Strict or Lax

3. Secrets and Credentials

Never hardcode secrets

# ❌ Any form of hardcoded credential — will end up in version control
API_KEY = "sk-prod-abc123"
DB_PASSWORD = "hunter2"
SECRET = "my-secret-key"

# ✅ Read from the environment; fail loudly if missing
api_key = require_env("API_KEY")   # raise an error if not set, never silently use a default

This applies to: API keys, database passwords, JWT secrets, encryption keys, private keys, OAuth client secrets, webhook signing secrets, internal service tokens — everything.

Never log secrets

Before logging any object, request, config, or error:

• Explicitly list which fields are safe to log
• Redact or omit everything else

# ❌ Logs entire request body — may contain passwords, tokens, private data
log(request.body)
log(config)

# ✅ Log only known-safe fields
log({ user_id: request.body.user_id, action: request.body.action })

Secrets in URLs — never

Query parameters and URL paths are logged by every proxy, CDN, browser history, and server access log between the client and your service. Secrets must go in headers (Authorization, X-API-Key) or in the request body, never in the URL.

Secret scanning

Before committing, verify no secrets are present:

# git-secrets, truffleHog, or gitleaks — check what the project uses
git diff --staged | grep -iE "password|secret|api.?key|token|private.?key" | head -20

4. Cryptography

Use standard implementations — never roll your own

Custom crypto is always broken. Use well-maintained, audited libraries that are standard in the ecosystem. Check what the project already uses before adding a new crypto dependency.

Algorithm selection

Secure random number generation

Always use the operating system's cryptographically secure random source:

# The principle is the same across all languages:
# Use the OS/platform CSPRNG, never the standard math random

# ❌ Predictable — not cryptographic
token = random_string(32)        # backed by Math.random, rand(), time seed
id = uuid_v4_from_math_random()

# ✅ OS-backed CSPRNG — unpredictable, suitable for security tokens
token = os_csprng_bytes(32).hex()
# Node: crypto.randomBytes(32)
# Python: secrets.token_hex(32) or os.urandom(32)
# Rust: OsRng.fill_bytes(&mut buf)
# Go: crypto/rand.Read(buf)
# Ruby: SecureRandom.hex(32)

Encryption correctness

• Always use authenticated encryption (AES-GCM, ChaCha20-Poly1305) — unauthenticated modes (AES-CBC, AES-CTR alone) allow attackers to tamper with ciphertext undetected
• Never reuse an IV/nonce with the same key — generate a fresh random IV for every encryption
• Store the IV alongside the ciphertext — it is not secret but must be unique
• Verify the authentication tag before using decrypted data — never decrypt-then-verify

5. HTTP and Network Security

General principles (framework-agnostic)

• Security headers: set Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security on all responses
• CORS: restrict allowed origins to an explicit allowlist; never use wildcard (*) for endpoints that handle credentials or sensitive data
• Rate limiting: apply to all authentication endpoints, password reset, and any endpoint that is expensive or could be used for enumeration
• HTTPS only: redirect HTTP to HTTPS; use HSTS; never send sensitive data over plain HTTP
• TLS configuration: disable old TLS versions (1.0, 1.1); use strong cipher suites

SSRF — validate URLs before fetching on behalf of a user

If your server fetches a URL supplied by a user or external input, an attacker can use it to reach internal services, cloud metadata endpoints (169.254.169.254), and other restricted resources.

# ❌ Blind fetch of user-supplied URL
response = http.get(user_supplied_url)

# ✅ Validate against an allowlist before fetching
parsed = parse_url(user_supplied_url)
if parsed.hostname not in ALLOWED_HOSTS:
    reject("Host not allowed")
if parsed.scheme != "https":
    reject("HTTPS only")
response = http.get(parsed)

Block private IP ranges (10.x, 172.16-31.x, 192.168.x, 127.x, ::1) if the allowlist approach is not feasible, but an explicit allowlist is always stronger.

Mass assignment

Never apply the full body of an incoming request directly to a database record. An attacker can include fields they should not be able to set (role, admin flag, owner ID, account balance).

# ❌ User can set any field on the record
db.update(record_id, request.body)

# ✅ Explicitly extract only the fields that are user-editable
db.update(record_id, {
    display_name: request.body.display_name,
    avatar_url: request.body.avatar_url,
})

6. File Handling

• Validate file type from content, not from the extension or Content-Type header — both are user-controlled. Read the first bytes (magic bytes / file signature) to detect the actual format.
• Enforce size limits before reading the file into memory
• Generate a safe storage name — never use the original filename for storage. Use a UUID or a hash of the content. Store the original name only in the database if needed for display.
• Store outside the web root — uploaded files must not be directly accessible via URL unless you explicitly intend to serve them, and then only after validation
• Scan or process in isolation — if the file will be processed (image resizing, document parsing), do it in a sandboxed environment if the format is complex

7. Dependency Security

Every dependency is part of your attack surface. Before adding one:

• Is it actively maintained?
• Does it have a known vulnerability disclosure process?
• Is the install count and community trust reasonable for what it does?
• Is there a lighter or already-present alternative?

After adding or updating dependencies, run the appropriate audit tool:

npm audit            # JavaScript / Node
cargo audit          # Rust
pip-audit            # Python
bundle audit         # Ruby
govulncheck ./...    # Go
dotnet list package --vulnerable   # .NET

Keep dependencies up to date. A vulnerability in a dependency is a vulnerability in your code.

8. Error Handling and Information Leakage

Errors sent to clients must never reveal:

• Stack traces
• Internal file paths or module names
• Database query structure or column names
• Framework or library versions
• Internal service names or IPs

# ❌ Full error detail exposed to caller
return { error: exception.message, trace: exception.stacktrace, query: failed_query }

# ✅ Log full detail internally; return a safe, generic message to the caller
log_internally(exception, request_context)
return { error: "An unexpected error occurred" }

In development environments it is acceptable to return more detail — but the mechanism to do so must be explicitly gated on an environment flag, never on anything the caller controls.

9. Platform-Specific Considerations

When writing for a specific platform, check what secure storage and security APIs are available before reaching for a generic solution:

• Mobile (iOS/Android): use the platform Keychain/Keystore for sensitive data — never unencrypted local storage or shared preferences for tokens or credentials
• Browser: use HttpOnly cookies over localStorage for session tokens — JS-accessible storage is vulnerable to XSS
• Server: use secret management services (Vault, AWS Secrets Manager, GCP Secret Manager) rather than environment variables for production secrets where possible
• CLI tools: never write secrets to stdout, log files, or shell history; use secure prompts and clear sensitive variables from memory after use

10. Pre-Commit Security Checklist

Before considering code complete:

Input and injection

• All external input validated against strict type, format, and range rules
• All database queries use parameterised statements — no string interpolation
• All file paths resolved and verified to stay within an allowed base directory
• All shell commands use argument arrays — no user data in shell strings
• All user-supplied URLs validated against an allowlist before server-side fetch

Auth and access control

• Every operation that accesses or modifies data verifies ownership server-side
• All token comparisons use constant-time equality
• Passwords hashed with argon2id, bcrypt, or scrypt — never fast hashes
• Sessions regenerated on privilege changes; invalidated server-side on logout

Secrets

• No hardcoded credentials, keys, or tokens anywhere in the code
• Secrets loaded from environment; startup fails loudly if any are missing
• No secrets in log output, error responses, or URLs

Cryptography

• All random tokens generated from OS CSPRNG, not math random
• Encryption uses an authenticated mode (GCM, Poly1305)
• No custom crypto implementations

HTTP

• Security headers set on all responses
• CORS restricted to an explicit origin allowlist
• Rate limiting applied to auth and sensitive endpoints
• Error responses return only generic messages — no internal detail

Dependencies

• Vulnerability audit run and clean after any dependency change

When You Spot a Vulnerability

If you find a security issue in existing code while working on something else — flag it immediately, even if you were not asked to audit it:

Note: while working on X I noticed Y is vulnerable to Z
(e.g. unsanitised input passed directly to a shell command on line N of file).
I have not changed it as it is outside the current task, but it should be
addressed before this ships.

Never silently work around a vulnerability or leave it unflagged. Security debt compounds.