OWASP Top 10

Posted Jun 9, 2025

90 min read

OWASP Top 10

Navigating the Evolving Threat Landscape: A Deep Dive into the OWASP Top 10

The digital world is in a constant state of flux, with web applications at the forefront of innovation and, unfortunately, also a primary target for malicious actors. Understanding and mitigating the most common security risks is paramount for any organization that develops or utilizes web applications. The Open Worldwide Application Security Project (OWASP) provides an invaluable resource in this endeavor: the OWASP Top 10. This report aims to provide an expert-level understanding of the OWASP Top 10, its evolution, a detailed examination of the current 2021 list, and practical guidance for both offensive (Red Team) and defensive (Blue Team) cybersecurity professionals.

Section 1: Introduction to OWASP and the Top 10

The Open Worldwide Application Security Project (OWASP) is a non-profit foundation dedicated to improving software security globally.1 Founded in 2001, OWASP operates as an open community, providing free and accessible resources, including tools, documentation, forums, and educational materials, to help organizations and individuals develop, purchase, and maintain trustworthy applications.2 With over 250 local chapters worldwide, OWASP fosters collaboration among security experts, developers, and organizations to power secure software through education and shared knowledge.2

Among its many initiatives, the OWASP Top 10 is arguably its most recognized and influential project.3 The OWASP Top 10 is a standard awareness document that identifies the ten most critical security risks to web applications.5 This list is compiled based on a broad consensus among security experts worldwide, drawing from extensive data and experience from an open community of contributors.2

The primary purpose of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the most prevalent and impactful web application vulnerabilities.3 It serves as a crucial guide for companies, DevOps teams, and regulators to understand and address these risks, thereby fostering a culture of more secure software development.2 By highlighting common pitfalls, the Top 10 helps organizations prioritize their security efforts, directing resources towards mitigating the most severe threats.3 This focus not only improves the security posture of applications, keeping users’ confidential data safe from attackers, but also supports regulatory compliance efforts.3

Section 2: The Evolution of the OWASP Top 10 – Understanding the 2021 Landscape

The OWASP Top 10 is not a static list; it is periodically updated to reflect the dynamic nature of web application security threats, evolving attack techniques, and emerging vulnerabilities.3 First published in 2003, it has seen several revisions, with the most current version at the time of this report being the 2021 list, which succeeded the 2017 version.3 These updates are critical for maintaining the list’s relevance as a benchmark for application security standards.6

The OWASP Top 10 2021 introduced significant changes from the 2017 iteration, reflecting shifts in the cybersecurity landscape. This update was driven by a data-centric approach, incorporating information from numerous organizations and security experts to rank vulnerabilities based on factors such as frequency of occurrence, exploitability, and potential impact.2

Key changes in the 2021 list include the introduction of new categories, the merging or renaming of existing ones, and notable shifts in ranking:

A01:2021 Broken Access Control ascended from the fifth position in 2017 to become the most serious web application security risk. Data indicated that 94% of applications tested exhibited some form of broken access control.3
A02:2021 Cryptographic Failures moved up one position to #2. This category was previously known as A3:2017-Sensitive Data Exposure, with the renaming intended to focus on the root cause (failures in cryptography) rather than solely the symptom.8
A03:2021 Injection slid from the top spot in 2017 to #3. Importantly, Cross-Site Scripting (XSS), which was A7:2017, was merged into this broader Injection category in the 2021 list.7
A04:2021 Insecure Design is a new category for 2021. It emphasizes the importance of addressing risks related to design flaws and calls for increased use of threat modeling, secure design patterns, and reference architectures from the outset of development.8
A05:2021 Security Misconfiguration moved up from #6 in the 2017 list. The former A4:2017-XML External Entities (XXE) category was incorporated into this risk category.8
A06:2021 Vulnerable and Outdated Components, previously A9:2017-Using Components with Known Vulnerabilities, climbed to #6.8
A07:2021 Identification and Authentication Failures, formerly A2:2017-Broken Authentication, moved down in ranking. The 2021 version now includes Common Weakness Enumerations (CWEs) more broadly related to identification failures.7
A08:2021 Software and Data Integrity Failures is another new category. It focuses on risks associated with assumptions about software updates, critical data, and CI/CD pipelines without verifying integrity. The A8:2017-Insecure Deserialization vulnerability is now part of this more comprehensive category.8
A09:2021 Security Logging and Monitoring Failures retained its significance, highlighting the critical need for effective detection and response capabilities.8
A10:2021 Server-Side Request Forgery (SSRF) was introduced as a new category, largely driven by input from the Top 10 community survey, signaling its growing importance in the threat landscape.8

The following table summarizes these key changes:

Table 1: Key Changes from OWASP Top 10 2017 to 2021


2017 Rank & Vulnerability	2021 Rank & Vulnerability	Nature of Change & Brief Rationale
A1: Injection	A01:2021 Broken Access Control	Shifted (A05:2017 -> A01:2021). Data showed extremely high prevalence (94% of apps tested).3
A2: Broken Authentication	A02:2021 Cryptographic Failures	Renamed & Shifted (A03:2017-Sensitive Data Exposure -> A02:2021). Focus on root cause (cryptography) over symptom.8
A3: Sensitive Data Exposure	A03:2021 Injection	Shifted (A01:2017 -> A03:2021) & Merged. Now includes Cross-Site Scripting (A07:2017).7
A4: XML External Entities (XXE)	A04:2021 Insecure Design	New Category. Focus on pre-code design flaws, threat modeling, and secure architecture.8
A5: Broken Access Control	A05:2021 Security Misconfiguration	Shifted (A06:2017 -> A05:2021) & Merged. Now includes XML External Entities (A04:2017).8
A6: Security Misconfiguration	A06:2021 Vulnerable and Outdated Components	Shifted & Renamed (A09:2017-Using Components with Known Vulnerabilities -> A06:2021).8
A7: Cross-Site Scripting (XSS)	A07:2021 Identification and Authentication Failures	Shifted & Renamed (A02:2017-Broken Authentication -> A07:2021). Broader scope including identification failures.7
A8: Insecure Deserialization	A08:2021 Software and Data Integrity Failures	New Category & Merged. Focus on CI/CD, updates, data integrity; includes Insecure Deserialization (A08:2017).8
A9: Using Components with Known Vulnerabilities	A09:2021 Security Logging and Monitoring Failures	Shifted (A10:2017 -> A09:2021). Continued emphasis on detection and response capabilities.8
A10: Insufficient Logging & Monitoring	A10:2021 Server-Side Request Forgery (SSRF)	New Category. Added from community survey, highlighting its rising importance.8

Data Sources: 3

A significant trend observable in the 2021 OWASP Top 10 is a stronger emphasis on proactive security measures and systemic issues, rather than focusing solely on isolated implementation bugs. The introduction of “Insecure Design” (A04) directly calls for integrating security considerations from the earliest stages of the development lifecycle, including “more threat modeling, secure design patterns and principles, and reference architectures”.8 This signifies a call to address security “pre-code.” Similarly, “Software and Data Integrity Failures” (A08) tackles broader challenges such as the security of CI/CD pipelines and the integrity of software updates, which are systemic concerns rather than simple coding errors.8 The renaming of “Sensitive Data Exposure” to “Cryptographic Failures” (A02) also reflects this shift by targeting the underlying cause—failures in the application of cryptography—instead of just the resulting symptom.8 This evolution indicates that effective application security demands a holistic strategy, moving beyond fixing individual vulnerabilities to embedding security into design and management practices.3 For development and security teams, this means that security cannot be an afterthought; it must be an integral part of the entire software development lifecycle (SDLC). For those on the offensive side, this suggests that avenues for exploitation may lie not only in common code-level bugs but also in flawed designs and vulnerable development processes.

Section 3: The OWASP Top 10 2021 Vulnerabilities: A Deep Dive for Practitioners

This section provides a detailed examination of each vulnerability in the OWASP Top 10 2021 list, offering insights for both Red Team (offensive) and Blue Team (defensive) cybersecurity professionals.

3.1 A01:2021 – Broken Access Control

Understanding Broken Access Control

Broken Access Control (BAC) occurs when an application fails to properly enforce restrictions on what authenticated users are permitted to do. This allows attackers to access functionalities or data that should be outside their authorized scope.2 It can manifest as users gaining access to other users’ accounts, viewing sensitive files, modifying unauthorized data, or invoking administrative or privileged functions.2 The severity of this vulnerability is underscored by its top ranking in the 2021 list, with data indicating that a staggering 94% of tested applications exhibited some form of BAC.3 The impact can be severe, leading to unauthorized data disclosure, modification, or destruction, and the ability for attackers to perform privileged actions.16

Common manifestations of Broken Access Control include 4:

Bypassing access control checks by modifying URLs, internal application states, or HTML page content.
Insecure Direct Object References (IDOR), where an attacker can view or edit another user’s data by simply changing a unique identifier (e.g., a user ID) in a request.
Vertical privilege escalation (gaining higher privileges, like admin rights) or horizontal privilege escalation (accessing another user’s data at the same privilege level).
Manipulation of metadata, such as replaying or tampering with JSON Web Tokens (JWTs) that manage access control.
CORS (Cross-Origin Resource Sharing) misconfigurations that permit unauthorized API access from different origins.
Forced browsing, where an attacker navigates directly to authenticated pages without being authenticated, or to privileged pages as a standard user.

Red Team Insights: Detection and Exploitation

Attackers employ various methods to detect Broken Access Control vulnerabilities. Manual testing is often key, involving the manipulation of parameters in URLs, hidden form fields, cookies, and query strings to probe for weaknesses.14 Forced browsing, attempting to access URLs that are not directly linked (e.g., /admin/config), can uncover unprotected administrative routes.14 Tools such as DAST (Dynamic Application Security Testing) scanners, manual penetration testing utilities, and general vulnerability scanners are also used to systematically test for IDORs, directory traversal flaws, and other URL-based access control issues.18 Another technique involves attempting to use alternative HTTP methods (e.g., sending a GET request to an endpoint expecting POST) to see if access controls are bypassed.18

Exploitation techniques often involve:

IDOR: Changing identifiers in URLs, such as modifying /account/1234 to /account/1235, to access or manipulate another user’s data.14
Token Manipulation: Modifying, replaying, or forging session tokens or JWTs to impersonate other users or escalate privileges.14
Method Tampering: Sending unauthorized HTTP requests (e.g., POST, PUT, DELETE) to endpoints that lack proper server-side checks for those methods.14
Platform Misconfiguration Exploitation: Leveraging misconfigurations like overriding request URLs using HTTP headers such as X-Original-URL or X-Rewrite-URL.18
Location Bypass: Using VPNs, proxy servers, or manipulating HTTP headers to circumvent location-based access controls.18

Real-world examples illustrate the impact:

Facebook (2013): A researcher discovered a flaw allowing the deletion of photos from any user’s account.18
Instagram (2019): An IDOR vulnerability enabled attackers to view private posts and stories by manipulating user IDs in API requests.18
GitHub (2022): A privilege escalation bug permitted users to gain unauthorized higher access levels within repositories.18
Optus (2023): An IDOR vulnerability allowed a malicious actor to directly access and enumerate nearly 10 million customer records.18

Blue Team Countermeasures: Detection and Mitigation

Defenders can detect potential Broken Access Control issues by regularly auditing access logs for anomalous activities such as unusual access patterns or repeated unauthorized attempts.18 Tracking failed access attempts is crucial; a high volume of HTTP 403 (Forbidden) errors or unauthorized requests can be an early indicator of probing or active attack attempts.14

Effective mitigation strategies include:

Server-Side Authorization: This is non-negotiable. Never rely solely on client-side controls (e.g., hiding buttons in the UI). Permissions must be validated on the server-side for every single request.14
Principle of Least Privilege / Deny by Default: Grant users only the minimum access necessary to perform their tasks. Access should be denied by default and explicitly granted only where needed.14
Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC): Implement and consistently enforce these access control models. Centralize role logic to ensure consistency across all services and endpoints.14 For example, in C#, an action method can be restricted to administrators using an attribute like ``.20 When fetching user-specific data, ensure the query explicitly checks ownership, e.g., FirstOrDefault(doc => doc.DocumentId == documentId && doc.OwnerId == userId);.20
Secure API Endpoints: Treat API access control with the same rigor as web UI routes. APIs are a common blind spot.14
Secure Session Management: Implement secure session tokens with appropriate timeout settings to prevent session hijacking.18 Session identifiers should be invalidated upon logout.17
Multi-Factor Authentication (MFA): While primarily an authentication control, MFA enhances overall identity verification, making it harder for attackers to abuse compromised credentials to test access controls.18
Centralized Enforcement: Utilize centralized, server-side mechanisms for all permission checks to ensure consistency.18
Rate Limiting: Implement rate limiting on API and controller access to hinder automated attacks aimed at discovering or exploiting access control flaws.16
System Hardening: Shut down unnecessary services and delete inactive or unneeded user accounts to reduce the attack surface.16
Secure by Design: Define access control requirements during the architecture and threat modeling phases of the SDLC.18

The extreme prevalence of Broken Access Control, with 94% of tested applications showing flaws 3, despite access control being a well-established security principle, points to a significant disconnect between understanding and consistent implementation. Fundamental concepts like the principle of least privilege have existed for decades. Yet, attackers frequently succeed with straightforward techniques like modifying a URL parameter.14 This widespread issue suggests that while the principles are known, their rigorous and uniform application across all facets of an application—including web UIs, APIs, and backend processes—remains a substantial challenge. Factors contributing to this gap likely include development pressures, the complexity of large-scale applications, simple oversight, or an over-reliance on client-side controls which are easily bypassed. This underscores the paramount importance of mastering and meticulously applying these foundational security controls. Defensive teams require robust, repeatable processes for implementing and testing access controls universally. For offensive teams, these often “easy win” vulnerabilities should always be on the checklist, as their high likelihood of presence makes them attractive targets. The sheer prevalence also indicates that automated tools alone are insufficient without thorough manual review and testing of access control logic.

3.2 A02:2021 – Cryptographic Failures

Understanding Cryptographic Failures

Cryptographic Failures, ranked #2 in the OWASP Top 10 2021, refer to vulnerabilities related to the misuse, weak implementation, or absence of cryptography, leading to the exposure of sensitive data.8 This category was previously named “Sensitive Data Exposure” in the 2017 list; the change in nomenclature emphasizes the root cause—failures in cryptographic mechanisms—rather than just the symptom of data exposure.8 These failures can affect data both in transit (e.g., lack of TLS, use of weak TLS ciphers) and at rest (e.g., unencrypted storage, use of weak encryption algorithms, poor key management practices).4

The impact of cryptographic failures can be severe, leading to the compromise of sensitive information such as passwords, credit card numbers, health records, and other personally identifiable information (PII). Such breaches can result in identity theft, financial fraud, significant reputational damage to the organization, and non-compliance with data protection regulations.24

Common Weakness Enumerations (CWEs) associated with this category highlight typical failure points 23:

CWE-319 (Cleartext Transmission of Sensitive Information): Transmitting data over unencrypted protocols like HTTP, SMTP, or FTP.
CWE-327 (Use of a Broken or Risky Cryptographic Algorithm): Employing outdated or known vulnerable algorithms such as SSL 2.0/3.0, RC4, DES, or weak hashing functions like MD5 and SHA1.
CWE-320/CWE-259 (Improper Key Management / Use of Hard-coded Password): Using default, weak, or reused cryptographic keys; failing to rotate keys; or hardcoding keys or passwords directly into source code.
CWE-523/CWE-295 (Unencrypted Protected Storage / Improper Certificate Validation): Failing to enforce encryption (e.g., missing HTTP Strict Transport Security - HSTS header) or improperly validating server certificates, which can lead to Man-in-the-Middle (MITM) attacks.
CWE-329/CWE-780 (Not Using a Random IV with CBC Mode / Use of RSA Algorithm without OAEP): Using insecure cryptographic modes like Electronic Codebook (ECB) or employing predictable or reused Initialization Vectors (IVs).
CWE-261 (Weak Encoding for Passwords): Using passwords directly as cryptographic keys without a proper Key Derivation Function (KDF).
CWE-331/CWE-332 (Insufficient Entropy / Insufficiently Random Values): Using random number generators that do not meet cryptographic security standards or are poorly seeded.

Red Team Insights: Detection and Exploitation

Detecting cryptographic failures involves a range of techniques 23:

Network Traffic Analysis: Using network sniffers to check if sensitive data is transmitted in clear text over protocols like HTTP, SMTP, or FTP.23
Algorithm and Protocol Identification: Identifying the use of old or weak cryptographic algorithms (e.g., DES, RC4, MD5, SHA1) or protocols (e.g., SSLv3, early TLS versions) through server configuration checks or protocol analysis.23
Key Management Review: Searching for hardcoded keys in client-side code, configuration files, or public repositories. Assessing key generation, storage, and rotation practices if possible.23
Security Header Checks: Verifying the presence and correct configuration of HTTP security headers like HSTS, which enforce HTTPS.23
Certificate Validation Testing: Assessing if client applications properly validate server certificates and their trust chains to prevent MITM attacks.23
Cryptographic Implementation Probing: Testing for insecure IV usage (e.g., static or predictable IVs), use of weak modes like ECB (identifiable by patterns in ciphertext), or reliance on deprecated hash functions.23
Exploiting Error Messages/Side Channels: Leveraging cryptographic error messages or side-channel information, such as in padding oracle attacks.23

Exploitation techniques vary based on the specific failure:

Intercepting Cleartext Data: Passive sniffing of unencrypted network traffic can reveal sensitive information like login credentials.24
Breaking Weak Encryption: Actively decrypting data protected by outdated or flawed algorithms (e.g., DES, or ECB mode if patterns are discernible).24
Compromising Cryptographic Keys: If keys are hardcoded, discovered in repositories, or weakly generated, they can be used to decrypt sensitive data.24
Downgrade Attacks: Forcing a connection to downgrade from HTTPS to HTTP if HSTS is not properly implemented, then intercepting data.24
Man-in-the-Middle (MITM) Attacks: Exploiting flawed SSL/TLS certificate validation to intercept and potentially modify encrypted communications.24
Brute-Forcing Weak Hashes/Keys: Attacking passwords stored with weak hashing algorithms or passwords used directly as encryption keys.24

Notable incidents stemming from cryptographic failures include:

Heartbleed (OpenSSL): A flaw in the OpenSSL cryptographic library’s TLS implementation allowed attackers to read sensitive memory from affected servers, exposing private keys, session cookies, and passwords.25
Dual EC DRBG Backdoor: Concerns were raised about an intentionally weakened random number generation algorithm standardized by NIST, potentially allowing decryption by those aware of the backdoor.25
Exactis Data Breach (2018): The exposure of a database containing approximately 340 million individual records, including personal details, highlighted failures in protecting data at rest.25
Facebook Plain Text Passwords: Reports surfaced that Facebook had stored millions of user passwords in plain text, accessible to thousands of employees, a significant failure in protecting credentials at rest.25

Blue Team Countermeasures: Detection and Mitigation

Defensive teams should regularly audit their applications and systems for signs of cryptographic weaknesses.23 This includes checking for cleartext data transmission, use of weak or deprecated algorithms and protocols, inadequate key management practices, missing or misconfigured security headers (like HSTS), improper SSL/TLS certificate validation by clients, insecure IVs or modes of operation, use of deprecated hash functions, and any cryptographic error messages that might leak information.

Mitigation of cryptographic failures requires a multi-faceted approach 4:

Data Classification: Identify and classify data based on sensitivity according to privacy laws (e.g., GDPR, HIPAA), regulatory requirements, or business needs. This determines the level of protection required.22
Minimize Data Storage: Do not store sensitive data unnecessarily. Discard it as soon as it’s no longer needed, or use techniques like PCI DSS compliant tokenization or truncation. Data not retained cannot be stolen.22
Encrypt Data at Rest: All sensitive data stored on servers, databases, or backups must be encrypted using strong, industry-standard algorithms (e.g., AES-256 or stronger) and robust key management practices.4
Encrypt Data in Transit: All data transmitted over networks (internal and external) must be encrypted using secure protocols such as TLS 1.2 or higher, with strong cipher suites that support Forward Secrecy (FS). Server-side cipher prioritization should be enforced. HTTP Strict Transport Security (HSTS) should be implemented to ensure browsers only connect via HTTPS.16
Disable Caching for Sensitive Data: Configure web servers and proxies to prevent caching of responses that contain sensitive information.16
Strong Password Hashing: Store user passwords using strong, adaptive, and salted hashing functions such as Argon2, scrypt, bcrypt, or PBKDF2, with an appropriate work factor (delay factor) to make brute-forcing computationally expensive.16
Secure Key Management: Cryptographic keys must be generated with sufficient randomness and stored securely (e.g., in memory as byte arrays, or using Hardware Security Modules - HSMs). If passwords are used to derive keys, appropriate password-based key derivation functions (KDFs) must be used. Implement secure key rotation policies.22
Proper Initialization Vector (IV) Handling: IVs must be chosen appropriately for the mode of operation. For many modes, this means using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). IVs should never be reused with a fixed key.23
Use Authenticated Encryption: Employ authenticated encryption modes (e.g., AES-GCM, ChaCha20-Poly1305) instead of just encryption, as they provide both confidentiality and integrity.22
Avoid Deprecated Cryptography: Do not use deprecated algorithms (MD5, SHA1, DES, RC4), protocols (SSLv2, SSLv3), or padding schemes (PKCS#1 v1.5 for encryption).22
Verify Configurations: Independently verify the effectiveness of all cryptographic configurations and settings.22
Minimize Attack Surface: A fundamental principle is to avoid collecting and storing sensitive data unless absolutely necessary.16

The persistence of cryptographic failures often arises not from inherently flawed algorithms, but from the complexity of their correct implementation and a widespread lack of deep cryptographic expertise within development teams.8 The OWASP documentation itself highlights the extensive and technical nature of preventative measures, covering data classification, key lifecycle management, IV generation, choice of operational modes, protocol versions, and hashing functions.22 Many development teams may treat cryptography as a “black box,” and without access to pre-vetted libraries, adequate training, or expert review processes, even minor implementation errors can lead to significant, exploitable vulnerabilities.27 This underscores that merely selecting a “strong” algorithm is insufficient; the entire ecosystem supporting its implementation—including key storage, IV generation, protocol configurations, and data handling procedures—must be meticulously and correctly managed. This calls for a greater emphasis on using well-vetted cryptographic libraries, seeking expert review for any custom cryptographic implementations (or avoiding them entirely where possible), and investing in specialized training for development and security personnel. For offensive security assessments, this means looking beyond obviously weak ciphers to find subtle but critical implementation flaws.

3.3 A03:2021 – Injection

Understanding Injection

Injection flaws occur when an application incorporates untrusted data into commands or queries that are then sent to an interpreter. This can trick the interpreter into executing unintended commands or accessing data without proper authorization.2 Injection has been a persistent and dangerous vulnerability, featuring in the OWASP Top Ten since its inception in 2003.4 In the 2021 list, it is ranked #3, and notably, Cross-Site Scripting (XSS) was consolidated into this broader category.8 Data from 2021 indicated that 94% of applications were tested for some form of injection.8

The impact of successful injection attacks can be devastating, ranging from data loss, corruption, or theft, to unauthorized system access, denial of service, and even complete system compromise.16 Common types of injection include SQL Injection (SQLi), NoSQL Injection, OS Command Injection, LDAP Injection, XPath Injection, and Cross-Site Scripting (XSS), as well as Expression Language (EL) or Object Graph Navigation Library (OGNL) injection.29 The underlying cause is typically insufficient input validation or sanitization, or the improper use of application APIs when interacting with interpreters.4

Red Team Insights: Detection and Exploitation

Detecting injection vulnerabilities often involves a combination of methods:

Source Code Review: This is considered the most effective method for identifying injection flaws, as it allows for direct examination of how user input is handled and passed to interpreters.29
Automated Testing: Systematically testing all user-supplied inputs, including URL parameters, HTTP headers, cookies, and data in JSON, SOAP, or XML payloads, is crucial.29 Tools like Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Interactive Application Security Testing (IAST) can be integrated into CI/CD pipelines to identify such flaws.29
Manual Probing: Identifying input fields that are not properly sanitized or validated by sending crafted inputs designed to trigger interpreter errors or unexpected behavior.30

Exploitation techniques vary depending on the type of injection:

SQL Injection (SQLi):
- Attackers modify SQL queries by injecting special characters like single quotes (') or comment sequences (--). For example, an input like ' UNION SLEEP(10);-- can be used to test for blind SQLi by causing a time delay 29, or an input like admin'-- for a username field might bypass password checks.32
- Union-Based SQLi: Uses the UNION SQL operator to combine the results of the original query with results from a malicious query, allowing data exfiltration from other tables.30
- Error-Based SQLi: Forces the database to generate error messages that reveal information about the database structure or query results.30
Cross-Site Scripting (XSS):
- Malicious scripts (typically JavaScript) are injected into a vulnerable web application, which then delivers the script to an unsuspecting user’s browser. For instance, injecting <script>alert('XSS Attack!');</script> via a search parameter can cause the script to execute in the victim’s browser.32
- XSS can lead to session hijacking, keystroke logging, or redirection to malicious websites.30
Command Injection:
- Attackers inject operating system commands through a vulnerable application input. For example, if an application uses user input to construct a shell command like dir + userInput, an input of test.txt & del C:\Windows\System32\important.dll could execute the dir command followed by a destructive del command.32
- Successful command injection can give attackers control over the underlying server.30
LDAP Injection: Involves manipulating LDAP queries to perform unauthorized actions or gain access to information stored in directory services.33
XPath Injection: Exploits vulnerabilities in XML-based applications by injecting malicious XPath queries, potentially leading to information disclosure or unauthorized access.33

Security breaches due to injection attacks can lead to severe consequences, including theft of sensitive data (PII, financial records), data loss or corruption, Denial of Service (DoS) by overwhelming databases or crashing applications, and significant financial and reputational damage.30

Blue Team Countermeasures: Detection and Mitigation

Defensive measures include:

Intrusion Detection Systems (IDS): These can be configured to spot suspicious behavior indicative of injection attempts.16

The primary mitigation strategies for injection focus on preventing untrusted data from being misinterpreted as part of a command or query 15:

Use Safe APIs (Primary Defense): The most preferred method is to use APIs that avoid direct interaction with the interpreter or provide a parameterized interface.
- Parameterized Queries (Prepared Statements): When interacting with databases, use parameterized queries or prepared statements. This ensures that user input is treated strictly as data and not as executable code. For example, in C#, use command.Parameters.AddWithValue("@username", username); instead of string concatenation to build queries.32 Object-Relational Mapping Tools (ORMs) also generally provide this protection.16
- Caution: Even when using parameterized stored procedures, vulnerabilities can arise if the stored procedure itself dynamically concatenates queries and data or executes hostile data using functions like EXECUTE IMMEDIATE or exec().29
Server-Side Input Validation (Positive Validation): All input from untrusted sources must be validated on the server-side. Positive validation, which defines allowed patterns or characters, is generally preferred over negative validation (blacklisting bad characters). However, this is not a complete defense, as many applications legitimately require special characters.16
Context-Aware Escaping/Encoding: If dynamic queries are unavoidable, all user-supplied data must be escaped using the specific escape syntax appropriate for the target interpreter before being included in commands or queries.29 For preventing XSS, user input should be HTML encoded (e.g., using Server.HtmlEncode() in ASP.NET or libraries like Microsoft’s AntiXSS library) before being rendered on a page.32
- Note: SQL structures like table names, column names, etc., cannot be safely escaped. Therefore, user-supplied input should never be used to form these parts of a query.29
Principle of Least Privilege: Application accounts should connect to databases and other interpreters with the minimum privileges necessary for their tasks. This limits the potential damage if an injection flaw is successfully exploited.33
SQL Controls for Limiting Disclosure: Use database controls like LIMIT (or TOP in SQL Server) within queries to prevent the mass disclosure of records in the event of a successful SQL injection.16
Content Security Policy (CSP): Implement CSP headers to restrict the sources from which scripts can be loaded and executed, providing a strong defense against many XSS attacks.32
HttpOnly and Secure Flags for Cookies: Set the HttpOnly flag on session cookies to prevent client-side scripts from accessing them, and the Secure flag to ensure they are only transmitted over HTTPS.32
Web Application Firewalls (WAFs): WAFs can provide an additional layer of defense by detecting and blocking known injection patterns. For example, F5 Distributed Cloud WAF can be configured in blocking mode to mitigate such attacks.34
OWASP Resources: Consult OWASP’s Injection Prevention Cheat Sheet, SQL Injection Prevention Cheat Sheet, OS Command Injection Defense Cheat Sheet, and LDAP Injection Prevention Cheat Sheet for detailed guidance.4

The enduring presence of injection vulnerabilities at the top of security risk lists since 2003 4, and its high prevalence in 2021 with 94% of tested applications showing some form of injection 29, underscores a persistent and fundamental challenge in web application security: the difficulty of consistently and correctly handling untrusted user input. The core problem often lies in “untrusted data [being] sent to an interpreter” 16 or when “user-supplied data is not validated, filtered, or sanitized”.29 This indicates a recurring failure to treat all external input as potentially hostile across a diverse range of interpreters, including SQL databases, operating system shells, LDAP directories, and web browsers (in the case of XSS). The consolidation of XSS into the broader Injection category in the 2021 list 8 further emphasizes that the underlying principle—untrusted data causing unintended execution—is the central theme, irrespective of the specific interpreter involved. This reinforces the critical “never trust user input” mantra. Defensive teams must implement robust, multi-layered defenses such as parameterization, validation, and encoding consistently across all input vectors. For offensive teams, the continued prevalence and diversity of injection flaws make them a high-value and frequently successful target.

3.4 A04:2021 – Insecure Design

Understanding Insecure Design

Insecure Design is a new category introduced in the OWASP Top 10 2021, ranking at #4. It focuses on vulnerabilities stemming from flaws in the design and architecture of an application, characterized by “missing or ineffective control design”.8 This category is distinct from insecure implementation; while a secure design can still suffer from implementation bugs, an insecure design cannot be rectified by perfect coding because the necessary security controls were never conceptualized or planned into the system from the beginning.11 The emphasis is on “pre-code” activities and integrating security into the earliest phases of the software development lifecycle.11

The impact of insecure design can be varied and severe, potentially leading to unauthorized access, data leakage, abuse of business logic, denial of service, or other exploits depending on the specific design flaw.38 Root causes often include 37:

A lack of business risk profiling during development, leading to an underestimation of the required security level.
Security considerations not being integrated into early planning and requirements gathering phases.
Pressure to release features quickly, sidelining thorough threat modeling.
An underestimation of how attackers can creatively abuse application logic.
Designing overly permissive workflows that prioritize user experience (UX) at the expense of robust risk controls.

Notable CWEs mapped to Insecure Design include CWE-209 (Generation of Error Message Containing Sensitive Information), CWE-256 (Unprotected Storage of Credentials), CWE-501 (Trust Boundary Violation), and CWE-522 (Insufficiently Protected Credentials).37

Red Team Insights: Detection and Exploitation

Detecting insecure design vulnerabilities requires a shift in focus from pure code-level bugs to architectural and logical weaknesses:

Threat Modeling from an Attacker’s Perspective: Analyzing the application’s design by asking “What could go wrong?” and considering how different features might be abused individually or chained together for malicious purposes.39
Business Logic Analysis: Scrutinizing application workflows, especially those involving financial transactions, user management, or access to sensitive resources, for potential abuse cases (e.g., refund systems, reward programs, booking processes).39
Identifying Missing Controls: Looking for the absence of fundamental security controls such as rate limiting on sensitive functions, restrictions on file types or sizes for uploads, lack of audit trails for critical operations, or weak credential recovery mechanisms.11
Reviewing Credential Recovery Workflows: Assessing the security of processes like “forgot password,” looking for weaknesses such as easily guessable security questions.11

Exploitation techniques often involve abusing intended functionality in unintended ways:

Business Logic Abuse:
- A rewards system that allows users to refer friends for credit might be exploited if it doesn’t validate who gets referred, enabling an attacker to script self-referrals with fake accounts.39
- A system allowing users to request a refund without verifying if the original payment was completed or if goods were already shipped can be abused.39
- A cinema chain’s booking system without deposit requirements for large groups could be exploited to reserve all seats, causing financial loss.11
Unrestricted File Upload: If an application allows file uploads without properly validating file types or sizes, an attacker might upload a malicious script (e.g., a PHP shell) disguised as an innocuous file type (e.g., a PDF), potentially leading to remote code execution.39
Lack of Rate Limiting: Brute-forcing login forms, API endpoints, or password reset functionalities if there are no limits on the number of attempts.38 For example, WordPress admin panels often lack login attempt limits by default, making them susceptible.38
Exploiting Flawed Credential Recovery: Using easily guessable or publicly available answers to “security questions” to reset passwords and take over accounts.11
Automated Attacks/Bot Abuse: Scalpers using bots to purchase limited-stock items on e-commerce sites that lack anti-bot measures.11
Error Message Reconnaissance: If error messages are overly verbose (e.g., displaying stack traces or SQL queries), they can reveal sensitive information about the system’s internal workings, install paths, or database structure, aiding further attacks.42
Credential Theft via Insecure Design: Storing passwords in plaintext or transmitting them over HTTP for login pages are design flaws that directly lead to credential compromise.42
Case Study: Mirai Botnet: This infamous IoT botnet exploited a critical insecure design choice: IoT devices were shipped with default, publicly known credentials that users rarely changed. This allowed the botnet to infect hundreds of thousands of devices.42

Blue Team Countermeasures: Detection and Mitigation

Detecting insecure design flaws involves proactive analysis during the development lifecycle:

Plausibility Checks: Conduct checks at each tier of the application (frontend to backend) to ensure logical consistency and adherence to security principles.11
Testing Against Threat Models: Develop unit and integration tests specifically designed to validate that all critical flows are resistant to the threats identified during threat modeling. Compile use-cases and, importantly, misuse-cases for each application tier.11

Mitigation strategies for insecure design are fundamentally about building security in from the start 11:

Secure Development Lifecycle (SDLC) Integration: Establish and utilize a secure SDLC where AppSec professionals are involved from the initial stages to help evaluate and design security and privacy-related controls.11
Threat Modeling: Conduct thorough threat modeling for critical application components, including authentication mechanisms, access control logic, business logic workflows, and key data flows. This should be an early and ongoing activity.11 Frameworks like STRIDE can be used to guide this process.39
Secure Design Patterns and Principles: Develop and use a library of secure design patterns or “paved road” ready-to-use components. Consistently apply fundamental security principles such as least privilege, defense in depth, robust input validation, and output encoding everywhere, not just in obvious input fields.11
Integrate Security into User Stories: Explicitly include security language, concerns, and required controls in all user stories and development tasks.11
Design for Abuse Cases: Actively consider how features could be misused or abused by malicious actors, not just how they will be used legitimately (the “happy path”).39
Incorporate Security into UX Design: Do not sacrifice security for convenience where critical operations are concerned. Implement appropriate friction, such as email confirmations for sensitive changes, CAPTCHAs or throttling on login/reset forms, strong password requirements, and mandatory two-factor authentication (2FA).39
Log and Monitor Security-Sensitive Events: Design logging and audit trails into the architecture from the beginning for administrative actions, authentication events, significant data changes, and access control decisions.39
Tier and Tenant Segregation: Ensure robust segregation of tier layers (e.g., presentation, application, data) and, if applicable, tenants, at both system and network levels, based on exposure and protection needs.11
Limit Resource Consumption: Design mechanisms to limit resource consumption by user or service to prevent denial of service or resource exhaustion attacks.11
Secure Credential Recovery: Replace inherently weak credential recovery mechanisms like “questions and answers” with more secure, multi-step verification processes.11
Anti-Bot Design: Implement design features and logic rules to identify and mitigate automated abuse by bots, such as for scalping or brute-force attacks.11

The introduction of “Insecure Design” as a distinct category in the OWASP Top 10 2021 signals a significant paradigm shift towards proactive, “security by design” thinking. OWASP’s documentation explicitly states that this category calls for more “pre-code activities” and aims to move security considerations “beyond ‘shift-left’ in the coding space” to even earlier stages of development.11 The critical distinction made between design flaws and implementation defects—highlighting that an insecure design “cannot be fixed by a perfect implementation” because the necessary controls were never conceived 11—underscores this shift. Consequently, the recommended mitigation strategies heavily emphasize early-lifecycle activities such as conducting threat modeling during the design phase, utilizing secure design patterns, and embedding security requirements directly into user stories.11 This focus on foundational architectural security, rather than solely on code-level bugs, reflects a maturing understanding within the industry: many vulnerabilities originate from flawed blueprints rather than just errors in construction. For defensive teams, the message is clear: attempting to bolt on security measures late in the development cycle is insufficient and often ineffective. Security must be an intrinsic part of the application’s fabric, woven in from its very conception. For offensive teams, this implies that a deep understanding of an application’s architecture and business logic can reveal vulnerabilities that automated code scanning tools might overlook. Exploiting insecure design often involves creatively abusing intended functionalities in ways the designers did not anticipate.

3.5 A05:2021 – Security Misconfiguration

Understanding Security Misconfiguration

Security Misconfiguration, ranked #5 in the OWASP Top 10 2021, arises when security settings are definable but are not set to optimal values, or when security features are not configured correctly. This often results from using insecure default configurations, having incomplete or ad-hoc configurations, or improperly setting permissions on systems and cloud services.2 This category moved up from #6 in the 2017 list, and data showed that 90% of applications tested had some form of misconfiguration.8 The scope of this category was also broadened in 2021 to include the former A4:2017-XML External Entities (XXE) vulnerability, as XXE often results from a misconfigured XML parser.8

The impact of security misconfigurations can be severe, leading to unauthorized access, exposure of sensitive data, system compromise, or denial of service.7 Common examples include 2:

Unnecessary features, services, ports, pages, or accounts being enabled or installed.
Default accounts and their passwords (e.g., “admin:admin”) remaining unchanged.
Overly informative error messages, such as stack traces, being returned to users, revealing sensitive internal information.
Security hardening measures missing across any part of the application stack (servers, frameworks, databases).
Improperly configured permissions on cloud services, such as Amazon S3 buckets being left publicly accessible.
Outdated software or unpatched systems (which has an overlap with A06: Vulnerable and Outdated Components).
Directory listing being enabled on the web server, allowing attackers to browse file structures.
Missing standard security headers (e.g., X-Frame-Options, Content-Security-Policy).
XML parsers configured to process external entities, making them vulnerable to XXE attacks.

Red Team Insights: Detection and Exploitation

Detecting security misconfigurations involves actively probing for common weaknesses:

Scanning and Enumeration: Scanning for open ports, default credentials, and unnecessary services running on servers.44
Directory Listing Checks: Attempting to access directories directly to see if listing is enabled.44
Error Message Analysis: Intentionally triggering errors to examine the verbosity of messages and check for leaked information like stack traces or component versions.44
Cloud Configuration Review: Assessing permissions on cloud storage (e.g., S3 buckets) and other cloud services for public exposure or overly permissive settings.44
XXE Testing: Crafting and submitting malicious XML input containing references to external entities to test if the XML parser processes them. This can involve trying to read local files (e.g., /etc/passwd) or make outbound network connections from the server.49

Exploitation techniques capitalize on these misconfigurations:

Default Credentials: Gaining administrative or privileged access to systems or applications by using well-known default usernames and passwords.44
Directory Listing Exploitation: Discovering sensitive files, configuration files, or compiled application code that can be downloaded and reverse-engineered to find further vulnerabilities.44
Verbose Error Exploitation: Gathering detailed information about server software versions, underlying application flaws, or sensitive data paths from error messages to aid in further attacks.44
Exposed Cloud Storage Access: Directly accessing and exfiltrating sensitive data from publicly readable cloud storage buckets or other misconfigured cloud resources.44
XXE Attacks: Forcing a vulnerable XML parser to access internal system files, perform network reconnaissance within the internal network, or exfiltrate data by making the server include external entities in its XML processing.49 An example is crafting an XML payload to retrieve the contents of /etc/passwd from the server.

Real-world incidents highlight the impact of misconfigurations, especially in cloud environments:

Accenture (2017): Accidentally exposed internal cloud databases containing sensitive client information, including passwords, due to weak security configurations on AWS S3 buckets.50
General AWS S3 Breaches (2017 onwards): Numerous incidents where companies mistakenly left AWS S3 buckets publicly accessible, exposing vast amounts of customer data, internal documents, and private communications.50
Capital One (2019): A misconfigured web application firewall (WAF) in their AWS cloud environment was a key factor in a breach that allowed an attacker to access data of over 100 million customers.50
Microsoft Power Apps (2021): Default OData API settings in Power Apps portals led to the public exposure of 38 million records from various organizations because data was made public by default unless explicitly restricted.51

Blue Team Countermeasures: Detection and Mitigation

Detecting misconfigurations relies on continuous verification and auditing:

Automated Configuration Verification: Implement automated processes and tools to verify secure configurations and detect misconfigurations across all environments (development, QA, production).16
WAF Monitoring: Utilize Web Application Firewalls in monitoring mode to detect attempts to exploit misconfigurations like XXE before switching to blocking mode.49

Mitigation strategies focus on establishing and maintaining secure configurations 15:

Repeatable Hardening Process: Implement a consistent, documented, and preferably automated hardening process for all systems and applications. Development, QA, and production environments should be configured identically, using different credentials for each environment.36
Minimal Platform Deployment: Deploy applications with a minimal setup. Remove or disable all unused features, services, components, ports, accounts, sample files, and documentation.16
Regular Configuration Review and Patch Management: Continuously review and update configurations in line with security advisories, updates, and patches. This includes regularly reviewing cloud storage permissions (e.g., S3 bucket policies) and adhering to cloud security best practices.16
Change Default Credentials: Immediately change all default usernames and passwords upon deployment of any software or system.7
Secure Error Handling: Configure servers and applications to not return detailed error messages, such as stack traces, directly to users.44
Architectural Segmentation: Employ network segmentation, containerization, or cloud security groups (ACLs) to effectively isolate application components and tenants, limiting the blast radius of a compromise.36
Enforce Security Headers: Configure web servers to send appropriate HTTP security headers (e.g., Content Security Policy, HTTP Strict Transport Security, X-Frame-Options) to clients to protect against various attacks.7
Automated Configuration Validation Tools: Use automated tools to regularly scan and verify that configurations meet defined security standards across all environments, ensuring settings are effective and consistently applied.16
XXE Prevention: For XML parsers, ensure that processing of external entities and DTDs (Document Type Definitions) is disabled by default, or configure parsers securely if such functionality is absolutely required.
Software Update Management: Implement processes for managing software updates effectively, both on-premises and in cloud environments.52
System Hardening via Policies: Utilize mechanisms like Group Policy (in Windows environments) or similar configuration management systems to enforce hardened security settings for users and computers.52

Security misconfigurations are often described as “low-hanging fruit” for attackers. This is because many such vulnerabilities stem from simple oversights like unchanged default credentials 44 or unnecessary features left enabled.44 The increasing complexity of modern application stacks—involving cloud services, containers, and microservices—makes comprehensive and consistently correct configuration a significant challenge.44 Attackers often do not need sophisticated techniques to exploit these issues; gaining access via default credentials or finding publicly open S3 buckets are common examples.44 The high prevalence of misconfigurations, with 90% of tested applications showing some form 44, reinforces the idea that these are widespread and common issues. This situation highlights the critical need for diligent configuration management and systematic hardening processes. Defensive teams must prioritize establishing secure baselines, automating configuration checks, and performing regular audits, especially within intricate cloud environments. For offensive teams, checking for common misconfigurations should be a standard part of any assessment, as they frequently provide an easy initial foothold or valuable information disclosure. The inclusion of XXE under this category also broadens its scope, underscoring that misconfigured parsers are a significant security concern.

3.6 A06:2021 – Vulnerable and Outdated Components

Understanding Vulnerable and Outdated Components

This category, ranked #6 in 2021 (up from #9 in 2017), addresses the risks associated with using software components—such as libraries, frameworks, and other modules—that are unsupported, out of date, or known to contain security vulnerabilities.2 This risk applies to both client-side and server-side components, including their direct and transitive (nested) dependencies.17 Organizations often struggle to effectively test for and assess the risks posed by these components.8

The impact of exploiting a vulnerable component can range from data loss and server takeover to other severe outcomes, depending on the nature of the vulnerability within the component. Essentially, a vulnerable component can act as a backdoor into the application or system.54

Common issues contributing to this risk include 54:

Lack of awareness of all component versions used within an application, especially nested dependencies.
Using software (including operating systems, web/application servers, database management systems, and libraries) that is known to be vulnerable, is no longer supported by the vendor, or is simply out of date.
Failure to regularly scan for vulnerabilities in used components or subscribe to security bulletins relevant to those components.
Delays in applying patches or upgrading underlying platforms, frameworks, and dependencies, often due to infrequent patching schedules or concerns about compatibility issues.
Not adequately securing the configurations of the components themselves.

Red Team Insights: Detection and Exploitation

Detecting vulnerable and outdated components involves several steps:

Component Identification and Version Fingerprinting: Identifying the components and their versions used by an application through various means, such as examining HTTP headers, analyzing client-side JavaScript, inspecting source code if available, or interpreting error messages.54
CVE Scanning: Cross-referencing identified component versions against databases of known Common Vulnerabilities and Exposures (CVEs).54
Software Composition Analysis (SCA) Tools: Using SCA tools to identify components and their known vulnerabilities. However, these tools primarily perform static analysis.54
Dynamic Application Security Testing (DAST): DAST tools can be more effective in identifying which vulnerable components are actually running and whether their vulnerabilities are exploitable in the live application environment.54

Exploitation techniques target the known weaknesses in these components:

Exploiting Known CVEs: Attackers actively scan for and exploit publicly known vulnerabilities in popular libraries and frameworks.54
Automated Attacks: Using automated tools and bots that are programmed to target specific vulnerable components.54
Specific Vulnerability Exploitation:
- Remote Code Execution (RCE) in frameworks like Apache Struts 54 or logging libraries like Log4j (the Log4Shell vulnerability).54
- Cross-Site Scripting (XSS) flaws in outdated client-side libraries like jQuery.54
- Exploiting insecure design patterns in legacy plugins for CMS platforms like WordPress or Drupal.54
Supply Chain Attacks: Compromising a third-party vendor or a seemingly benign software dependency. A notable example is the Polyfill.io incident, where a legitimate JavaScript library was compromised to serve malicious code to thousands of websites that included it.55

Real-world examples demonstrate the severe consequences:

Apache Struts (Equifax Breach, 2017): An unpatched RCE vulnerability in the Apache Struts framework was exploited, leading to one of the largest data breaches in history.54
Log4j (Log4Shell, 2021): A critical RCE vulnerability in the widely used Log4j Java logging library affected a vast number of applications and systems worldwide, allowing attackers to execute arbitrary code.54
Outdated jQuery Libraries: These are frequently found with known XSS vulnerabilities that can be exploited if not updated.54

Blue Team Countermeasures: Detection and Mitigation

Detecting vulnerable components requires continuous vigilance:

Continuous Inventory Management: Maintain an accurate and up-to-date inventory of all software components, their versions (both client-side and server-side), and all their dependencies. Tools like OWASP Dependency Check, retire.js, or commercial SCA solutions can automate this process.16
Automated Vulnerability Scanning and Monitoring: Continuously scan all components and their dependencies for known vulnerabilities. Monitor sources like the CVE database and the National Vulnerability Database (NVD), and subscribe to security alerts relevant to the components in use.16

Effective mitigation strategies include 16:

Robust Patch Management Process: Establish and adhere to a formal process to promptly identify, assess, and apply patches or upgrades for vulnerable components. This process should also include removing unused dependencies, features, components, files, and documentation to reduce the attack surface.36
Use Secure and Official Sources: Obtain all software components exclusively from official and trusted sources, preferably over secure (HTTPS) links. Whenever possible, use signed packages to verify their integrity and ensure they have not been tampered with.16
Monitor for Unmaintained or End-of-Life Components: Regularly evaluate libraries and components for active maintenance and availability of security patches. If a component is no longer maintained or patches are not available, consider replacing it. If immediate replacement is not feasible, explore virtual patching using Web Application Firewalls (WAFs) or other compensating controls to monitor, detect, or protect against known exploits.16
Compatibility Testing: Thoroughly test updated, upgraded, or patched libraries to ensure they are compatible with the existing application and do not introduce functional regressions.56
Secure Component Configurations: Harden the configurations of all third-party components according to security best practices, rather than relying on default settings.56
Software Bill of Materials (SBOMs): Generate and maintain SBOMs for applications. Tools like Veracode Software Composition Analysis can produce SBOMs in standardized formats (e.g., CycloneDX, SPDX), providing clear visibility into the component landscape and associated vulnerabilities.57
Automate Updates: Where practical, use dependency management tools and CI/CD pipelines to automate the process of checking for and applying updates and security patches for components.54

The challenge posed by vulnerable and outdated components is increasingly shifting towards the complexities of software supply chain security and the inherent difficulty in achieving comprehensive visibility into all software dependencies. Modern applications are not monolithic; they are assembled from a multitude of third-party and open-source components.54 The risk extends beyond known vulnerabilities in direct dependencies to those hidden within transitive (nested) dependencies 17, and even to the integrity of the components themselves, as highlighted by supply chain attacks like the Polyfill.io incident.55 OWASP documentation itself notes the struggle organizations face to adequately “test and assess risk” and the difficulty of “maintaining a full component inventory”.8 This reality necessitates the adoption of tools like Software Composition Analysis (SCA) and the generation of Software Bills of Materials (SBOMs) to gain a clearer understanding of “what’s in your stack”.54 For defensive teams, this means that security efforts must extend beyond simple patching of direct dependencies. They need robust SCA programs, SBOM generation and management, and stringent processes to vet the sources and integrity of all components. The old “trust-based assumptions” 55 about the security of third-party software components are no longer tenable. For offensive teams, this opens up avenues to explore supply chain attack vectors or exploit vulnerabilities in less obvious, deeply nested dependencies. The sheer volume and complexity of components in modern applications make manual tracking practically impossible, underscoring the critical need for automated solutions and a more holistic view of software security.

3.7 A07:2021 – Identification and Authentication Failures

Understanding Identification and Authentication Failures

Ranked #7 in 2021, Identification and Authentication Failures encompass weaknesses in how an application confirms a user’s identity (identification), verifies that identity (authentication), and manages user sessions securely.2 This category was previously known as “Broken Authentication” (A02 in 2017) and has been broadened to include CWEs more specifically related to failures in the identification process itself.8

The impact of these failures can be severe, potentially leading to unauthorized access to user accounts, account takeover, privilege escalation, and session hijacking, ultimately compromising sensitive data and application functionality.16

Common weaknesses that fall under this category include 59:

Permitting automated attacks such as credential stuffing (where attackers use lists of stolen credentials) and brute-force attacks (systematically trying password combinations).
Allowing the use of default, weak, or commonly known passwords (e.g., “password123”, “admin”).
Implementing weak or ineffective credential recovery processes, such as relying on easily guessable “knowledge-based answers” (security questions).
Storing passwords in plain text, encrypting them with reversible encryption, or using weak, unsalted hashing algorithms.
Missing or ineffectively implemented Multi-Factor Authentication (MFA).
Exposing session identifiers in URLs, making them susceptible to capture.
Reusing session identifiers after a successful login, which can lead to session fixation attacks.
Not properly invalidating session identifiers upon user logout, after a period of inactivity (idle timeout), or after an absolute session duration (absolute timeout).
Providing verbose error messages during login attempts (e.g., distinguishing between “Invalid password” and “User not found”) that can help attackers enumerate valid usernames.61

Red Team Insights: Detection and Exploitation

Detecting identification and authentication failures involves testing various aspects of the login, session management, and recovery mechanisms:

Automated Attack Testing: Attempting credential stuffing and brute-force attacks using automated scripts (e.g., developed with Selenium) and lists of common or breached credentials to see if the application lacks rate limiting or account lockout mechanisms.59
Password Policy Assessment: Checking if the application enforces strong password policies (length, complexity, uniqueness).
Credential Recovery Probing: Testing the security of password reset and account recovery functions for logical flaws or guessable elements.
Password Storage Analysis: If a data breach occurs or if there’s an information leak, analyzing how passwords were stored (though this is often post-exploitation).
MFA Bypass/Weakness Testing: Evaluating the MFA implementation for bypass vulnerabilities or weaknesses in recovery options.
Session Management Analysis: Looking for session identifiers exposed in URLs, testing if session tokens are predictable or if they are not regenerated after login (session fixation). Observing session behavior after logout or timeouts to ensure invalidation.59

Exploitation techniques include:

Credential Stuffing: Systematically trying username/password combinations obtained from previous data breaches against the target application’s login interface, often using automated tools. This is highly effective due to widespread password reuse.59
Brute-Force Attacks: If login attempt rate limiting is absent or weak, attackers can try numerous password combinations for a known username.59
Session Fixation/Hijacking: An attacker can fixate a user’s session ID by providing it to them before they log in, or hijack an existing session by stealing a valid session token (e.g., if exposed in a URL or through XSS).59 A session fixation example involves an attacker logging in to get a valid session ID, then tricking the victim into logging in using that same session ID. If the application doesn’t regenerate the session ID upon the victim’s successful authentication, the attacker shares the session.64
Exploiting Weak Password Reset Mechanisms: Guessing answers to security questions, exploiting flaws in the token generation or validation logic for password reset links, or reusing old reset links.61
JWT Abuse: Manipulating improperly signed or weakly protected JSON Web Tokens (JWTs), such as by changing the algorithm to none or exploiting weak signature keys.61
Exploiting Business Logic Flaws in Authentication: Abusing workflows that allow password resets or email address changes without requiring re-authentication, or permit users to remain logged in even after a password change.61

Real-world examples and case studies demonstrate the impact:

Ubiquiti (2022): A breach occurred via a third-party cloud provider, leading to the theft of credentials that were subsequently used in credential stuffing attacks against Ubiquiti users.64
Microsoft Exchange Server (Play Ransomware, 2021): Attackers exploited CVE-2022-41082, which involved authentication bypass aspects, to gain unauthorized access to Outlook Web App (OWA) and achieve remote code execution.63
UnitedHealth Group (2024): A ransomware attack compromised data of over 100 million individuals. Attackers used stolen credentials to access a Citrix portal that lacked multi-factor authentication.65
Okta Customer Support System Breach (2023): An attacker gained access by compromising an Okta employee’s account through credentials stored insecurely in the employee’s personal Google account. This allowed the attacker to access files within Okta’s customer support system.65
Norton LifeLock Credential Stuffing Attack (2022): Approximately 925,000 customer accounts were affected by a credential stuffing attack, exploiting password reuse. Personal details and potentially Norton Password Manager vaults were exposed.65
LinkedIn API Breach (2021): A publicly accessible API endpoint that lacked authentication allowed attackers to scrape the personal records of over 700 million users.65

Blue Team Countermeasures: Detection and Mitigation

Detecting attacks related to identification and authentication failures involves active monitoring:

Failed Login Attempt Monitoring: Continuously monitor for high rates of failed login attempts, which can indicate brute-force or credential stuffing attacks. Implement limits and escalating delays for repeated failures from the same IP or for the same account.16
Alerting: Log all authentication failures and configure alerts for administrators when credential stuffing, brute-force, or other suspicious authentication patterns are detected.59
Bot Defense Mechanisms: Employ bot detection and mitigation services to identify and block automated credential stuffing attempts.62

Mitigation strategies are crucial for robust protection 15:

Multi-Factor Authentication (MFA): Implement MFA wherever possible, especially for sensitive accounts and functions. Prefer app-based Time-based One-Time Password (TOTP) authenticators over SMS-based MFA due to SMS vulnerabilities. Ensure MFA recovery flows are also secure.16
Strong Password Policies: Enforce strong password requirements, including minimum length (e.g., 12+ characters), complexity (mix of character types), and checks against lists of known breached or common passwords (e.g., using services like HaveIBeenPwned). Align policies with NIST 800-63B guidelines regarding memorized secrets, which often discourage mandatory frequent password rotation if other controls like MFA are in place.16
Eliminate Default Credentials: Never ship or deploy applications with default credentials, particularly for administrative users.16
Rate Limiting and Account Lockout: Implement strict rate limiting on login attempts and other authentication-related endpoints. Temporarily lock accounts after a certain number of consecutive failed attempts. Use CAPTCHAs on public-facing forms to deter bots.15
Secure Session Management:
- Use a server-side, secure session management mechanism.
- Generate new, random, high-entropy session identifiers after a successful login to prevent session fixation.
- Do not expose session identifiers in URLs.
- Store session tokens securely, using cookie flags like HttpOnly (prevents JavaScript access), Secure (ensures transmission only over HTTPS), and SameSite (mitigates CSRF).
- Properly invalidate session identifiers on the server-side upon user logout, after a reasonable period of inactivity (idle timeout), and after an absolute session duration (absolute timeout).16
Harden Credential Recovery Processes: Avoid easily guessable knowledge-based answers for account recovery. Implement secure, multi-step recovery processes. Use consistent, generic messages for all outcomes (success or failure) during registration and credential recovery attempts to prevent attackers from enumerating valid usernames.59
Use Hardened Identity Providers: Whenever feasible, leverage established and hardened identity providers (e.g., Auth0, Okta, Azure AD B2C, Firebase Authentication) rather than building custom authentication logic. If custom implementation is necessary, meticulously follow OWASP’s Authentication Cheat Sheet and other best practices.61
Secure Password Storage: Store passwords using strong, adaptive, and salted hashing algorithms (as detailed under A02: Cryptographic Failures).59
Generic Error Messages: During login, provide generic error messages like “Invalid username or password” rather than messages that confirm whether a username exists (e.g., “Invalid password” for a valid user, or “User not found” for an invalid user) to prevent username enumeration.64

The increasing exploitation of authentication failures at scale, primarily through automated methods like credential stuffing 59, highlights a critical vulnerability vector. Credential stuffing attacks leverage the common user behavior of password reuse across multiple online services, combined with readily available lists of credentials leaked from previous data breaches.61 Incidents like the Norton LifeLock breach 65 and other general credential stuffing examples 62 demonstrate the widespread success of these large-scale automated attacks. The frequent recommendation of defenses against such automation—like rate limiting, CAPTCHAs, and especially MFA 15—underscores this trend. This implies that robust authentication security is no longer just about the strength of individual passwords; it’s critically about defending against widespread, automated abuse facilitated by human tendencies in password management. Defensive teams must prioritize technical controls that specifically counter automation (e.g., rate limits, bot detection services) and strongly advocate for and enforce MFA adoption. For offensive teams, leveraging automation and publicly available breach data to simulate these common attack scenarios can be highly effective in demonstrating real-world risk. The “human factor” of password reuse remains a key enabler for these types of attacks.

3.8 A08:2021 – Software and Data Integrity Failures

Understanding Software and Data Integrity Failures

Software and Data Integrity Failures, a new category in the 2021 OWASP Top 10 (ranked #8), addresses vulnerabilities related to the lack of verification for the integrity of software updates, critical data, and Continuous Integration/Continuous Deployment (CI/CD) pipelines.8 This category emphasizes the risks of trusting software components, data sources, or update processes without adequate mechanisms to ensure they have not been tampered with or maliciously altered.67 It notably incorporates the risks previously covered by A8:2017-Insecure Deserialization.8

The impact of these failures can be profound, potentially leading to the execution of malicious code, full system compromise, unauthorized modification of critical data or configurations, and devastating supply chain attacks.67

Common causes and manifestations include 67:

Unsigned or Unverified Software Updates, Plugins, or Dependencies: Applications consuming updates or external components without verifying their digital signatures or checksums.
Lack of Integrity Checks in CI/CD Pipelines: Build and deployment pipelines that do not validate the integrity of code, artifacts, or configurations at various stages, allowing malicious changes to be injected into production.
Insecure Deserialization of Untrusted Data: Applications deserializing data from untrusted sources without proper validation, which can lead to object injection and remote code execution if the serialized data is crafted maliciously.
Absence of Data Authenticity Verification: Systems accepting and processing input from external or untrusted sources without verifying its origin and integrity.
Code Download Without Integrity Verification: Fetching external code or dependencies (e.g., from CDNs or package repositories) without checking their authenticity or integrity.
Compromise of Build Systems or Dependencies: Attackers targeting build tools, repositories, or dependencies through techniques like dependency confusion or typosquatting.

Red Team Insights: Detection and Exploitation

Detecting software and data integrity failures often requires looking beyond the application’s runtime behavior to its development and deployment ecosystem:

Update Mechanism Analysis: Examining how software updates are delivered and applied, specifically looking for the absence of digital signature verification or integrity checks.67
CI/CD Pipeline Review: If possible, assessing CI/CD pipeline configurations for weaknesses, misconfigurations, or points where malicious code or artifacts could be injected without detection.67
Insecure Deserialization Testing: Actively probing applications that handle serialized objects by providing crafted, malicious serialized data to test for vulnerabilities. This often requires understanding the specific serialization format used (e.g., Java serialization, PHP serialization, Python pickle).67
Dependency Analysis: Identifying dependencies pulled from untrusted or public repositories that could be susceptible to typosquatting, dependency confusion, or contain known vulnerabilities that facilitate integrity violations.69
DAST for Runtime Effects: Dynamic Application Security Testing can help identify the runtime consequences of integrity failures, such as the execution of tampered scripts or the successful exploitation of an insecure deserialization vulnerability.67

Exploitation techniques are diverse and can be highly impactful:

Supply Chain Attacks:
- Injecting Malicious Code into Software Updates: Attackers compromise a vendor’s build or distribution system to inject malware into legitimate software updates, which are then distributed to unsuspecting users (e.g., the SolarWinds attack).67
- Compromising Third-Party Vendors or Open-Source Libraries: Gaining control of a widely used library or a vendor’s component to distribute malicious code to all downstream users.70
- Dependency Confusion: An attacker identifies internal package names used by an organization and uploads malicious packages with the same names to public repositories (like npm or PyPI). If the organization’s build system prioritizes public packages or lacks proper scoping, it may pull in the malicious version, leading to code execution within the build environment or deployed application.69
- Typosquatting: Similar to dependency confusion, but involves registering package names that are slight misspellings of popular, legitimate packages.
Insecure Deserialization: Crafting a malicious serialized object that, when deserialized by a vulnerable application, triggers arbitrary code execution on the server. This can occur even if the application’s core logic does not directly interact with the malicious object’s payload; the deserialization process itself can be the trigger.67
Compromising CI/CD Pipelines: Attackers can target CI/CD servers (e.g., Jenkins, TeamCity, GitHub Actions) to inject malicious code into build artifacts, steal credentials stored in the pipeline, or manipulate deployment scripts to install backdoors in production environments.67
Tampering with Data in Transit or At Rest: If data integrity is not cryptographically verified, attackers who gain access to data flows or storage can modify critical information without detection.67
Injecting Malicious Plugins or Dependencies: For example, injecting JavaScript-based cryptocurrency miners into websites via compromised npm packages or CDN-hosted scripts.67

Real-world examples illustrate the severity of these failures:

SolarWinds Orion Attack (2020): Sophisticated attackers compromised the SolarWinds software build process to inject a malicious backdoor (SUNBURST) into updates for its Orion network monitoring platform. This trojanized update was then digitally signed and distributed to thousands of SolarWinds customers, including government agencies and major corporations, leading to widespread espionage.67
CodeCov Breach (2021): Attackers compromised CodeCov’s CI/CD environment, allowing them to modify a legitimate script used by CodeCov customers. This modified script could exfiltrate sensitive information (like credentials) from the customers’ CI environments.69
Dependency Confusion Attacks (2021): A security researcher demonstrated widespread susceptibility to dependency confusion attacks by successfully uploading malicious packages to public repositories that were then pulled by internal build systems of major companies.69
Hypothetical Open-Source Package Attack 70: An attacker gains control of a poorly maintained but widely used open-source library, injects malicious code (e.g., to steal SSH keys), publishes an update, and infects users who update the package.

Blue Team Countermeasures: Detection and Mitigation

Detecting software and data integrity failures requires monitoring and verification throughout the software lifecycle:

Supply Chain Security Tools: Utilize tools like OWASP Dependency Check or OWASP CycloneDX (an SBOM standard) to verify that components do not contain known vulnerabilities and to maintain an inventory of dependencies.68
CI/CD Pipeline Monitoring: Actively monitor CI/CD pipeline activities for anomalous behavior, unauthorized changes, or unexpected artifacts.
DAST for Runtime Verification: DAST can help detect if tampered scripts are executing in the live environment or if insecure deserialization vulnerabilities are exploitable by observing application behavior.67

Mitigation strategies focus on establishing trust and verifying integrity at every step 16:

Verify Software and Data Integrity: Use digital signatures, cryptographic checksums (hashes), or similar mechanisms to verify that all software (including updates, libraries, and executables) and critical data originate from a trusted source and have not been altered during transit or at rest.67
Secure CI/CD Pipelines:
- Strictly control access to pipeline configurations, secrets, and build/deployment environments.69
- Use ephemeral build runners or isolated build environments where possible.69
- Validate the integrity of all inputs (source code, dependencies), build outputs (artifacts), and deployments.69
- Harden CI/CD tools and platforms, regularly scan for misconfigurations, and apply patches promptly.71
Secure Dependency Management:
- Use trusted and official repositories for all external libraries and dependencies. For organizations with a higher risk profile, consider hosting an internal, vetted repository of approved components.16
- Pin dependencies to exact, known-good versions to prevent unexpected updates from introducing malicious code.69
- Regularly audit all dependencies, including those used only in development or testing environments.69
- Implement controls against dependency confusion, such as properly scoping internal package names or using private registries that take precedence.
Defend Against Insecure Deserialization:
- Avoid deserializing untrusted data whenever possible. If deserialization is necessary, do not process data from untrusted sources or use formats that are known to be vulnerable to object injection attacks.16
- Prefer safer data formats like JSON or Protocol Buffers over complex binary serialization formats if the data source is not fully trusted.69
- If using native serialization formats, implement strict class whitelisting (allow-listing) to permit only expected object types to be deserialized.69
- Ensure that unencrypted or unsigned serialized data is not sent to untrusted clients without robust integrity checks to detect tampering or replay.16
Implement Code and Artifact Integrity Checks:
- Use Subresource Integrity (SRI) for JavaScript files and CSS stylesheets loaded from CDNs or other external sources to ensure they haven’t been modified.69
- Run hash or digital signature checks on all downloaded tools, updates, and dependencies before installation or execution.69
- Require cryptographically signed commits for critical code repositories to ensure code provenance and integrity.69
Protect Stored Data Integrity: Use message authentication codes (MACs) or digital signatures to protect the integrity of critical data stored in databases or files, ensuring that any unauthorized modifications can be detected.72

The emergence of “Software and Data Integrity Failures” as a distinct OWASP Top 10 category highlights a critical expansion of the attack surface beyond the application’s own code. It brings into focus the vulnerabilities inherent in the entire development and deployment ecosystem. This category explicitly encompasses CI/CD pipelines, software update mechanisms, and the vast web of dependencies that modern applications rely on.8 High-profile exploitation examples, such as the SolarWinds attack (which compromised a build system) 67 and the rise of dependency confusion attacks (which exploit package manager behaviors) 69, demonstrate that attackers are increasingly targeting the processes and tools surrounding the application code, not just flaws within it. Consequently, mitigation strategies must also broaden, involving the security of the entire toolchain, rigorous verification of external components, and ensuring the integrity of build and deployment processes from end to end.69 This is a departure from traditional application security vulnerabilities like injection or broken access control, which are primarily concerned with flaws in the application’s own logic. For defensive teams, this means that securing the software supply chain—including development tools, build environments, and dependency sources—is now a critical imperative. Traditional application security testing that focuses solely on the final application artifact might miss these crucial ecosystem vulnerabilities. For offensive teams, this opens up new avenues for attack, as these auxiliary systems and processes are often less hardened than the production application itself and can yield significant impact if compromised.

3.9 A09:2021 – Security Logging and Monitoring Failures

Understanding Security Logging and Monitoring Failures

Ranked #9 in the 2021 OWASP Top 10, Security Logging and Monitoring Failures refer to deficiencies in an organization’s ability to adequately log security-relevant events, monitor these logs effectively, and respond to detected incidents in a timely manner.8 Without sufficient logging and monitoring, breaches can go undetected for extended periods, significantly increasing the potential damage and making it difficult to perform incident investigation, forensic analysis, and determine the root cause of an attack.75 Such failures can also lead to non-compliance with various regulations that mandate logging and monitoring practices (e.g., PCI DSS, HIPAA, GDPR, SOC 2).75 If logs are missing or can be tampered with, attackers can more easily cover their tracks.75

Common failures in this category include 74:

Failure to log critical security events such as logins (successful and failed), high-value transactions, access control failures, and server-side input validation errors.
Warnings and error messages that generate no logs, inadequate logs, or unclear log messages, making it difficult to identify issues.
Application and API logs that are collected but not actively monitored for suspicious activity.
Storing logs only locally, which increases the risk of logs being tampered with or lost if the server itself is compromised.
Inadequate alerting thresholds or poorly defined response escalation processes, leading to alert fatigue or missed critical alerts.
Penetration testing activities or DAST scans that do not trigger any alerts, indicating gaps in detection capabilities.
The inability of the application or system to detect, escalate, or alert for active attacks in real-time or near real-time.
Information leakage in logs that are visible to users or attackers (e.g., logging sensitive data in error messages that are displayed to users).
Lack of log integrity protection, allowing logs to be altered or deleted by attackers.
Inconsistent logging practices across different systems or applications, and insufficient log retention periods for forensic analysis.

Red Team Insights: Detection and Exploitation

From an external Red Team perspective, directly “detecting” logging and monitoring failures can be challenging without post-breach access or insider information. However, inferences can be made:

Probing for Loggable Events: Attackers can perform actions that should trigger logs and alerts (e.g., multiple failed login attempts, attempts to access unauthorized resources, probing with DAST tools) and then try to ascertain if these actions were detected or led to any observable defensive response. A lack of response might suggest monitoring deficiencies.74
Post-Compromise Assessment: If a system is compromised, attackers will assess the extent and quality of logging to understand the organization’s detection capabilities and how much time they might have to operate before being discovered.
Evasion: Attackers specifically benefit from these failures. They don’t “exploit” the lack of logging in the same way they exploit an injection flaw to gain entry. Instead, insufficient logging and monitoring allow attackers to:
- Prolong Dwell Time: Remain undetected within a compromised network or system for much longer periods.75
- Lateral Movement and Privilege Escalation: Move across systems and escalate privileges without triggering alarms if these activities are not logged or monitored.
- Stealthy Data Exfiltration: Exfiltrate sensitive data slowly over time to avoid detection.
- Cover Tracks: Delete or manipulate logs if they are stored insecurely or lack integrity controls, making forensic investigation much harder.75 The absence or inadequacy of logging and monitoring acts as a significant enabler for attackers, allowing them to achieve greater impact from their initial compromise.

A notable, though somewhat indirect, example often cited is the CrowdStrike “glitch” incident (referred to with a future date of July 2024 in some snippets, likely a typo for a past event or a hypothetical illustration).76 In this scenario, a faulty content update from CrowdStrike reportedly caused widespread system crashes. The failure highlighted was twofold: CrowdStrike’s own internal monitoring systems allegedly failed to detect the problematic update before its deployment, and customer organizations often lacked the visibility to identify the root cause of the issue as it unfolded in real-time. This case is presented as a failure in monitoring the security tools themselves and the broader ecosystem, demonstrating how a lack of observability can exacerbate the impact of an incident, even one not directly caused by an external attacker.

Blue Team Countermeasures: Detection and Mitigation

Detecting weaknesses in logging and monitoring involves proactive testing and review:

Log Review and Analysis: Regularly review logs and security event dashboards provided by SIEMs or other monitoring tools to identify suspicious patterns or actual incidents.75
Testing Alerting Mechanisms: Ensure that DAST scans, penetration tests, and simulated attacks do trigger appropriate alerts. This helps verify the effectiveness of monitoring systems and alert configurations.57
SIEM Implementation: Utilize Security Information and Event Management (SIEM) tools to aggregate, correlate, and analyze logs from diverse sources (applications, servers, network devices, security appliances).79

Mitigation of logging and monitoring failures requires a comprehensive strategy 16:

Log All Critical Events: Ensure that all significant security-relevant events are logged. This includes, but is not limited to:
- All login attempts (successful and failed).
- Access control decisions and failures (e.g., attempts to access unauthorized resources).
- Server-side input validation failures.
- High-value transactions and business operations.
- Administrative activities and configuration changes.
- System errors and exceptions. Logs should include sufficient context for forensic analysis, such as timestamps, source IP addresses, user identifiers, requested resources, and outcomes.74
Standardized and Consumable Log Formats: Generate logs in a consistent, well-documented format that can be easily parsed and ingested by centralized log management solutions (e.g., JSON, CEF, LEEF) and SIEM tools like Splunk, QRadar, or the ELK Stack (Elasticsearch, Logstash, Kibana).16
Secure Log Data and Storage:
- Protect log data from unauthorized access, modification, or deletion using strong access controls and integrity mechanisms (e.g., hashing, digital signatures for log files).16
- Encode log data correctly to prevent injection attacks targeting the logging or monitoring systems themselves (e.g., log injection).74
- Implement centralized logging, where logs from all relevant systems are sent to a dedicated, secure log management infrastructure. Ensure off-site backups of logs to protect against loss in case of a primary system compromise.74
- Define and enforce appropriate log retention policies based on regulatory requirements and business needs.
Effective Monitoring and Alerting:
- Establish real-time or near real-time monitoring of logs for suspicious activities, known attack patterns, and anomalies.
- Configure meaningful alerts for critical security events. Tune alerting thresholds carefully to reduce false positives (alert fatigue) and ensure that genuine incidents are promptly escalated to the appropriate personnel.74
Incident Response and Recovery Plan: Develop, document, adopt, and regularly test an incident response and recovery plan (e.g., following guidelines like NIST SP 800-61r2). This plan should detail procedures for handling various types of security incidents, including roles, responsibilities, communication channels, and escalation paths.74
Utilize Security Frameworks and Tools:
- Employ application protection frameworks like the OWASP ModSecurity Core Rule Set (CRS) with a WAF to detect and potentially block common attacks at the network edge.74
- Use log correlation software and SIEM platforms to create custom dashboards, reports, and alerts tailored to the organization’s specific threat landscape and critical assets.74
Maintain Audit Trails: Ensure that comprehensive audit trails are maintained for all high-value transactions and sensitive operations, with strong integrity controls to prevent tampering.74
Regularly Test Monitoring Capabilities: Periodically test the effectiveness of monitoring systems by simulating attacks or using tools like DAST to ensure that such activities are detected and trigger the expected alerts and responses.76

Effective security logging and monitoring extend far beyond the mere collection of event data; they are fundamentally about generating actionable intelligence and ensuring operational readiness for incident response. The category name itself, “Security Logging and Monitoring Failures,” emphasizes that both components are critical. Common pitfalls include collecting vast amounts of log data that are never reviewed 74, setting up inadequate or noisy alerting systems that lead to “alert fatigue” 74, or lacking a well-defined and practiced incident response plan.74 Mitigation efforts, therefore, must focus not only on what to log but also on ensuring that logs are context-rich and parsable for consumption by management solutions 74, that alerting is effective and timely 74, and that all monitoring activities are integrated into comprehensive incident response procedures.74 The primary impact of failures in this area is often an extended breach duration and significantly hampered post-incident investigation 75, which clearly indicates a failure to utilize the collected data effectively. For defensive teams, the goal must be to transform raw log data into actionable security intelligence that enables rapid detection, analysis, and response. For offensive teams, the ability to operate within a target environment without triggering meaningful alerts is a strong indicator of immature logging and monitoring capabilities, which typically allows for increased dwell time and a greater chance of achieving objectives.

3.10 A10:2021 – Server-Side Request Forgery (SSRF)

Understanding Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to induce a server-side application to make HTTP requests to an arbitrary domain or internal resource chosen by the attacker.8 SSRF flaws occur when a web application fetches a remote resource (e.g., based on a user-supplied URL for importing an image, fetching data from an API, or using webhooks) without properly validating the destination URL.82 This vulnerability was newly added to the OWASP Top 10 in 2021, primarily based on the Top 10 community survey, which signaled its rising importance and concern among security professionals, even if its incidence rate in datasets at the time was relatively low.8 The incidence of SSRF is reportedly increasing as modern web applications more frequently incorporate features that require fetching external URLs.82

The impact of SSRF can be severe. Attackers can leverage SSRF to 16:

Scan internal networks accessible from the vulnerable server.
Access internal services, applications, or files that are not directly exposed to the internet, effectively bypassing firewalls, VPNs, or network Access Control Lists (ACLs).
Interact with services running on the loopback interface (localhost or 127.0.0.1) of the vulnerable server.
Exfiltrate sensitive data.
Make requests to other external systems, potentially masking the attacker’s true origin. In worst-case scenarios, SSRF can be chained with other vulnerabilities to achieve full system compromise.83 A key aspect of SSRF is the exploitation of trust relationships, where the application server has permissions to interact with private backend systems or cloud provider metadata services that are not intended for direct user access.84

Red Team Insights: Detection and Exploitation

Detecting SSRF vulnerabilities involves identifying application functionalities that process user-supplied URLs and then testing how the application handles crafted inputs:

Identify URL Input Points: Look for features where the application takes a URL as input, such as image or data import from URL, PDF generation from URL, webhook configurations, file downloaders, or API integrations that fetch external data.82
Test with Internal/Special URLs: Provide URLs that point to:
- Internal IP addresses (e.g., 10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x).
- Loopback addresses (127.0.0.1, localhost).
- Cloud provider metadata services (e.g., 169.254.169.254 for AWS EC2 metadata, Azure Instance Metadata Service, Google Cloud Metadata server).16
- External servers controlled by the attacker to monitor for requests.
Use External Listener Services: Employ tools like Burp Collaborator, interactsh.sh, or custom listener services. If the application makes an HTTP/DNS request to this external service when a crafted URL is supplied, it confirms SSRF.83
Analyze Responses: Examine application responses for error messages, differences in response times, or returned content that indicates successful (or attempted) interaction with the target URL. For example, if trying to access an internal admin panel, the response might be the panel’s login page.88
Bypass Defenses: Attackers often try to bypass weak SSRF defenses by:
- Using URL encoding or case variations in protocols/hostnames.
- Manipulating HTTP headers.
- Employing URL path traversal techniques (e.g., example.com/../../internal-service).
- Using hostnames that resolve to internal IP addresses (requires DNS control or exploiting DNS rebinding vulnerabilities).89
- Leveraging open redirects or redirects on attacker-controlled servers to make the initial request seem legitimate while the server ultimately requests a forbidden resource.89

Exploitation techniques depend on what the vulnerable server can access:

Attacks Against Localhost/Server Itself: Accessing internal services running only on the server’s loopback interface, such as administrative consoles, debugging endpoints, or unauthenticated internal APIs, by supplying URLs like http://localhost/admin_panel or http://127.0.0.1:8080/debug_info.84
Attacks Against Other Backend Systems: Making requests from the vulnerable server to other internal servers or services on the private network that it can reach. This can bypass perimeter firewalls that would block direct external access.84
Accessing Cloud Metadata Services: One of the most impactful SSRF exploits involves querying cloud instance metadata services (e.g., AWS EC2’s http://169.254.169.254/latest/meta-data/) to retrieve sensitive information such as temporary security credentials (IAM roles), instance ID, user data, network configuration, etc. These credentials can then be used to access other cloud resources.16
Internal Network Port Scanning: By systematically trying to connect to various internal IP addresses and ports and observing error messages (e.g., “connection refused,” “timeout”) or response times, an attacker can map out parts of the internal network.
Information Disclosure (File Access): If the application supports and does not properly restrict URL schemes like file:///, an attacker might be able to read arbitrary files from the server’s filesystem (e.g., file:///etc/passwd, file:///c:/windows/win.ini).88
Blind SSRF: In cases where the application does not return the response from the forged request directly to the attacker, it’s considered blind SSRF. Attackers can still infer success based on timing differences in responses, or by triggering out-of-band interactions (e.g., forcing the server to make a DNS lookup or HTTP request to an attacker-controlled server).88
Chaining with Other Vulnerabilities: SSRF can be used as a pivot point. For example, an attacker might use SSRF to reach an internal application that is vulnerable to Remote Code Execution (RCE) or SQL Injection, which would otherwise be inaccessible from the internet.83 The Atlassian Confluence OGNL injection (CVE-2021-26084) is an example where SSRF could be used to trigger the RCE.89

Real-world incidents and research highlight the significance of SSRF:

Capital One Breach (2019): A former Amazon Web Services employee exploited an SSRF vulnerability in a misconfigured web application firewall to gain access to the AWS EC2 metadata service. This allowed the attacker to acquire temporary credentials (IAM role keys) which were then used to exfiltrate data of approximately 106 million Capital One customers and credit card applicants from S3 buckets.83
Microsoft Exchange Server Attacks (Hafnium, 2021): The CVE-2021-26855 vulnerability was an SSRF flaw in Microsoft Exchange Server. Attackers exploited it to authenticate as the Exchange server itself, enabling them to send arbitrary HTTP requests and subsequently chain this with other vulnerabilities to achieve remote code execution and exfiltrate emails.83
Facebook SSRF Research: Facebook acknowledged the importance of SSRF by launching a specific dashboard tool for security researchers to report such vulnerabilities, indicating its prevalence and concern within major tech companies.87
Microsoft Azure Services Vulnerabilities (January 2023): Security researchers discovered unauthenticated SSRF vulnerabilities in some Azure services, which could have allowed attackers to make requests from Azure servers without needing an Azure account.88

Blue Team Countermeasures: Detection and Mitigation

Detecting SSRF attempts often involves monitoring outbound network traffic and WAF logs:

Outbound Traffic Monitoring: Monitor outbound network connections from application servers. Unexpected requests to internal IP addresses, unusual ports, or known malicious external domains can be indicators of SSRF activity.
Web Application Firewall (WAF) Logs: Modern WAFs can be configured with rulesets to detect and potentially block common SSRF patterns and signatures in incoming requests (e.g., URLs containing localhost, internal IP ranges, or metadata service addresses).82

Mitigation strategies are crucial to prevent SSRF and should be implemented robustly 16:

Input Validation and Sanitization (Primary Defense):
- Strictly validate and sanitize all user-supplied input that is used to construct URLs for server-side requests. This includes checking the protocol, hostname, path, and port.16
- Ensure proper URL encoding and decoding is performed to prevent bypasses.88
Allow-lists (Whitelisting) for Destinations:
- This is generally the most effective approach. Maintain an explicit allow-list of permitted, known-good protocols (e.g., HTTP, HTTPS), domain names, IP addresses, and ports that the application legitimately needs to access. Deny all other requests by default.16
- When validating hostnames, ensure that the resolved IP address also matches an allowed IP or range. Be cautious of DNS rebinding attacks where an attacker might control DNS resolution to return a whitelisted IP initially, then an internal IP for the actual request. Resolve the hostname to an IP address once and use that IP for all checks and the connection.89
Network Segmentation and Isolation:
- Isolate functionalities that need to fetch remote resources in a separate, restricted network segment (e.g., a DMZ or a dedicated VPC with strict egress filtering). This limits the potential reach of an SSRF attack even if one occurs.16
- Enforce the principle of least privilege for the server making the requests; it should only have network access to the specific resources it absolutely needs.
Disable Unused URL Schemes: Only allow URL schemes that are explicitly required by the application (typically HTTP and HTTPS). Block potentially dangerous schemes like file:///, gopher:///, dict:///, ftp://, sftp://, etc., as these can be abused to access local files or interact with other unintended services.57
Consistent Server Responses / No Raw Responses: Ensure that the application does not send raw response bodies from the requested remote server directly back to the client. This can prevent leakage of sensitive information from internal services that might not be intended for external viewing.16 Instead, process and sanitize the response before relaying relevant parts to the user.
Authentication for Internal Services: Whenever possible, internal services should require authentication, even if they are on a “trusted” network. This provides defense in depth against SSRF.
Explicitly Disallow HTTP Redirections (or handle securely): If the application follows redirects, ensure that the redirected URL is also validated against the allow-list. Attackers can use redirects to bypass initial URL checks.16
Cloud Security Best Practices for Metadata Services: If running in a cloud environment, configure instance metadata service access with caution. Use IMDSv2 (Instance Metadata Service Version 2) on AWS, which requires a session token and provides protection against some SSRF techniques. Apply similar protections for Azure and GCP metadata services.

The inclusion of Server-Side Request Forgery (SSRF) in the OWASP Top 10 2021, driven significantly by community feedback 8, signals a growing recognition of its potential severity and increasing relevance in modern application architectures. While historical data might have shown lower incidence rates compared to some other perennial vulnerabilities, the potential for SSRF to bypass network perimeters and interact with sensitive internal systems or cloud metadata services makes it a high-impact threat.83 The increasing adoption of microservices, serverless functions, and cloud-native designs, where applications frequently need to make outbound requests to fetch data or interact with other services 82, inherently expands the attack surface for SSRF. This architectural trend means that functionalities relying on user-supplied URLs are becoming more common, and if not secured meticulously, can be exploited. The Capital One breach is a stark reminder of how SSRF can be leveraged to gain access to highly sensitive cloud credentials and data.83 Therefore, defensive teams must treat any feature that makes server-side requests based on user input with extreme caution, implementing robust validation, allow-listing, and network segregation. For offensive teams, SSRF represents a valuable target, as a successful exploit can provide a crucial pivot point into an organization’s internal network or cloud environment, often bypassing traditional firewall protections. The focus on community input for its inclusion suggests that practitioners are encountering and concerned about this vulnerability more frequently than past broad-based data might have indicated.

Section 4: Beyond the Web Application Top 10: Other Key OWASP Resources

While the OWASP Top 10 for Web Applications is its most widely recognized project, OWASP provides a wealth of other resources and specialized Top 10 lists that address security concerns in different technological domains. These resources offer valuable guidance for securing a broader range of applications and systems.

OWASP API Security Top 10: With the proliferation of APIs in modern application architectures, securing them has become critical. OWASP produces a dedicated API Security Top 10 list, first released in 2019 and updated in 2023.2 This list highlights the most dangerous security risks and vulnerabilities specific to Application Programming Interfaces, such as Broken Object Level Authorization (API1:2023), Broken Authentication (API2:2023), and Improper Inventory Management (API9:2023).1 APIs often handle sensitive data and provide direct access to backend systems, making them prime targets.1
OWASP Mobile Top 10: This list focuses on the most critical security risks in mobile applications, addressing vulnerabilities unique to mobile platforms. It covers issues such as insecure data storage, insufficient cryptography, and insecure communication on mobile devices.2 The OWASP Mobile Application Security Project also provides a security standard and a comprehensive testing guide for mobile apps.2
OWASP Top 10 for Large Language Model (LLM) Applications: Recognizing the unique security challenges posed by the rise of Generative AI and Large Language Models, OWASP introduced this specialized list (e.g., LLM01:2025 Prompt Injection, LLM04:2025 Data and Model Poisoning). It aims to highlight critical vulnerabilities specific to LLM applications and guide developers in building more secure AI systems.3
OWASP Kubernetes Top 10: As Kubernetes has become a standard for container orchestration, this list addresses the security challenges associated with its deployment and management. It covers risks such as insecure workload configurations, inadequate logging and monitoring within Kubernetes clusters, and insecure network traffic management.6
OWASP Software Assurance Maturity Model (SAMM): SAMM is an open framework designed to help organizations assess, formulate, and implement a software security strategy that can be integrated into their existing Software Development Lifecycle (SDLC).2 It provides a measurable way to analyze and improve secure development practices across five business functions and 15 security practices, each with defined maturity levels.91 SAMM is technology and process agnostic, supporting various development methodologies from waterfall to agile and DevOps.91 Microsoft’s Security Development Lifecycle (SDL) shares common goals with SAMM, and there’s significant overlap, though SAMM covers broader AppSec program aspects like security champions and decommissioning, while SDL can be more specific on certain technical requirements.93
OWASP Dependency-Track: This is an intelligent component analysis platform that helps organizations identify and reduce risk in their software supply chain. It monitors component usage across all application versions to proactively identify vulnerabilities in third-party and open-source dependencies.2 This tool directly supports addressing risks like A06:2021-Vulnerable and Outdated Components.
OWASP Juice Shop: An intentionally insecure web application designed for security training, awareness demos, Capture The Flag (CTF) competitions, and as a testbed for security tools. It incorporates all vulnerabilities from the OWASP Top 10 and many other common security flaws found in real-world applications, providing a safe environment for learning and practice.2
OWASP ModSecurity Core Rule Set (CRS): This is a set of generic attack detection rules for use with ModSecurity or compatible Web Application Firewalls (WAFs). CRS provides protection against a wide range of attacks, including many covered by the OWASP Top 10.2
OWASP Web Security Testing Guide (WSTG): This is a comprehensive guide to testing the security of web applications and web services. It is a premier cybersecurity testing resource for web application developers and security professionals, providing methodologies and techniques for thorough security assessments.2
OWASP Cheat Sheet Series: This project provides a collection of concise, actionable guidance on specific application security topics, offering developers quick “how-to” guides for preventing common vulnerabilities.4
OWASP Application Security Verification Standard (ASVS): ASVS provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.94

These projects and lists demonstrate OWASP’s commitment to providing comprehensive, community-driven resources to improve software security across various domains and throughout the entire lifecycle of software.

Section 5: Strategic Implementation of the OWASP Top 10

The OWASP Top 10 serves as a foundational document for both offensive (Red Team) and defensive (Blue Team) cybersecurity strategies. Its practical application can significantly enhance an organization’s security posture.

For Red Teams: Guiding Offensive Operations

Red Teams can leverage the OWASP Top 10 as a strategic guide for penetration testing and vulnerability assessments:

Prioritizing Attack Vectors: The Top 10 list, representing the most critical and common web application risks, helps Red Teams prioritize their efforts on vulnerabilities that are most likely to be present and have a significant impact if exploited.3
Developing Test Scenarios: Each category in the Top 10 provides a basis for developing specific test cases and attack scenarios. For example, when assessing for A03:Injection, Red Teams will systematically test input fields for SQL injection, XSS, command injection, etc..29
Tool Selection and Configuration: Many penetration testing tools are designed to detect OWASP Top 10 vulnerabilities. Red Teams can select and configure tools like:
- Web Application Proxies/Scanners: OWASP ZAP (Zed Attack Proxy) and PortSwigger’s Burp Suite are indispensable for intercepting, modifying, and analyzing web traffic, and for scanning for a wide range of vulnerabilities including those in the Top 10.95 OWASP ZAP is an open-source tool specifically built for dynamic testing and excels at detecting Top 10 flaws.97
- Vulnerability Scanners: Tools like Nessus, OpenVAS (Greenbone Vulnerability Management), and Acunetix can identify many Top 10 issues, especially misconfigurations and known vulnerabilities in components.79
- Specialized Tools: Depending on the target, tools for specific injection types (e.g., sqlmap for SQLi), SSRF testing, or API testing (e.g., Akto, APIsec, Escape for GraphQL) can be employed.95
- Exploitation Frameworks: Metasploit can be used if a Top 10 vulnerability leads to an exploitable condition with a public exploit module.96
- Caido: A newer modular proxy tool useful for testing session management, API endpoints, and multi-step login sequences.97
Simulating Real-World Threats: By focusing on the Top 10, Red Teams simulate the tactics used by actual attackers who often target these common weaknesses.
Reporting and Communication: Findings can be framed using the OWASP Top 10 categories, making it easier for development and management teams to understand the risks and prioritize remediation.6

For Blue Teams: Strengthening Defenses and Processes

Blue Teams can integrate the OWASP Top 10 into various aspects of their defensive strategy and the Secure Software Development Lifecycle (SSDLC):

Integrating into the Secure SDLC: The OWASP Top 10 should be a cornerstone of any SSDLC. This involves:
- Requirements Phase: Using the Top 10 to inform security requirements for new applications and features.15 For instance, a requirement could be “The application must prevent all OWASP Top 10 injection vulnerabilities.” The OWASP ASVS can provide a detailed list of verifiable security requirements.94
- Design Phase: Architects and designers should use the Top 10 (especially A04:Insecure Design) to guide secure architectural choices and conduct threat modeling to proactively address potential risks.11
- Implementation Phase: Developers should code with the Top 10 risks in mind, applying secure coding practices to prevent vulnerabilities like injection, cryptographic failures, and broken access control. OWASP Proactive Controls and Cheat Sheets offer specific guidance.15
- Verification Phase: Security testing (SAST, DAST, IAST, manual penetration testing) should explicitly cover all OWASP Top 10 categories.15
- Maintenance Phase: Continuously monitor for new vulnerabilities related to the Top 10 in deployed applications and their components.
Developer Training and Awareness: The Top 10 is an excellent educational tool to raise awareness among developers, QA personnel, and other stakeholders about common web application security risks and how to prevent them.3 OWASP projects like Juice Shop provide hands-on training environments.2
Risk Assessment and Prioritization: Use the Top 10 as a framework for assessing the risk posture of existing applications and prioritizing remediation efforts based on the severity and likelihood of these common vulnerabilities.3
Tool Selection and Configuration: Blue Teams can select and configure various security tools to detect, prevent, and monitor for OWASP Top 10 vulnerabilities:
- Static Application Security Testing (SAST): Tools like Snyk, SonarQube, Checkmarx, and Micro Focus Fortify SCA analyze source code to find vulnerabilities before deployment.96 Veracode SAST can identify flaws leading to injection or access control issues.57
- Dynamic Application Security Testing (DAST): Tools like OWASP ZAP, Micro Focus Fortify WebInspect, Acunetix, Invicti (Netsparker), and Veracode DAST test running applications for vulnerabilities.57 DAST should trigger logging and alerting events if monitoring is effective.57
- Interactive Application Security Testing (IAST): Tools like Contrast Security provide runtime analysis from within the application.95
- Software Composition Analysis (SCA): Tools like OWASP Dependency Check, OWASP Dependency-Track, Snyk, Bytesafe, retire.js, and Veracode SCA help identify and manage vulnerable and outdated components (A06) by scanning dependencies.57
- Web Application Firewalls (WAFs): Solutions like F5 BIG-IP with Advanced WAF, ModSecurity with OWASP CRS, or cloud WAFs can help block attacks targeting many Top 10 vulnerabilities, including injection, XSS (part of A03), and SSRF

To get in touch with me or for general discussion please visit ZeroDayMindset Discussion

Information, Cybersecurity

reading cybersecurity

This post is licensed under CC BY 4.0 by the author.

Navigating the Evolving Threat Landscape: A Deep Dive into the OWASP Top 10

Section 1: Introduction to OWASP and the Top 10

Section 2: The Evolution of the OWASP Top 10 – Understanding the 2021 Landscape

Section 3: The OWASP Top 10 2021 Vulnerabilities: A Deep Dive for Practitioners

3.1 A01:2021 – Broken Access Control

3.2 A02:2021 – Cryptographic Failures

3.3 A03:2021 – Injection

3.4 A04:2021 – Insecure Design

3.5 A05:2021 – Security Misconfiguration

3.6 A06:2021 – Vulnerable and Outdated Components

3.7 A07:2021 – Identification and Authentication Failures

3.8 A08:2021 – Software and Data Integrity Failures

3.9 A09:2021 – Security Logging and Monitoring Failures

3.10 A10:2021 – Server-Side Request Forgery (SSRF)

Section 4: Beyond the Web Application Top 10: Other Key OWASP Resources

Section 5: Strategic Implementation of the OWASP Top 10

Trending Tags