Web Security for Developers: OWASP Top 10 and Beyond
Web security vulnerabilities cause data breaches, ransomware attacks, and regulatory fines. Most vulnerabilities aren't exotic — they're the same handful of mistakes made repeatedly across different codebases. The OWASP Top 10 catalogues the most common and impactful web application security risks. This guide explains each one and how to prevent it.
SQL Injection
SQL injection occurs when untrusted user input is embedded directly in a SQL query. An attacker can manipulate the query to dump the entire database, bypass authentication, or delete data. Classic example: SELECT * FROM users WHERE username = '{input}' — if input is ' OR '1'='1, the query returns all users.
Prevention: always use parameterised queries / prepared statements. Never concatenate user input into SQL strings. ORMs parameterise by default — use raw queries only when necessary and parameterise those too. Use our RegExp Tester to validate and sanitise input patterns.
Cross-Site Scripting (XSS)
XSS injects malicious scripts into web pages viewed by other users. Stored XSS saves the payload in the database; Reflected XSS bounces it off the server in an immediate response; DOM-based XSS manipulates the DOM without a server round-trip. The payload can steal session cookies, redirect users, keylog inputs, or deface the page.
Prevention: escape all user-supplied output in HTML context. Use Content Security Policy (CSP) headers to restrict which scripts can execute. Use HttpOnly cookies so scripts can't access session tokens. Modern frameworks (React, Vue, Angular) auto-escape by default — never use dangerouslySetInnerHTML or v-html with untrusted data.
Cross-Site Request Forgery (CSRF)
CSRF tricks an authenticated user into unknowingly making a request to a site they're logged into. If a banking site uses cookie-based sessions and doesn't validate request origin, a malicious page can make the user's browser send a money transfer request. The victim's browser automatically includes the session cookie.
Prevention: use CSRF tokens (random values embedded in forms and validated server-side). Use the SameSite=Strict or SameSite=Lax cookie attribute. Validate the Origin and Referer headers on state-changing requests.
Insecure Direct Object Reference (IDOR)
IDOR occurs when an application uses user-controllable input to directly access objects without authorisation checks. Example: changing /api/orders/1234 to /api/orders/1235 and seeing another user's order. This is an authorisation bug — the application authenticates but doesn't check that the authenticated user owns the resource.
Prevention: authorise every resource access. Check that the currently authenticated user has permission to access the specific object being requested. Use UUIDs instead of sequential integers to make enumeration harder (though obscurity alone is not security).
Sensitive Data Exposure
Applications frequently expose more data than necessary: API responses include fields that frontend code doesn't display but an attacker can read, logs contain passwords or tokens, error messages reveal internal paths, and database backups are left in publicly accessible storage.
Prevention: return only the data the client needs. Encrypt sensitive data at rest using AES-256 (test with our AES tool). Use TLS everywhere. Hash passwords with bcrypt/Argon2 — never MD5. Rotate and expire tokens. Audit your S3 buckets, GCS buckets, and Azure blobs for public accessibility.
Broken Authentication
Weak authentication includes predictable session tokens, credential stuffing vulnerabilities (no rate limiting on login), storing passwords as MD5 or SHA-1 without salting, exposing session tokens in URLs, and not invalidating sessions on logout. Use our Hash tool to understand why MD5 is broken for password storage. Generate strong session secrets with our Password Generator.
Security Misconfiguration
The most common category in practice: default credentials left unchanged, debug mode left on in production, directory listing enabled on web servers, CORS configured with Access-Control-Allow-Origin: *, overly permissive IAM roles, and verbose error messages exposing stack traces. Use automated security scanners in your CI/CD pipeline to catch these before deployment.
Server-Side Request Forgery (SSRF)
SSRF tricks the server into making HTTP requests to internal resources. If your application fetches a URL provided by the user, an attacker can request http://169.254.169.254/latest/meta-data/ to steal AWS instance credentials, or scan internal services that aren't accessible from the internet. Validate and whitelist URLs before fetching them.
Security Headers Checklist
Every web application should set: Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY (prevents clickjacking), Strict-Transport-Security (enforces HTTPS), Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy to restrict browser features. Check your headers at securityheaders.com after deploying.