The Web Security Checklist Every Developer Should Follow in 2026

Security is everyone's responsibility, but most developers never receive formal security training. We learn to build features, not to defend against attacks. The result: applications with XSS vulnerabilities, SQL injection in APIs, and authentication bypasses that would make a security researcher cry.

I am not a security researcher. I am a developer who has been burned enough times to take security seriously. This checklist is what I apply to every application I build. It covers the most common vulnerabilities and their mitigations in practical terms.

Input Validation and Sanitization

Rule number one: never trust user input. Not from forms, not from URL parameters, not from headers, not from cookies, not from file uploads. All external input is potentially malicious.

Validate on the server side, always. Client-side validation is for UX (showing errors before submission). Server-side validation is for security. A malicious user can bypass any client-side check by modifying the request directly.

Use a validation library (Zod, Yup, Joi) to define schemas for every API endpoint. The schema specifies: what fields are expected, their types, maximum lengths, allowed patterns, and whether they are required. Reject requests that do not match the schema before processing them.

SQL injection prevention: never concatenate user input into SQL queries. Use parameterized queries or an ORM (Prisma, Drizzle). Both automatically escape user input. If you must write raw SQL, use parameterized placeholders ($1, ?). Never template literals with user strings.

XSS prevention: escape all user-generated content before rendering in HTML. React does this automatically for JSX expressions (the content is escaped before DOM insertion). But dangerouslySetInnerHTML bypasses this — only use it with sanitized HTML (DOMPurify).

Authentication Security

Password hashing: use bcrypt or Argon2 with a cost factor that takes at least 250ms. Never MD5, never SHA-256 for passwords. These are fast hashes — an attacker can try billions per second. bcrypt and Argon2 are intentionally slow.

Session management: use HTTP-only cookies with Secure and SameSite=Strict attributes. HTTP-only prevents JavaScript access (XSS cannot steal sessions). Secure ensures cookies only transmit over HTTPS. SameSite=Strict prevents CSRF by not sending cookies on cross-origin requests.

Multi-factor authentication: offer it. Ideally, make it the default for admin accounts. TOTP (authenticator apps) is the minimum. WebAuthn/passkeys are better — phishing-resistant and more user-friendly.

Account lockout: after 5-10 failed login attempts, lock the account temporarily (15 minutes). This prevents brute force attacks. Implement progressive delays between attempts to slow automated attacks without locking out legitimate users who mistype.

HTTP Security Headers

These headers protect against common attacks and take minutes to configure:

Content-Security-Policy (CSP): restricts what sources can load scripts, styles, images, and other resources. Prevents XSS by blocking inline scripts and scripts from unauthorized domains. Start with a strict policy and loosen as needed: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'.

Strict-Transport-Security (HSTS): tells browsers to only connect via HTTPS. Prevents downgrade attacks and mixed content. Header: Strict-Transport-Security: max-age=31536000; includeSubDomains.

X-Content-Type-Options: nosniff. Prevents browsers from guessing content types. Stops attacks where a malicious file is uploaded with a harmless extension but executed as JavaScript.

X-Frame-Options: DENY (or SAMEORIGIN). Prevents your page from being embedded in iframes on other sites. Stops clickjacking attacks.

Referrer-Policy: strict-origin-when-cross-origin. Limits information sent in the Referer header. Prevents leaking sensitive URL parameters to external sites.

Permissions-Policy: restrict access to browser features your application does not need. Disable camera, microphone, geolocation if you do not use them: camera=(), microphone=(), geolocation=().

API Security

Rate limiting on all endpoints. Even authenticated endpoints should have rate limits to prevent abuse. See our detailed post on rate limiting patterns for implementation strategies.

API key management: generate keys with sufficient entropy (256 bits). Store hashed (SHA-256 is fine for API keys since they have high entropy). Transmit in headers (Authorization: Bearer key), never in URL parameters (URLs end up in logs and browser history).

CORS configuration: restrict Access-Control-Allow-Origin to specific origins, never use wildcard (*) for authenticated endpoints. A wildcard allows any website to make authenticated requests to your API using your users' cookies.

Request size limits: set maximum body sizes on all endpoints. Without limits, an attacker can send a 10GB request body and exhaust your server's memory. 1MB is sufficient for most APIs; increase for file upload endpoints only.

Data Protection

Encryption at rest: ensure your database disk is encrypted. Most managed database services do this automatically (RDS, PlanetScale, Neon). For self-hosted databases, enable filesystem encryption.

Encryption in transit: HTTPS everywhere, no exceptions. Free certificates from Let's Encrypt make this trivial. In 2026 there is zero excuse for unencrypted HTTP in production.

Sensitive data minimization: do not collect data you do not need. Every piece of user data is a liability. Do not store credit card numbers (use Stripe). Do not log personally identifiable information. Do not keep data longer than necessary.

Backup encryption: database backups contain all your sensitive data. Encrypt them. Store them in a separate location from the primary database. Test restoration periodically.

Dependency Security

Dependency auditing: run npm audit (or equivalent) regularly. Fix critical and high vulnerabilities immediately. Use automated tools (Dependabot, Renovate, Snyk) to get PRs when dependencies release security patches.

Lock files: commit your package-lock.json / pnpm-lock.yaml. Lock files ensure everyone installs the exact same dependency versions. Without them, a malicious package update could affect some developers but not others.

Supply chain attacks: pin major versions and review dependency updates before merging. A popular package can be compromised (happened to event-stream, ua-parser-js, colors.js). Minimize your dependency count — every dependency is an attack surface.

File Upload Security

Validate file types on the server by reading file headers (magic bytes), not just the file extension. A file named invoice.pdf could contain malicious JavaScript if you only check the extension.

Store uploads in a separate domain or subdomain. If uploaded files can contain HTML or JavaScript and are served from your main domain, they can access your users' cookies. Serve from a different origin (like uploads.yourdomain.com) to isolate them.

Set Content-Disposition: attachment for user-uploaded files. This forces download instead of rendering in the browser, preventing stored XSS through uploaded HTML files.

Limit file sizes. Set maximums per endpoint and globally. An unbounded file upload is a denial-of-service vector.

Scan uploads for malware. For applications that handle file uploads from untrusted users, integrate a virus scanning service (ClamAV, or cloud-based alternatives).

Monitoring for Security

Log authentication events: every login, logout, failed attempt, password change, MFA enrollment, and API key creation. These logs are essential for investigating compromised accounts.

Alert on anomalies: multiple failed logins from different IPs (credential stuffing), successful login from an unusual country, privilege escalation attempts, bulk data access patterns.

Keep dependencies updated: enable automated security patches for your dependencies. Merge security updates within 24 hours of release for critical vulnerabilities.

Our Security Posture

At AIDToolStack:

All tools run client-side (no user data touches our servers during tool use)

Authentication via Clerk (dedicated security team maintaining auth)

CSP headers configured with strict policy

API routes validate input with Zod schemas

Rate limiting on all authenticated and public API endpoints

Dependencies updated weekly via automated PRs

Sentry monitors for unexpected errors that could indicate attacks

No raw SQL — Prisma handles query construction

Security is an ongoing practice, not a one-time configuration. Review this checklist quarterly, update it as new threats emerge, and treat security vulnerabilities with the same urgency as production outages. Your users trust you with their data — honor that trust.