OWASP top 10 and how it works
What is OWASP
The Open Web Application Security Project (OWASP) is a non-profit foundation dedicated to improving the security of software. OWASP operates under an ‘open community model, this model enables anyone both to participate and contribute to projects, events, online chats, and more. All materials and information attributed to OWASP are free and easily accessible on their website. The body offers everything from tools, videos, forums, projects, to events related to web application security.
OWASP Top 10 is an online repository housed on OWASP’s website which provides a well-researched ranking and remediation guidance for the top 10 most critical web application security risks. The report is based on extensive deliberations among security experts from different countries. The observed risks are ranked based on the frequency of discovered security defects, the severity of the vulnerabilities, and the magnitude of their potential impacts.
The OWASP Top 10 report is published and updated every two to three years since 2013 in line with the advancement and changes in the application security ecosystem. The table below captures the differences in the 2017 and 2021 update.
The OWASP Top ten servers as a checklist for security auditors to give a central position about the security posture of an application.
The Top 10: 2021
- Broken Access Control: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits.
Example
An attacker simply forces browses to target URLs. Admin rights are required for access to the admin page.
If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw.
- Cryptographic Failures: The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU’s General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS).
Example
A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g., at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could alter all transported data, e.g., the recipient of a money transfer.
- Injection: An application is vulnerable to injection attack when:
- User-supplied data is not validated, filtered, or sanitized by the application.
- Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
- Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
- Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.
Example:
The below code snippet is subject to sql injection, as the condition will always evaluate to TRUE
http://example.com/app/accountView?id=' or '1'='1
- Insecure design: This is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes and remediation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. One of the factors that contribute to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.
Example
A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are prohibited. Such code should be removed and replaced with a more secure design.
- Security Misconfiguration: A security misconfiguration issue might occur if situations like Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges), and Default accounts and their passwords are still enabled and unchanged persists.
Example:
The application server comes with sample applications not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. Suppose one of these applications is the admin console, and default accounts weren’t changed. In that case, the attacker logs in with default passwords and takes over.
- Vulnerable and Outdated Components: These are issues that persist if software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
Example:
Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g., coding error) or intentional (e.g., a backdoor in a component).
- Identification and Authentication Failures: Confirmation of the user’s identity, authentication, and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application: Permits brute force or other automated attacks, Permits default, weak, or well-known passwords, such as “Password1” or “admin/admin”, Uses weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers,” which cannot be made safe.
Example:
Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered, best practices, password rotation, and complexity requirements encourage users to use and reuse weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.
- Software and Data Integrity Failures: Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. Many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations.
Example:
An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise.
- Security Logging and Monitoring Failures: Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs at any time. Some issues are: auditable events, such as logins, failed logins, and high-value transactions, are not logged, warnings and errors generate no, inadequate, or unclear log messages, logs of applications and APIs are not monitored for suspicious activity and logs are only stored locally.
Example:
A childrens’ health plan provider’s website operator couldn’t detect a breach due to a lack of monitoring and logging. An external party informed the health plan provider that an attacker had accessed and modified thousands of sensitive health records of more than 3.5 million children. A post-incident review found that the website developers had not addressed significant vulnerabilities. As there was no logging or monitoring of the system.
- Server Side Request Forgery (SSRF): SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).
Example:
Sensitive data exposure – Attackers can access local files such as or internal services to gain sensitive information such as file:///etc/passwd</span> and http://localhost:28017/
I hope this will serve as a guide when on a security review engagement. Drop your comments.
Leave a Reply