OWASP Web Top 10
The ten most critical web application security risks — with real-world examples, attack scenarios, and remediation guidance. Updated for 2021 (current standard).
Broken Access Control
CriticalAccess control enforces policies so users cannot act outside their intended permissions. Broken access control is the #1 most common vulnerability — found in 94% of applications tested. Failures lead to unauthorized data access, privilege escalation, and account takeover.
Attack examples
- Accessing another user's account by changing the
?user_id=123parameter (IDOR) - Accessing admin panels at
/adminwithout authentication - Elevating privileges by modifying
role=adminin a JWT or cookie - Browsing to any URL without being logged in (missing auth checks)
Remediation
- Deny access by default — explicitly grant permissions
- Enforce access control server-side on every request
- Use indirect object references (internal IDs, not direct DB keys)
- Log and alert on access control failures
- Rate-limit API access to reduce automated probing
GET /api/invoices?user_id=1337 → attacker changes to user_id=1338
// ✅ Fix — always use authenticated session identity
GET /api/invoices → server resolves user_id from session token
Cryptographic Failures
CriticalFormerly called "Sensitive Data Exposure," this covers failures in cryptography that lead to exposure of sensitive data — passwords, credit card numbers, health records, and more. Often it's not a complex attack; it's simply data transmitted or stored in cleartext.
Attack examples
- Passwords stored as unsalted MD5 or SHA1 hashes — trivially cracked
- Credit card data transmitted over HTTP (no TLS)
- Weak cipher suites (RC4, DES, 3DES) in TLS configuration
- Encryption keys hardcoded in source code or committed to Git
Remediation
- Use bcrypt, Argon2, or scrypt for password hashing
- Enforce HTTPS everywhere with HSTS headers
- Disable deprecated TLS versions (TLS 1.0, 1.1)
- Never store sensitive data you don't need to store
- Use authenticated encryption (AES-GCM, ChaCha20-Poly1305)
Injection
CriticalInjection flaws occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection remains the most impactful, but this category covers XSS, OS command injection, LDAP injection, and more. Successful injection can result in full data exfiltration or server compromise.
Attack examples
- SQL:
' OR '1'='1to bypass login - XSS: injecting
<script>document.cookie</script> - OS command injection via unsanitised shell parameters
- SSTI:
{{7*7}}evaluated server-side in template engines
Remediation
- Use parameterised queries / prepared statements for all DB calls
- Validate and sanitise all user input server-side
- Encode output for the context (HTML, JS, URL)
- Use a WAF as a defence-in-depth layer
- Apply least privilege to DB accounts (no DROP/ALTER)
query = "SELECT * FROM users WHERE email='" + email + "'"
// ✅ Parameterised query
query = "SELECT * FROM users WHERE email = ?"
db.execute(query, [email])
Insecure Design
HighNew in 2021, this category covers risks from flawed design decisions — not implementation bugs. Insecure design cannot be fixed by a perfect implementation; the architecture itself is fundamentally broken. Threat modelling and security requirements must happen at design time.
Attack examples
- Password reset flow that exposes the token in the URL (emails indexed by proxies)
- No rate limiting on OTP, allowing brute-force of 6-digit codes in ~17 minutes
- Multi-tenant app that stores all tenants' data in the same DB tables without partitioning
- "Security questions" as account recovery — trivially guessable
Remediation
- Threat model every feature before building it
- Design security requirements alongside functional requirements
- Use secure design patterns and reference architectures
- Integrate security into agile and design sprints
- Use plausibility checks for all user flows (how many orders can a user place per day?)
Security Misconfiguration
High90% of applications have some form of misconfiguration. This includes default credentials, overly permissive CORS, exposed error messages, cloud storage misconfiguration, and missing security headers. Misconfig is consistently the easiest vulnerability to exploit.
Attack examples
- Default admin credentials on network devices (admin/admin)
- Stack traces exposed in production error pages
- S3 bucket publicly readable — exposing customer PII
- Directory listing enabled on web server
- Permissive CORS:
Access-Control-Allow-Origin: *on authenticated endpoints
Remediation
- Establish a hardening baseline and automate it (IaC)
- Change all default credentials immediately after deployment
- Disable all unnecessary features, ports, and services
- Add security headers: CSP, HSTS, X-Frame-Options, etc.
- Continuously scan for misconfigurations in CI/CD
Vulnerable & Outdated Components
HighUsing libraries, frameworks, and other software components with known vulnerabilities is extremely common and high-risk. Log4Shell (CVE-2021-44228), Heartbleed, and Struts2 are all examples of third-party component vulnerabilities that caused massive breaches worldwide.
Attack examples
- Log4j 2.x with JNDI lookup enabled → RCE (Log4Shell)
- OpenSSL with Heartbleed → memory disclosure
- Outdated WordPress plugins with known CVEs
- npm packages with known prototype pollution vulnerabilities
Remediation
- Maintain a software bill of materials (SBOM)
- Use Dependabot, Snyk, or OWASP Dependency-Check
- Remove unused dependencies, features, and files
- Subscribe to CVE alerts for your critical components
- Pin dependency versions and audit regularly
Identification & Authentication Failures
CriticalWeaknesses in authentication and session management allow attackers to compromise passwords, keys, or session tokens — or to exploit implementation flaws to assume the identity of legitimate users temporarily or permanently.
Attack examples
- No brute-force protection on login — automated credential stuffing
- Predictable or short session tokens
- Session not invalidated on logout
- Passwords checked against known breach lists (Have I Been Pwned)
- No MFA on admin or sensitive accounts
Remediation
- Implement MFA wherever possible — especially for admin access
- Use a battle-tested auth library, don't roll your own
- Enforce rate limiting and account lockout on login
- Use long, random session IDs and invalidate on logout
- Check new passwords against breach databases
Software & Data Integrity Failures
HighThis category covers code and infrastructure that doesn't protect against integrity violations — including insecure CI/CD pipelines, auto-update mechanisms that fetch unsigned packages, and deserialization of untrusted data that can lead to RCE.
Attack examples
- SolarWinds supply chain attack via compromised build pipeline
- Deserialization of untrusted Java objects → RCE
- npm package hijacking (typosquatting, dependency confusion)
- CDN resources loaded without Subresource Integrity (SRI) checks
Remediation
- Sign and verify software packages and updates
- Secure CI/CD pipelines — treat as critical infrastructure
- Use SRI hashes for all CDN-loaded resources
- Avoid deserializing untrusted data; prefer JSON over binary serialisation
- Review third-party dependencies before inclusion
Security Logging & Monitoring Failures
MediumInsufficient logging and monitoring is what allows attackers to persist in your environment for weeks or months undetected. The average breach dwell time is 207 days. Without proper logging, you can't detect attacks, respond to incidents, or conduct forensic investigation.
What's typically missing
- Login failures not logged (or logs not reviewed)
- No alerts on impossible travel or suspicious access patterns
- Logs stored locally on the same server that was compromised
- Penetration tests revealing no detection within 30 days
Remediation
- Log all auth events, access control failures, and input validation errors
- Centralise logs to a SIEM (Splunk, Elastic, etc.)
- Set up automated alerts on anomalies and high-severity events
- Define and test your incident response plan
- Protect logs from tampering — use append-only storage
Server-Side Request Forgery (SSRF)
CriticalSSRF flaws occur when a web application fetches a remote resource based on user-supplied input without validating the URL. An attacker can coerce the server to make requests to internal services, cloud metadata endpoints, or other systems that are normally unreachable from the internet.
Attack examples
- Accessing AWS metadata service:
http://169.254.169.254/latest/meta-data/iam/security-credentials/ - Port-scanning internal services via the vulnerable server
- Bypassing IP allowlists by routing requests through trusted server
- Reading internal-only files via
file:///etc/passwdscheme
Remediation
- Validate and sanitise all user-supplied URLs
- Use an allowlist of permitted domains and IPs
- Block requests to private/reserved IP ranges at network level
- Disable unused URL schemas (file://, gopher://, dict://)
- Use IMDSv2 on AWS (requires PUT token, prevents simple SSRF)
url = request.params['url']
response = http.get(url) # attacker sends http://169.254.169.254/
// ✅ Allowlist approach
ALLOWED_HOSTS = ['api.partner.com', 'cdn.example.com']
if parsed_url.hostname not in ALLOWED_HOSTS: raise ForbiddenError
Know if your app has
any of these vulnerabilities
Our web app pentesting service covers the full OWASP Top 10 — manually verified with proof-of-concept exploits, not just scanner output.