Web Development Common Mistakes That Undermine Security

Web Development Common Mistakes That Undermine Security

Every week I review code from teams that know security matters—yet the same patterns keep showing up. These aren't exotic zero-days; they're everyday mistakes that open the door to data leaks, account takeovers, and compliance failures. Let's walk through the most common ones and what to do about them.

1. Trusting User Input Everywhere

The classic. You see it in search bars, profile forms, API parameters—anywhere data enters your app. Without proper validation and output encoding, you're inviting XSS, SQL injection, and command injection.

Fix: Validate input on the server side (whitelist where possible), encode output for the context (HTML, JS, CSS, URL), and use parameterized queries for databases. Don't rely on client-side checks alone.

2. Rolling Your Own Authentication

I've seen teams build custom password hashing, session management, and JWT handling from scratch. It almost always misses something—weak salt, predictable tokens, missing expiration checks.

Fix: Use established libraries and frameworks. For authentication, lean on OAuth 2.0 / OpenID Connect with a trusted provider. For sessions, let your web framework handle it. If you must build custom, follow OWASP guidelines to the letter.

3. Exposing Too Much in APIs

APIs that return full database objects, stack traces, or internal IDs are a goldmine for attackers. I've seen /api/user/123 return the entire user row, including password hash and internal notes.

Fix: Define explicit response schemas. Never return sensitive fields. Use DTOs (Data Transfer Objects) to shape what goes out. Implement rate limiting and proper HTTP methods (GET for reads, POST for writes, etc.).

4. Ignoring Dependency Vulnerabilities

Your app might be solid, but the libraries you import could have known CVEs. Teams often forget to update dependencies or run vulnerability scans until it's too late.

Fix: Use automated dependency scanning (e.g., Dependabot, Snyk, or OWASP Dependency-Check). Set a policy to patch critical vulnerabilities within 48 hours. Regularly audit your package-lock.json, requirements.txt, or equivalent.

5. No Security Headers

HTTP security headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security are easy to add but often missing. Without them, your app is vulnerable to clickjacking, MIME sniffing, and protocol downgrade attacks.

Fix: Add headers at your reverse proxy or application layer. Use a tool like securityheaders.com to check your current posture. Start with a strict policy and relax only as needed.

Proof Section: Secure Web Engineering Runbook

Here's a concrete runbook you can use to catch these mistakes before they hit production. I use this with every team I consult.

Checklist for Every Code Review

• All user input is validated server-side (type, length, format, whitelist).
• Output is encoded for the correct context (HTML entity, URL, JS, etc.).
• Database queries use parameterized statements or ORM with bound parameters.
• Authentication uses a vetted library (e.g., Passport.js, Devise, Spring Security).
• API responses never expose internal IDs, stack traces, or sensitive fields.
• Dependencies are scanned for vulnerabilities; no critical CVEs unpatched.
• Security headers are present: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security.
• Session tokens are random, expire, and are stored securely (HttpOnly, Secure, SameSite).
• File uploads are restricted by type and size, stored outside webroot, and scanned for malware.
• Error handling returns generic messages; no stack traces to the client.

How to Use This Runbook

1. Add it to your pull request template.
2. Run it as a pre-merge gate.
3. Review each item with the developer before merging.

This runbook is part of our broader Secure Web Engineering methodology. If your team needs help implementing these practices, our web development services include security reviews and remediation.

FAQ

Q: What is the most common mistake you see in web development? A: Trusting user input without validation or encoding. It's the root cause of XSS, SQL injection, and many other attacks.

Q: How often should we update dependencies? A: At least weekly for critical vulnerabilities. Use automated scanning to alert you when a library has a known CVE.

Q: Is it safe to use open-source authentication libraries? A: Yes, if they are well-maintained and widely used. Avoid rolling your own; the risk of missing edge cases is high.