Common Security Mistakes in Web Applications

We've Audited Hundreds of Web Apps

Over the years, we've reviewed the security of hundreds of web applications. The same mistakes appear again and again - not because developers don't care about security, but because these vulnerabilities are easy to introduce and hard to spot without deliberate attention.

Here are the most common ones, with practical fixes.

1. SQL Injection (Still Happening in 2025)

The Mistake

Building SQL queries by concatenating user input directly into the query string. This lets attackers modify the query to access or modify data they shouldn't.

The Fix

Use parameterized queries or an ORM. Never build SQL strings from user input. This is non-negotiable.

Why It Still Happens

Developers copy-paste code from old tutorials. Some ORMs have "raw query" features that bypass protections. Quick fixes under deadline pressure skip validation.

2. Broken Authentication

The Mistake

Weak session management, predictable tokens, or improperly implemented password reset flows.

Common Vulnerabilities

• Session tokens that don't expire
• Password reset links that don't have time limits
• No brute-force protection on login endpoints
• Storing passwords with weak hashing (MD5, SHA1)

The Fix

Use a proven authentication library or service. If you must build your own, use bcrypt or Argon2 for password hashing, generate cryptographically random session tokens, and implement rate limiting.

3. Cross-Site Scripting (XSS)

The Mistake

Rendering user-supplied content without proper sanitization, allowing attackers to inject malicious scripts.

Types

• Stored XSS: Malicious script saved to the database (comments, profiles)
• Reflected XSS: Script in URL parameters rendered on the page
• DOM XSS: Client-side JavaScript processes untrusted data

The Fix

• Use a framework that auto-escapes output (React, Vue, Angular all do this by default)
• Never use dangerouslySetInnerHTML (React) or v-html (Vue) with user content
• Implement a Content Security Policy (CSP) header
• Sanitize HTML input with a library like DOMPurify

4. Insecure Direct Object References (IDOR)

The Mistake

Exposing internal object IDs in URLs or API responses and not verifying that the requesting user has access to that object.

Example

A user accesses /api/invoices/123 and can change the ID to 124 to see another customer's invoice.

The Fix

Always verify authorization on the server side. Check that the authenticated user owns or has permission to access the requested resource. Use UUIDs instead of sequential IDs to make enumeration harder (but don't rely on this alone).

5. Missing Security Headers

The Mistake

Deploying a web application without proper HTTP security headers.

Essential Headers

• Content-Security-Policy: Prevents XSS and data injection
• Strict-Transport-Security: Forces HTTPS
• X-Content-Type-Options: nosniff: Prevents MIME sniffing
• X-Frame-Options: DENY: Prevents clickjacking
• Referrer-Policy: Controls information leakage

The Fix

Configure these headers in your web server, CDN, or application middleware. Use securityheaders.com to verify your configuration.

6. Exposed API Keys and Secrets

The Mistake

Committing API keys, database credentials, or encryption keys to version control. Once pushed, they're in the git history forever.

The Fix

• Use environment variables for all secrets
• Use a secrets manager in production
• Add secret scanning to your CI/CD pipeline (GitHub has this built-in)
• Rotate any key that has ever been committed to a repository

7. Insufficient Logging

The Mistake

Not logging security-relevant events, making it impossible to detect or investigate breaches.

What to Log

• Authentication attempts (successful and failed)
• Authorization failures
• Input validation failures
• Administrative actions
• Data exports and bulk operations

What Not to Log

• Passwords (even failed ones)
• Full credit card numbers
• Session tokens
• Personal health information

Conclusion

Most web application security doesn't require exotic knowledge - it requires discipline. Use proven libraries, validate all input, verify all authorization, and log security events. The vulnerabilities on this list are all preventable with straightforward practices.