The Open Web Application Security Project (OWASP), Top 10 list (maintained since 2003 and announced every few years), highlights the ten most critical security risks to web applications.
It is recommended that organisations adopt the OWASP Top 10 to ensure their web applications are not exposed to any cyber risks.
According to OWASP:
The Top 10 OWASP vulnerabilities in 2021 are:
- Broken Access Control
- Cryptographic Failures
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery (SSRF)
How was the OWASP Top 10 put together?
OWASP selected eight of the ten categories from contributed data and two from the Top 10 community survey at a high level.
AppSec (Application security) researchers attempt to find new vulnerabilities and new ways to test for them. Because of the nature of the testing, it takes time to integrate these tests into tools and processes. More than likely, years will have passed, so it’s not easy for OWASP to accurately test a weakness at scale.
To balance this view, OWSP conducts a community survey. The survey asks application security and development experts (in the field) what they see as essential weaknesses that the data may not have shown yet.
What is included in the OWASP TOP?
A01:2021-Broken Access Control
Access controls enforce policies so users cannot act outside their intended permissions. Failures generally lead to unauthorised information disclosure or modification, destruction of data, or performing an organisation function outside a user’s restrictions.
Formerly known as Sensitive Data Exposure, Cryptographic Failures are all about protecting sensitive data. This includes personal information such as passwords, credit card numbers, health records, and other data organisations require extra protection for. Cryptographic Failures are especially worth noting if the data falls under GDPR or other regulations.
Injection occurs when suspicious data is sent to an interpreter as part of a command or query. An example of this could be a malicious user controlling the response generated by an application and managing the servers, thus deceiving the interpreter to carry out unintended commands or access data without proper authorisation.
Applications are at risk when:
- User-supplied data is not validated, filtered, or sanitised by the application.
- Dynamic queries or non-parameterised 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.
Insecure Design focuses on risks related to Design and architectural flaws. There is a call for more threat modelling, secure design patterns, and reference architectures to go beyond “shift left”.
According to OWASP, “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. A perfect implementation cannot fix an insecure design as, by definition, needed security controls were never created to defend against specific attacks. One factor contributing to insecure Design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine the level of security design required.”
While several vulnerabilities happen because of underlying code errors, this Security Misconfiguration relates to the misconfiguration of any layer of the applications stack from the software package or cloud platform up to the individual deployed application layer. It will thus embody unknowingly exposed services or ports, out-of-date or unpatched frameworks or the stack on which the framework sits, default passwords, or prolix error show left enabled on production systems. Typically, it may be a case of the server administrator failing to alter the settings inside the stack to harden the protection of the setup.
A06:2021-Vulnerable and Outdated Components
Vulnerable and Outdated Components include any software that is vulnerable, unsupported, or out of date. If you are unsure of the versions of your components – including all direct and indirect dependencies – or neglect to scan and test your components, you are likely at risk.
A07:2021-Identification and Authentication Failures
To protect against authentication-related attacks, it is critical there is confirmation of the user’s identity, authentication, and session management. Failure to do so can result in attackers being able to exploit passwords, key session tokens, or implementation flaws and assume a user identity.
A08:2021-Software and Data Integrity Failures
Software and data integrity failures are defined as code and infrastructure not protected against integrity violations. For example, 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 unauthorised access, malicious code, or system compromise. Additionally, many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could upload their updates to be distributed and run on all installations. Another aspect to consider is where objects or data are encoded or serialised into a structure that a malicious attacker can see and modify is vulnerable to insecure deserialisation.
A09:2021-Security Logging and Monitoring Failures
Security Logging and Monitoring Failures include errors in detecting, escalating, and responding to live breaches. Without logging and monitoring, a violation or breach will not be seen. Examples of insufficient logging, detection, and monitoring include not logging auditable events like logins or failed logins, warnings and errors that generate inadequate or unclear log messages or logs only stored locally. Failures in Security Logging and Monitoring Failures will impact visibility, incident alerting, and forensics.
A10:2021-Server-Side Request Forgery (SSRF)
SSRF (Server-Side Request Forgery) flaws occur when a web application fetches a remote resource without validating the user-supplied URL. An attacker can then force the web application to send a specially crafted request to an unexpected destination, even when protected by a firewall, VPN, or access control list (ACL).
Web Application Testing with Sapphire
As organisations conduct more business online and deliver services conveniently, these systems are open to exploitation. Sapphire will test these systems and advise on the security configuration and vulnerabilities within a selected website application.
Typically, in two stages, the test will be completed initially with no authentication to the application and then with a valid user account for testing privilege escalation vulnerabilities and assessing any weaknesses with the authentication and authorisation mechanisms.
Sapphire will test the user journey based on all the system’s features, such as registration, content or document uploads, e-commerce facilities, form submissions, and reporting based on several user roles. Using the OWASP guide, we will check all the website functionality, authentication, and validation.
As part of our structured web application reports, Sapphire will respond to your key security questions, namely:
• Are the web applications suitably protected from unauthenticated users gaining access to members or admin data services?
• Are the web applications suitably protected from malicious authenticated users?
• Are the correct user management practices preventing horizontal and vertical privilege escalation from obtaining personal details?
• Is there correct segregation between users and admin accounts?
Frequently Asked Questions on Owasp 10
1. How Does the OWASP Top 10 Gather the Knowledge?
The OWASP Top 10 is not merely a list. The OWASP, risk rating system, evaluates each vulnerability category and offers recommendations, best practices for avoiding attacks, examples, and references for each risk.
The security risk ranking is gathered through a consensus between security experts from all over the world. In addition, it draws on the vast expertise and experience of contributors in the open community of OWASP.
The ranking is based on the frequency of the detected security flaws, the seriousness of identified vulnerabilities, and the size of their possible impacts.
2. What are Other Common Vulnerabilities apart from OWASP’s Top 10?
Although OWASP Top 10 vulnerabilities are the most harmful and widespread, hackers explore other security vulnerabilities when attacking a website. They include:
a). Open Redirects
An open redirect vulnerability is one of the top ways to exploit, and it needs almost no hacking experience. This application’s security flaw can be exploited and lead users to a malicious website.
Vulnerable applications have a problem in that they improperly authenticate URLs, making it impossible to tell whether they are a part of the domain of the intended page. Instead, these programs redirect to the given page, regardless of the URL.
This flaw is frequently exploited to generate phishing attacks that steal user passwords and manipulate users into making payments.
b). Excessive Data Exposure
Sometimes we overdo things, which is the same when handling specific cases while you are developing applications. For example, we often disclose more data than is necessary for web applications, extra object properties, unnecessary error-handling details, etc.
This happens regularly when we give more attention to improving the user experience than we do to the sensitivity of the data we expose. The issue is that an attacker might exploit this extra knowledge to gain access to the network or steal sensitive data.
3. Why is the OWASP Top 10 Important?
The OWASP Top 10 is a crucial foundational resource for developing a secure code.
Many organisations use the report’s actionable advice as a checklist and internal web application development standard. Its major goal is to provide developers and web application security experts with insight into the most common security issues so they may incorporate the report’s conclusions and recommendations into their security practices, decreasing the existence of known vulnerabilities in their apps.
Developers may construct safe applications that protect their users’ data from hackers by writing their own code and testing with these web application security risks in mind.
Auditors frequently interpret a company’s failure to address the OWASP Top 10 as a sign that it could not meet other compliance criteria. On the other hand, including the Top 10 in the software development life cycle (SDLC) demonstrates a company’s dedication to using the most secure development practices available.
4. What Is the Top Application Security Risk Reported by OWASP?
Injection attacks are the top software security risks reported by the OWASP. The injection can send untrusted data through SQL or other paths like the LDAP, leading the interpreter to sensitive data exposure. This access to critical data could also lead to executing commands not intended by the application security tools.
5. Which Vulnerabilities were Added or Removed from the Updated List?
- Insecure design is a new vulnerability that reflects the focus on the “shifting left” and integrates security into the full development lifecycle.
- Server-side request forgery is another added vulnerability voted on by users in the community survey.
- Software and data integrity failures were added, focusing on the integrity of the software security updates and CI/CD pipelines.
- Cross-site scripting and XML external entities (XXE) were removed and merged into other categories like Injection and Security Configuration.