OWASP Top 10 (2021)
Securing the Web, One Risk at a Time

Introduction
OWASP stands for Open Worldwide Application Security Project.
It acts as a global safety club for software where experts from around the world share knowledge to help make websites and apps more secure.
It’s a list of the 10 most common and dangerous mistakes developers could make when building websites or apps and helps teams to spot and fix vulnerabilities.
These mistakes can let hackers steal data, break into systems, or cause major damage.
The list is updated every four years based on real-world attacks and expert feedback.
Why It Matters for Developers, Testers, and Security Teams
Developers use it to avoid writing risky code.
Testers use it to find weak spots before the app goes live.
Security teams use it to fix problems and protect users.
What changed from 2017 to 2021 edition

A01 – Broken Access Control
Occurs when users can access resources or perform actions beyond their intended permissions.
Explanation: It moved from 5th position to the top of the list. In this attack, attackers take the help of session management and try to access data from the unexpired session tokens, which gives them access to many valid IDs and passwords.
Example: A user changes the URL from …/user/123 to …/user/124 and accesses another user's profile
Real Breach: GitHub once had a flaw allowing users to view private repositories by manipulating access token (2012)
Prevention:
Implement role-based access control (RBAC).
Verify user permissions on both client and server sides.
Use secure frameworks to handle access control.
Centralize access control logic.
Log and monitor access control failures.
Apply the principle of least privilege.
A02 – Cryptographic Failures
Occurs when sensitive data (like passwords or credit card information) isn’t properly protected using encryption.
Explanation: Shifts up one position from 3rd to 2nd position in the list. It is previously known as Sensitive Data Exposure. It focus on failures related to cryptography which often leads to sensitive data exposure or system compromise.
Example: An app transmits login credentials over HTTP, exposing them to interception.
Real Breach: Equifax’s breach involved unencrypted sensitive data, contributing to massive exposure (2017).
Prevention:
Use strong, modern encryption algorithms like AES-256 to protect sensitive data.
Always encrypt data in transit using TLS (HTTPS) and data at rest to safeguard information throughout its lifecycle.
Store passwords using strong hashing algorithms.
Audit cryptographic systems regularly to detect weaknesses and vulnerabilities.
A03 – Injection
Occurs when untrusted input is executed as part of a command or query, leading to unintended actions.
Explanation: Slides down to 3rd position in the list. Not all applications are vulnerable to this attack, only the applications that accept parameters as input are vulnerable to injection attacks.
Example: A login form allows SQL like admin'-- to bypass authentication.
Real breach: The famous Sony Pictures hack exploited SQL injection to access internal databases (2011)
Prevention:
Use parameterized queries or prepared statements.
Validate and sanitize all user inputs.
Avoid building SQL queries using string concatenation.
Apply the principle of least privilege to database users.
Keep your database and libraries up to date.
Deploy a Web Application Firewall (WAF) as an extra layer.
A04 – Insecure Design
Refers to weaknesses that present in the designing process of a product
Explanation: They include flaws like lack of assessment of the security measures required in a design during development phase.
Example: A banking app allows fund transfers without verifying the recipient’s account ownership for the 2nd time.
Real breach: Many fintech apps have been found lacking threat modeling, leading to logic flaws (2020-2023)
Prevention:
Implement secure-by-design principles during development.
Apply rate limiting to sensitive endpoints.
Threat modelling for designing authentication, access controls, business logics and key flows
Conduct unit and integration tests to check if all critical flows of the design are safe as per the threat model
A05 – Security Misconfiguration
Refers when security settings are improperly configured, leaving systems exposed.
Explanation: Moved from 6th to 5th position in the list. The most common reason for this vulnerability is not patching or upgrading systems, frameworks, and components.
Example: Default admin credentials (admin/admin) left unchanged on a production server.
Real breach: Capital One’s AWS misconfiguration exposed over 100 million customer records (2019)
Prevention:
Regularly audit and harden configurations.
Disable unnecessary features like directory listing or verbose error messages.
Using Dynamic application security testing (DAST).
Disabling the use of default passwords and Rotate and enforce strong credentials
Automated process to verify the effectiveness of security configurations time to time
A06 – Vulnerable and Outdated Components
Refers to using outdated software components with known vulnerabilities.
Explanation: Moved from 9th position and previously titled as Using Components with Known Vulnerabilities. It also occurs because developers frequently don’t know which open source and third-party components are present in their applications.
Example: Using jQuery v1.7 with known XSS vulnerabilities.
Real breach: The Struts2 vulnerability exploited in the Equifax breach was due to outdated components (2017)
Prevention:
Remove unnecessary dependencies, features, components and files
Install components of a system only from official sources through secure channels only.
Properly maintain the libraries and components and regularly check for updates and upgrades for each.
A07 – Identification and Authentication Failures
Occurs when authentication mechanisms are weak, allowing attackers to impersonate users.
Explanation: Slide down from 2nd position and previously known as broken authentication. This normally occurs when applications incorrectly execute functions related to session management allowing intruders to compromise passwords, security keys, or session tokens.
Example: Weak password policies allow users to set “123456” as their password.
Real breach: LinkedIn’s 2012 breach exposed millions of weakly hashed passwords using SHA-1 (2012)
Prevention:
Implementing multi-factor authentication(MFA)
Protecting user credentials
Sending passwords over encrypted connections
Weak passwords should not be allowed for any user
Credential Recovery process must be secured
A08 – Software and Data Integrity Failures
Relates to the lack of validation on software updates or critical data.
Explanation: New category in the 2021 edition. If an application relies on dependencies like libraries, modules or plugins from an untrusted source or repository it could lead to Software and Data Integrity Failures.
Example: Auto-updating software pulls code from an unauthenticated source.
Real breach: The SolarWinds attack injected malicious code into trusted updates (2020)
Prevention:
Ensuring libraries and dependencies are installed from trusted repositories.
Unencrypted serialized data should not be sent to untrusted clients without an integrity check.
Use of digital signature to verify the integrity of any software or data.
Secure CI/CD pipelines to prevent unauthorized changes.
A09 – Security Logging and Monitoring Failures
Occurs when security events (e.g., login attempts, error messages) aren’t logged or monitored.
Explanation: Moved from 10th position and previously titled as Insufficient Logging and Monitoring. When applications do not properly log critical events or fail to monitor and alert on suspicious activities. This can delay detection of breaches, hinder incident response, and allow attackers to operate undetected within systems.
Example: A brute force attack on login pages goes unnoticed because no failed login attempts are logged.
Real breach: Target’s 2013 breach went unnoticed for weeks despite alerts from their security system (2013)
Prevention:
Input validation for Login controls, access controls and server-side must be ensured.
Logs generated by the system should follow a particular format that can be easily stored and processed by log management solutions.
Regularly review logs for suspicious activity.
A proper implementation of an incident response plan in case of security incident
A10 – Server-side Request Forgery (SSRF)
Occurs when an attacker tricks a server into sending requests to unintended locations.
Explanation: Newly added risk to the list. When a web application do not validate the user-supplied URLs before fetching them, which lets the attacker to force the legit website to send a forged request to an unexpected destination, despite being protected by firewalls, access controls etc.
Example: A file upload feature accepts a URL input to fetch the file. The attacker provides http://localhost/admin, which the server fetches, exposing internal admin data.
Real breach: SSRF was a key vector in the Capital One AWS metadata exposure (2019)
Prevention:
Sanitization and validation of all client-side input data.
HTTP redirections should be disabled.
Avoid using server-side functionality to fetch remote URLs unless necessary.
If URL fetching is required, limit it to internal logic with strict controls.
Use firewalls and network policies to prevent outbound requests to internal or sensitive systems.
What significant changes are expected in the 2025 edition?

FINAL TIPS & TAKEAWAYS
Security is a shared responsibility across design, development, and operations.
Proactive threat modeling and secure coding help prevent most top risks.
Regular updates and patching are critical to reduce exposure from outdated components.
Access control and authentication must be enforced rigorously to protect sensitive data.
Monitoring and logging are essential for timely detection and response.
Security missteps often stem from misconfiguration—automate checks where possible.
OWASP Top 10 is a living framework—review it regularly to stay ahead of emerging threats.



