OWASP Top 10 Explained with Real-World Examples and Fixes

The OWASP Top 10 is the most widely recognized awareness document for web application security. It represents a broad consensus about the most critical security risks. But reading a list of vulnerability categories is very different from understanding how they actually manifest in real applications. This guide bridges that gap with concrete examples and actionable fixes.

A01: Broken Access Control

Moving up from fifth place, broken access control is now the most critical web application security risk. It occurs when users can act outside their intended permissions.

Real-World Example

A common pattern: an e-commerce application exposes order details at /api/orders/12345. By simply changing the order ID, a user can view any customer's order -- including shipping addresses, payment details, and purchase history. This is an Insecure Direct Object Reference (IDOR).

How to Fix It

• Implement server-side access control checks for every request, not just in the UI
• Use indirect object references (map internal IDs to per-user tokens)
• Deny by default: require explicit grants rather than allowing unless restricted
• Log and alert on access control failures to detect probing

A02: Cryptographic Failures

Formerly "Sensitive Data Exposure," this category focuses on failures in cryptography that lead to data exposure. This includes using weak algorithms, improper key management, and transmitting data in cleartext.

Real-World Example

A healthcare application stored patient records encrypted with MD5 (a hash, not encryption) and used the same static key across all environments. An attacker who gained read access to the database could decrypt every record using rainbow tables.

How to Fix It

• Use strong, current algorithms: AES-256-GCM for encryption, bcrypt/scrypt/Argon2 for password hashing
• Enforce TLS 1.2+ for all data in transit
• Never store secrets in source code; use proper key management services
• Classify data and apply appropriate protection levels

A03: Injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection remains the most common, but the category also includes NoSQL injection, OS command injection, and LDAP injection.

Real-World Example

A login form vulnerable to SQL injection:

-- Vulnerable query:
SELECT * FROM users WHERE username = '$input' AND password = '$pass'

-- Attack input for username:
admin' OR '1'='1' --

-- Resulting query:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' --' AND password = ''

How to Fix It

• Use parameterized queries (prepared statements) for all database interactions
• Use ORMs that properly escape inputs by default
• Validate and sanitize all user input on the server side
• Apply least-privilege database permissions

A04: Insecure Design

A new category recognizing that security issues can stem from design flaws, not just implementation bugs. No amount of perfect coding can fix a fundamentally insecure design.

A05: Security Misconfiguration

This includes default credentials, unnecessary features enabled, overly verbose error messages, and missing security headers. It is the most common vulnerability we find during security audits.

How to Fix It

• Implement a hardening process for all environments
• Remove default credentials and unnecessary features/frameworks
• Add security headers: Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security
• Automate configuration verification in CI/CD pipelines

A06-A10: The Rest of the List

• A06 - Vulnerable Components: Track dependencies, subscribe to security advisories, and automate updates
• A07 - Authentication Failures: Implement MFA, rate limiting, and secure session management
• A08 - Software Integrity Failures: Verify package integrity, use signed commits, secure your CI/CD pipeline
• A09 - Logging Failures: Log security events, protect log integrity, implement alerting
• A10 - SSRF: Validate and sanitize all URLs, use allowlists, segment network access

Understanding these vulnerabilities is the first step. Preventing them requires integrating security into every phase of development. Our security audit service can help identify these issues in your applications before attackers do.