OWASP Top 10 Security
Understand and defend against the OWASP Top 10 web application vulnerabilities - injection, broken auth, XSS, insecure design, and more.
skill: OWASP Top 10 Security category: Security tags: [OWASP, Security, Web Security, Vulnerabilities, AppSec] readingTime: 7
OWASP Top 10 represents the most critical and common web vulnerabilities - understanding them is the minimum security baseline for any developer. Security is not a feature to add later; it must be designed in from the beginning. Defense in depth means multiple controls, not relying on any single measure.
Workflow
- Prevent SQL Injection with parameterized queriesSQL injection is the oldest and most devastating web vulnerability - an attacker can dump, modify, or delete your entire database. Parameterized queries separate code from data.
- Prevent XSS with output encodingCross-Site Scripting lets attackers inject JavaScript that runs in victims' browsers - stealing session tokens, redirecting users, or defacing the site.
- Implement proper authenticationBroken authentication is the #2 OWASP category - weak passwords, no MFA, insecure session tokens, and credential stuffing all fall here.
- Validate and sanitize all inputUntrusted data from users, APIs, and third parties drives injection, deserialization, and path traversal attacks. Validate at the boundary.
- Set security headersSecurity headers provide defense-in-depth - CSP blocks XSS, HSTS enforces HTTPS, X-Frame-Options prevents clickjacking.
Output Format
Secure web application: parameterized queries, output encoding, strong auth, input validation, and security headers.
Security checklist:
☐ All DB queries parameterized (no string concat)
☐ All user output HTML-encoded or sanitized
☐ Passwords hashed with bcrypt/argon2 (rounds ≥ 12)
☐ Sessions use 256-bit random tokens with expiry
☐ All input validated against a strict schema
☐ Security headers via helmet (CSP, HSTS, etc.)
☐ Dependencies scanned with npm audit / Snyk
☐ Sensitive data not logged (no PII, no tokens in logs)Examples
Input
Output
Edge Cases & Gotchas
- Second-order SQL injection - Data stored safely (parameterized) then later used in a dynamic query can be injected. Always parameterize at the query level, not just at input.
- DOM XSS - Server-side escaping doesn't prevent DOM XSS (JavaScript writing untrusted data to innerHTML on the client). Use textContent instead of innerHTML.
- JWT algorithm confusion - Accepting both HS256 and RS256 in JWT verification allows attackers to downgrade to HS256 and sign with the public key as HMAC secret. Always specify the expected algorithm.
- CORS misconfiguration - Setting Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true allows any site to make authenticated requests. These headers can't be combined - CORS must use specific origins for credentialed requests.
When to Break These Rules
- Don't skip security reviews under deadline pressure - security debt compounds. A 30-minute threat modeling session before building a feature is cheaper than a breach.
- Don't rely solely on automated scanners (SAST/DAST) - they find common patterns but miss business logic vulnerabilities and design flaws. Manual code review is non-negotiable for auth and data access code.
Reference Files
https://owasp.org/Top10/https://cheatsheetseries.owasp.org/