TOP 10 Webapplication vulnerabilities | OWASP

TOP 10 Web application vulnerabilities 2021 | OWASP

The OWASP Top 10 vulnerabilities is a popular awareness guideline for web application security enthusiasts and developers. It contains a wide range of the most critical security vulnerabilities of web applications.

2021 TOP OWASP vulnerabilities are as follows:

  1. Broken Access Control
  2. Cryptographic Failures
  3. Injection
  4. Insecure Design
  5. Security Misconfiguration
  6. Vulnerable and Outdated Components
  7. Identification and Authentication Failures
  8. Software and Data Integrity Failures
  9. Security Logging and Monitoring Failures
  10. Server-Side Request Forgery

Broken Access Control

Applying limitations on who (or what) can perform out attempted actions or access resources that they have requested is known as access control (also known as authorization). Access control as in the context of online applications relies on session management and authentication.

Identification and verification of the user’s identity are accomplished through authentication. The subsequent HTTP requests performed by the same user are tracked by session management. The user’s attempt to perform a certain action is checked by access control to see if they are authorised to do so. Broken Access control issues are a common and potentially serious security risk.

Access control design and management are one of the most challenging issues that combine technological implementation with organisational, business, and legal limitations.

For example, if an ordinary user who is not an admin may access the admin page, their role has not been properly checked. By creating a model access control based on record ownership, this security risk can be reduced.

Cryptographic Failures

Cryptographic Failures, formerly known as Sensitive Data Exposure, focus on errors in cryptography. Hackers frequently attempt to steal data from the user’s browser while it is in transit rather than directly assaulting a system. You must establish a secure communication channel in order to thwart such attacks.

A serious web application security flaw known as a cryptographic failure exposes confidential application data to a shoddy or nonexistent cryptographic scheme. Passwords, medical records of patents, trade secrets, credit card numbers, email addresses, and other private user data are some examples.

Enforcing TLS on all pages is a straightforward fix for this issue for web applications. A hacker can monitor network traffic, downgrade the connection from HTTPS to HTTP, and seize all information transferred in clear text, including user data, passwords, session cookies, and other information, without an enforced TLS policy or with inadequate encryption.

Today’s online applications process data both in transit and at rest, necessitating strict security measures for complete threat prevention. A few deployments use flimsy cryptographic methods that can be broken in a reasonable amount of time. Users may choose not to follow data protection best practises, even with the perfect implementation of cryptographic algorithms, leaving sensitive data open to theft.


When an attacker inserts code into a query that is delivered to a back-end programme, the end target executes it. This is known as injection. Attackers take advantage of this to force the system to carry out unintended orders that they have sent over the API.

Untrusted data by a programme that compels it to execute commands is referred to as an injection attack. An attacker may insert such data or malicious code, which can jeopardise data or the entire application. SQL injections and cross-site scripting (XSS) attacks are the most frequent injection attacks, although there are also code injections, command injections, CCS injections, and others.

Hackers are able to access protected data or even run OS commands using this kind of attack. This latter factor greatly increases the danger of this kind of attack.

Insecure Design

When developers, QA, and/or security teams neglect to foresee and consider dangers during the code design process, insecure design flaws result. These flaws are also a result of applications being designed without following security best practices. Consistent threat modelling is needed to mitigate design vulnerabilities as the threat landscape changes in order to stop well-known attack vectors. 

This group of vulnerabilities focuses on the dangers brought on by design and architectural defects. These are distinct from the hazards connected to implementation flaws, as stated by OWASP. An insecure design that has been implemented well is nonetheless open to attacks.

Part of what is meant by “insecure design” is the absence of security controls and business risk profiling during the software development process, which results in an incorrect assessment of the required level of security design.

The dangers associated with design faults are the focus of the insecure design. A design that lacks threat modelling, secure design principles and patterns, and reference architectures is referred regarded as being insecure.

Security Misconfiguration

The majority of security flaws and the various tools that can be used to exploit them are well known to hackers. Unnecessary open ports, default usernames and passwords, handling failures that give too much information about the application, sample files and programmes that are installed by default but are removed from the production server, and other issues can be examples of these.

Scanners that operate automatically can be used to guarantee an adequate security setting. If you don’t want to spend money on automated scanners, you can lower your chance of being subjected to such attacks by implementing a patch management procedure and deleting files and features that are not in use to get rid of any extraneous code that might be vulnerable to attacks.

Hackers frequently target TLS/SSL misconfigurations because they are well-known and simple to find. Attack vectors frequently have the requisite time to use privilege escalation to exploit such vulnerabilities since security teams need time to follow vectors in complicated communication systems.

Vulnerable and Outdated Components

Vulnerable and Outdated Components, formerly known as “Using Components with Known Vulnerabilities,” is the sole category without any Common Vulnerability and Exposures (CVEs) linked to the include Common Weakness Enumerations (CWEs).

You should constantly keep an eye on all of your external components to safeguard your apps against obsolete and vulnerable ones. When a vulnerability is discovered and a newer version is required, you can use automated tools that notify you.

Previously known as “Using Components with Known Vulnerabilities,” this category. One of the following scenarios may give rise to component vulnerabilities:

If you are oblivious to the client-side and server-side component versions you employ
whether the programme is outdated, unsupported, or vulnerable. Operating systems, web/application servers, database management systems (DBMS), applications, APIs and any related components, runtime environments, and libraries are all included in this.

If you do not routinely check for vulnerabilities and monitor security news regarding the components you use,

If you don’t upgrade or correct your platform, framework, and dependencies as soon as patches are released.

Identification and Authentication Failures

Identification and Authentication Failures, formerly known as “Broken Authentication,” occur when authentication is implemented incorrectly, allowing attackers to gain access and pretend to be another person.

A series of activities and exchanges that take place when a user is logged in together constitute a session. A user is given a special Session ID (Cookies, URL Parameters, Authentication Tokens, etc.) after logging in to a system, which enables the communication between the user and a web app for the duration of the active session. Many developers create sessions without the proper settings, which makes it simpler for a hacker to take over the session ID and get unauthorised access to the system. Additionally, some developers don’t implement session rotation and time limits, which enables attackers to pretend to be users who have already logged in.

Attackers who take advantage of session management flaws manually look for holes in user authentication and verification before using automated methods to gather more data and take over more of the programme. Since attackers are constantly looking for ways to exploit security implementation vulnerabilities to gain access, authentication and session management are essential components of contemporary application security frameworks.

Most user accounts can be effectively protected from this vulnerability by discouraging users from using simple passwords and restricting the number of failed login attempts. To assist users in safeguarding their accounts from inadvertent mistakes and facilitating easy account recovery, you also need to create credential recovery systems and set session timeouts.

Software and Data Integrity Failures

The focus of Software and Data Integrity Failures is on CI/CD pipelines, crucial data, and assumptions made about software upgrades without checking integrity.

Additionally, this vulnerability includes Insecure Deserialization. Any programme that does not deserialize external or tempered objects is considered to be insecure. That’s because hackers would then have the ability to alter the data that the back-end code is receiving.

Simply refusing to accept serialised objects from untrusted sources and limiting the use of serialised objects within your application is the simplest and possibly safest technique to safeguard oneself against insecure deserialization.

Developers are frequently forced to employ plugins, modules, and libraries from public repositories, shady sources, and content delivery networks due to the intricacy of modern update-release cycles. Due to these difficulties, crucial data and software upgrades are uploaded to the delivery pipeline without being checked for integrity, which leads to software and data integrity failures (design flaws). Applications are vulnerable to malicious code insertion, system compromise, and unauthorised information exposure in the lack of proper validation caused by software and data integrity issues.

The lifecycles of modern software are streamlined by auto-update technology, which downloads updates and applies them without requiring any special rights. Threat actors can take advantage of these features by launching a Man-in-the-Middle attack and injecting malicious code into the update pipeline. This leads to the deployment and direct execution of corrupted payloads on application instals.

Security Logging and Monitoring Failures

In order to try and increase their level of privileges, hackers take advantage of holes in logging and monitoring by counting on the fact that security teams will take time to notice and fix the attack. This section examines the risks connected to inadequate logging and monitoring as well as the effects of a successful attack on businesses.
Almost all significant security incidents are the result of inadequate monitoring, unexpected security methods, or insufficient logging. Businesses deploying logging-deficient or -less applications run the danger of attacks taking so long to contain that they can seriously harm the entire tech stack.

Administrators and security teams can use raw traffic data from logging and monitoring services to spot strange trends and potentially dangerous situations.

This category, which was once known as “Insufficient Logging & Monitoring,” has been expanded to include more failure types. Even though logging and monitoring are difficult to test, they are crucial because errors can affect forensics, incident alerting, accountability, and visibility.

Server-Side Request Forgery

TOP 10 Web application vulnerabilities | OWASP TOP, 10 Web application vulnerabilities, owasp top 10 vulnerabilities pdf, owasp top 10 vulnerabilities ppt, owasp top 10 vulnerabilities pdf, owasp, owasp

Server-Side Request When a web application requests a remote resource without first validating the user-supplied URL, forged issues occur. This makes it possible for attackers to bypass firewalls, virtual private networks, or other types of network access control lists in order to cause an application to submit a specially constructed request to an unexpected location (ACL).

Modern web applications frequently use URL fetching, which leads to an increase in SSRF incidents. Additionally, problems are getting worse as a result of the complexity of cloud services and infrastructures.

Attackers target a susceptible application’s backend server by taking advantage of a server-side request forgery vulnerability and tricking it into executing malicious requests for carrying out unwanted actions. Hackers can access internal resources that are inaccessible from outside the network or other systems connected to the webserver by using SSRF attacks. Given the shifting threat environment, SSRF is still ranked as the tenth (A10) of the top ten OWASP vulnerabilities for 2021 and is still viewed as posing a significant security risk for enterprises that own applications.

Web applications rely on inter-server requests to import resource metadata from URLs and access remote resources of other apps. A threat actor can alter parameter values within the application to create fraudulent requests from the backend server if the target URL was created using user-controllable data. Organizations should give SSRF prevention a priority since controlling server-side requests enables hackers to plan a variety of hostile actions on internal networks. The importance of SSRF prevention in application security is covered in the section that follows.

You may like:

Introduction to cybersecurity(Ransomware, Phishing, MITM, DDOS)

Leave a Reply