← Back to Blog
Research 25 min read

OWASP Top 10 2025: The Complete Guide to Web Application Security Risks

The OWASP Top 10 is the most widely recognized standard for web application security risks. Whether you're a developer, security engineer, or business leader — this guide explains every category with real-world examples, detection techniques, and remediation strategies.

ℹ️ What is the OWASP Top 10?

A periodically updated awareness document that ranks the most critical security risks to web applications. Based on data analysis from hundreds of organisations, community surveys, and real-world breach data. Referenced by PCI DSS, DORA, NIS2, and many industry standards.


A01 Broken Access Control

#1 most common vulnerability — found in 94% of tested applications.

⚠️ Real-World Examples

  • IDOR: Changing /api/users/123/profile to /api/users/124/profile
  • Privilege escalation: Regular user accessing /admin/dashboard
  • Missing function-level access control: API checks auth but not authorisation
  • CORS misconfiguration: Allowing malicious sites to make authenticated requests

✅ Remediation

  • Implement access control server-side — never rely on client-side
  • Deny by default — require explicit grants
  • Implement proper RBAC or ABAC
  • Log and alert on access control failures
  • Rate-limit API access

A02 Cryptographic Failures

Previously "Sensitive Data Exposure" — renamed to focus on the root cause.

⚠️ Common Mistakes

  • Login pages transmitting credentials over plain HTTP
  • Supporting TLS 1.0/1.1 or weak cipher suites
  • Passwords stored with MD5 or SHA-1 instead of bcrypt/Argon2
  • Hardcoded encryption keys in source code
  • Database backups without encryption

✅ Remediation

Enforce HTTPS everywhere with HSTS. Use AES-256, bcrypt/Argon2, SHA-256+. Never hardcode secrets — use Vault or AWS Secrets Manager. Encrypt data at rest. Disable TLS 1.0/1.1.

A03 Injection

The classic web vulnerability — still in the top 3 after two decades.

Types of Injection

  • SQL Injection: ' OR 1=1 -- and far more sophisticated attacks
  • NoSQL Injection: JSON manipulation of MongoDB/CouchDB
  • Command Injection: OS commands through application inputs
  • XSS: Injecting JavaScript — reflected, stored, DOM-based
  • Template Injection (SSTI): Code into server-side template engines
  • Header Injection: Manipulating HTTP headers

✅ Prevention

Parameterized queries for all DB interactions. Input validation with allowlists. Output encoding for context. Content Security Policy headers. Least privilege DB accounts. Use ORMs consistently.

A04 Insecure Design

New category — design-level flaws, not implementation bugs.

⚠️ Examples

  • Password reset flow allowing unlimited attempts (no rate limiting)
  • Client-side enforcement of business rules (price validation in JS)
  • Single API key granting both read and write access to all resources

Fix: Integrate threat modeling (STRIDE, PASTA) into design phase. Use secure design patterns. Write abuse cases alongside use cases.

A05 Security Misconfiguration

Found in 90% of tested applications.

⚠️ Common Misconfigurations

  • Default admin passwords on databases and admin panels
  • Directory listing, debug endpoints, verbose error messages enabled
  • Missing security headers (CSP, X-Frame-Options, X-Content-Type-Options)
  • Publicly accessible S3 buckets or Azure blobs
  • Unnecessary HTTP methods (PUT, DELETE, TRACE) enabled

✅ Prevention

Repeatable hardening process. Remove all unnecessary features. Implement all security headers. Automate config management with IaC. Regular config audits. Use CSPM for cloud.

A06 Vulnerable and Outdated Components

528
Avg. Components/App
84%
Codebases with Known Vulns
48%
High-Risk Vulnerabilities
252d
Avg. Fix Time

⚠️ Notable Examples

  • Log4Shell (CVE-2021-44228): Critical RCE affecting millions of Java apps
  • Spring4Shell (CVE-2022-22965): RCE in Spring Framework
  • jQuery XSS: Many apps still use vulnerable jQuery versions

Fix: Maintain component inventory (SBOM). Continuously monitor CVE databases. Remove unused dependencies. Automate updates with Dependabot/Renovate.

A07 Identification and Authentication Failures

⚠️ Common Failures

  • Credential stuffing: Automated attacks using stolen passwords
  • Weak password policies (allowing "password123")
  • Session fixation and missing session invalidation
  • Session tokens exposed in URLs
  • Missing MFA for critical functions

✅ Prevention

Implement MFA. Enforce strong passwords with breach database checking. Rate limiting on auth endpoints. Secure session management (random IDs, HTTPOnly/Secure flags). Invalidate sessions on logout/password change.

A08 Software and Data Integrity Failures

⚠️ Real-World Attacks

  • SolarWinds (2020): Malicious code in legitimate software update — 18,000 orgs affected
  • Insecure deserialization: Arbitrary code execution via untrusted data
  • CI/CD pipeline compromise: Codecov, ua-parser-js incidents
  • Missing SRI: Loading JS from CDNs without integrity hashes

Fix: Digital signatures on all software/data. Subresource Integrity (SRI) for external resources. Secure CI/CD with access controls and signing. Avoid insecure deserialization — use JSON.

A09 Security Logging and Monitoring Failures

ℹ️ The Cost of Blindness

Average time to identify a breach: 204 days (IBM 2024). Without adequate logging, attackers can establish persistence, exfiltrate data, and expand their foothold — all without triggering alarms.

Fix: Log all auth events, access control failures, and input validation failures. Include context (timestamp, user, IP, action). Centralise logs in a tamper-resistant SIEM. Implement automated alerting. Test detection capabilities regularly.

A10 Server-Side Request Forgery (SSRF)

New category — added due to increasing prevalence in cloud-native architectures.

⚠️ Why SSRF is Dangerous

  • Capital One breach (2019): SSRF → AWS metadata → 100M+ customer records exposed
  • Cloud metadata theft: Accessing http://169.254.169.254/ for IAM credentials
  • Internal service access: Reaching APIs, databases, admin panels behind the firewall

✅ Prevention

Validate all user-supplied URLs server-side. Use allowlists for permitted domains. Block private IP ranges (10.x, 172.16.x, 169.254.x, 127.x). Disable unnecessary URL schemes (file://, gopher://). Use IMDSv2 on AWS. Segment URL-fetching services.


How KENSAI Scans for the OWASP Top 10

OWASP CategoryKENSAI Coverage
A01 Broken Access ControlIDOR testing, authorization bypass, CORS checks
A02 Cryptographic FailuresTLS analysis, header checks, encryption verification
A03 InjectionSQL, XSS, command injection, SSTI, header injection
A04 Insecure DesignRate limiting, predictable resources, logic testing
A05 Security MisconfigurationHeaders, defaults, information disclosure, HTTP methods
A06 Vulnerable ComponentsTechnology fingerprinting, 332K+ CVE database
A07 Authentication FailuresDefault credentials, session testing, cookie analysis
A08 Integrity FailuresSRI checks, deserialization testing
A09 Logging FailuresSecurity header analysis, error handling review
A10 SSRFInternal endpoint injection, cloud metadata testing
332K+
CVEs Tracked
10/10
OWASP Coverage
AI
Powered Accuracy
€990
Starting Price/mo

Test Your App Against the OWASP Top 10

Free scan — no commitment, no credit card required. AI-powered DAST with compliance-ready reporting.

Start Free Scan →

FAQ

What is the most common OWASP vulnerability?

Broken Access Control (A01) — found in 94% of tested applications. It moved from position 5 to position 1, reflecting widespread failure to enforce authorization, particularly in APIs and SPAs.

Is OWASP Top 10 compliance mandatory?

The OWASP Top 10 itself is voluntary. However, it's referenced by PCI DSS (requires addressing OWASP Top 10), NIS2 (expects systematic vulnerability management), DORA (references industry-standard testing), and many vendor assessments. In practice, it's effectively mandatory.

Can automated tools detect all OWASP Top 10?

Automated DAST tools effectively detect most categories — especially injection (A03), cryptographic failures (A02), misconfiguration (A05), and vulnerable components (A06). Some categories like Insecure Design (A04) and Logging Failures (A09) often require manual assessment. Use automated scanning for breadth + manual testing for depth.

How often is the OWASP Top 10 updated?

Every 3–4 years. Major releases: 2013, 2017, 2021. Each update reflects threat landscape shifts — the 2021 update introduced Insecure Design (A04) and SSRF (A10) while reorganizing others.

Security is not optional.

🗡️ The KENSAI Team