---
name: "Secure coding"
description: "Always-on, stack-agnostic security rules for every file in the repository."
applyTo: "**"
---

# Secure coding rules

These rules apply to every language and file type. When a rule conflicts with a quick fix, keep the rule.

## Secrets

- Never write secrets, passwords, API keys, tokens, connection strings or private keys into code, config files, tests, samples or comments. Anything committed is permanently exposed.
- Read secrets at runtime from Azure Key Vault or Azure DevOps pipeline secret variables (or variable groups linked to Key Vault).
- Prefer managed identities or workload identity over stored credentials.
- Use obvious placeholders in examples (`<your-api-key>`), and keep `.env` and local secret files in `.gitignore`.
- If a secret was ever committed, treat it as leaked: rotate it first, then remove it from history.

## Input and output

- Treat all input as untrusted: request data, headers, files, queue messages, environment and third-party responses.
- Validate at the boundary with allow-lists for type, length, range and format; reject unknown fields on sensitive objects.
- Use parameterized queries or the ORM; never concatenate input into SQL, shell commands, LDAP, file paths or template expressions.
- Encode output for its context (HTML, attribute, URL, JavaScript) and never render untrusted HTML without a sanitizer.
- Fetch user-supplied URLs only against a host allow-list, blocking private and metadata IP ranges. Prevents SSRF.
- Never deserialize untrusted data into arbitrary types.

## Access control

- Authenticate and authorize every endpoint, handler, job and admin path; deny by default.
- Check object-level ownership (`id` plus user or tenant), not just the role. Prevents IDOR.
- Enforce authorization on the server; client-side checks are for UX only.
- Grant least privilege to service accounts, pipeline service connections, database users and cloud roles; no shared admin accounts.

## Data and logging

- Never log passwords, tokens, secrets, full card numbers or personal data (names, emails, addresses, IDs). Log opaque ids instead.
- Return generic error messages to users with a correlation id; keep stack traces, SQL and internal paths in server logs only.
- Encrypt data in transit (TLS) and use vetted crypto libraries; hash passwords with Argon2, bcrypt or scrypt. Never roll your own crypto.
- Collect and keep only the personal data the feature needs.

## Dependencies and builds

- Add dependencies only when needed, from official registries, and pin versions with a committed lockfile.
- Check new packages for maintenance, license and known vulnerabilities; fix high and critical findings before merging.
- Do not disable security checks, TLS validation, linters or scanners to make a build pass.
- Do not copy code from unknown sources without understanding what it does.

## When to ask a human

- Stop and ask a reviewer before changing authentication, authorization, cryptography, secret handling, payment flows, or personal data processing.
- Ask before adding a new external service, widening network or firewall access, or granting new permissions.
- Flag it clearly when you are unsure whether code is safe, or when a request would weaken an existing control.

Go deeper: for larger tasks use the backend-code-review, frontend-code-review and api-design skills, plus the stack-specific development skill for the code you are changing.