Security

Security is a property of every feature: design every endpoint, form, data flow, and integration point with it from the start. Stack-agnostic guidance follows.

OWASP Top 10

Use the OWASP Top 10 as a starting checklist, not a full list. The table follows the 2025 edition (OWASP Top 10:2025). Mapping from the 2021 edition and per-category prevention steps are in the reference.

Related: LLM and agent security. Systems that embed an LLM or run autonomous agents have their own risk lists: the OWASP Top 10 for LLM Applications 2025 and the OWASP Top 10 for Agentic Applications 2026.

Input validation

Input validation is the first line of defense. Validate at every system boundary, not just at the UI.

• Validate on the server: client-side validation is a UX convenience, not a security control
• Allowlist over denylist: define what is acceptable rather than trying to block what is dangerous
• Validate type, length, format, and range: a "name" field should not accept 10MB of data or contain control characters
• Reject unexpected input: fail closed, do not try to "clean" malicious input and proceed
• Canonicalize before validation: normalize Unicode, decode URL encoding, and resolve path traversals before checking

Type coercion:

Loose type comparisons can bypass security checks. A string "0" might equal integer 0 or boolean false depending on the language. Use strict comparison operators and explicit type casting.

Parameterized queries:

Never concatenate user input into SQL, LDAP, or OS commands. Use parameterized queries or prepared statements. This applies to ORMs too, because raw query methods bypass ORM protections. See secure coding reference for details.

Authentication patterns

Authentication verifies identity: "who are you?" See auth patterns reference for detailed guidance.

Password hashing:

• Use bcrypt, scrypt, or Argon2id. Never use MD5, SHA-1, or SHA-256 alone for passwords
• Salts must be unique per password and generated by the hashing library
• Never store plain-text passwords, never use reversible encryption for passwords
• Enforce a minimum length and check against breached-password lists. Avoid composition rules and forced periodic changes (NIST SP 800-63B-4 prohibits both)

Multi-factor authentication (MFA):

• TOTP (time-based one-time passwords) is the baseline
• WebAuthn/passkeys provide the strongest phishing resistance
• SMS-based MFA is better than nothing but vulnerable to SIM swapping
• Provide recovery codes

Session management:

• Generate cryptographically random session IDs with sufficient entropy (128+ bits)
• Set secure cookie attributes: HttpOnly, Secure, SameSite=Lax (or Strict)
• Regenerate session ID after login to prevent session fixation
• Implement absolute and idle timeouts
• Invalidate sessions server-side on logout

Token-based auth (JWT caveats):

• JWTs are not sessions, and they cannot be revoked without extra infrastructure
• Validate the signature algorithm server-side; reject alg: none
• Keep tokens short-lived (minutes, not hours)
• Use refresh tokens for long-lived sessions; store them securely
• Never store sensitive data in JWT payloads. They are base64-encoded, not encrypted

OAuth2 flows:

• Authorization Code with PKCE: standard for web and mobile apps
• Client Credentials: for machine-to-machine communication
• Do not use the Implicit flow. The OAuth 2.0 Security BCP (RFC 9700) says clients should not use it

Authorization patterns

Authorization determines permissions: "what are you allowed to do?" It is not the same as authentication. See auth patterns reference for details.

Principle of least privilege:

• Grant the minimum permissions needed for a task
• Default to deny: grant access explicitly rather than revoking it
• Time-bound elevated privileges when possible

Role-Based Access Control (RBAC):

• Assign permissions to roles, assign roles to users
• Keep roles coarse-grained; avoid role explosion
• Check permissions, not role names, in application code. This decouples authorization logic from role definitions

Attribute-Based Access Control (ABAC):

• Decisions based on attributes of user, resource, action, and environment
• More flexible than RBAC for complex policies (e.g., "managers can approve expenses under $10,000 during business hours")
• More complex, so use it when RBAC is insufficient

Common authorization mistakes:

• Checking authorization only in the UI. Always enforce it server-side
• Relying on obscurity (unguessable URLs) instead of access controls
• Failing to check authorization on every request (including API calls, file downloads, and indirect references)
• IDOR (Insecure Direct Object Reference): always verify the user has access to the specific resource they are requesting

Data protection

Encryption at rest:

• Encrypt sensitive data stored in databases, files, and backups (backups included)
• Use AES-256 or equivalent for symmetric encryption
• Manage encryption keys separately from encrypted data
• Rotate encryption keys on a schedule and when compromise is suspected

Encryption in transit:

• Use TLS 1.2+ for all network communication
• Disable older protocols (SSL, TLS 1.0, TLS 1.1)
• Validate certificates; do not disable certificate verification

PII handling:

• Identify and classify all personally identifiable information
• Minimize collection: do not collect data you do not need
• Implement data retention policies and delete data when it is no longer needed
• Provide data export and deletion capabilities for compliance (GDPR, CCPA)
• Mask PII in logs. Never log passwords, tokens, credit card numbers, or full SSNs

Secure deletion:

• Overwrite sensitive data before freeing memory (when the language allows)
• Make sure database deletions actually remove data (not just soft-delete for sensitive records)
• Consider backup retention: deleted data may persist in backups

Secrets management

Never in code or config files:

• No API keys, passwords, or tokens in source code, config files, or environment-specific files committed to version control
• Use .gitignore for local config files, but do not rely on it as your only protection
• Scan repositories for accidentally committed secrets (use tools like git-secrets, truffleHog, or Gitleaks)

Environment variables:

• Acceptable for simple deployments but have limitations
• They are visible to all processes in the same environment
• They appear in process listings and crash dumps
• Better than hardcoding, but not the strongest option

Secret managers:

• Use dedicated secret managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
• Access secrets at runtime, not build time
• Audit access to secrets

Rotation strategy:

• Rotate secrets on a regular schedule
• Rotate immediately if compromise is suspected
• Design systems to support rotation without downtime (support two active versions during transition)
• Automate rotation where possible

Security headers

Set these HTTP response headers on every response. Each addresses a specific class of attack.

CORS (Cross-Origin Resource Sharing):

• Do not use Access-Control-Allow-Origin: * for authenticated endpoints
• Allowlist specific origins
• Be restrictive with Access-Control-Allow-Methods and Access-Control-Allow-Headers
• Remember that browsers enforce CORS. It does not protect server-to-server calls

Common antipatterns

These mistakes show up often and create vulnerabilities:

• Security through obscurity: hiding URLs, using unpredictable IDs, or obfuscating code is not a security control. It supplements real controls and never replaces them.
• Homegrown cryptography: never implement your own encryption, hashing, or random number generation. Use well-tested libraries.
• Storing secrets in repositories: even in "private" repos, secrets in code spread through forks, CI systems, and developer machines.
• Disabling security features for convenience: turning off CSRF protection, SSL verification, or authentication in a "development" mode that leaks to production.
• Trusting internal networks: zero-trust means verifying identity and authorization even for internal service-to-service calls.
• Ignoring dependency vulnerabilities: known vulnerabilities in dependencies are among the easiest attack vectors. Scan and update regularly.
• Catching and silencing exceptions: swallowing errors hides security failures. Log them (without sensitive details) and fail safely.

Other controls

Items to check in review that are not covered above:

• Output is encoded or escaped for its context (HTML, URL, JavaScript, SQL)
• File uploads validate type, size, and content, and are stored outside the web root
• Rate limiting on login endpoints, plus account lockout or progressive delays after failed attempts
• Admin functions are protected and not reachable by URL guessing
• Debug mode is disabled in production, and error messages do not leak internal details to clients
• Security events are logged (login failures, authorization denials, input validation failures), alerts exist for suspicious patterns, logs are protected from tampering
• An incident response plan is documented