Menu
When managing a website it’s important to stay on top of the most critical security risks and vulnerabilities. The OWASP Top 10 is a great starting point to bring awareness to the biggest threats to websites in 2021.
Contents
OWASP stands for the Open Web Application Security Project, an online community that produces articles, methodologies, documentation, tools, and technologies in the field of web application security.
OWASP Top Ten is the list of the 10 most common application vulnerabilities. It also shows their risks, impacts, and countermeasures. Updated every three to four years, the latest OWASP vulnerabilities list was released September 24, 2021. Let’s dive into some of the changes!
Image credit to OWASP
Broken Access Control moved up from the fifth most severe risk in 2017 to the top risk in 2021. There were more instances of Common Weakness Enumerators (CWE) for this than any other category.
Here are some examples of what we consider to be “access”:
Attackers can exploit authorization flaws to accomplish the following:
Here are a few examples provided by OWASP of what can happen when there is broken access control:
This makes it possible for an attacker to send a request like: /wp-json/wp/v2/posts/1234?id=12345helloworld which would assign 12345helloworld to the ID parameter – which now contains more than just digits.
Developers are going to be more familiar with the above scenarios, but remember that broken access control vulnerabilities can be expressed in many forms through almost every web technology out there. It all depends on what you use on your website.
There are things you can do to reduce the risks of broken access control:
To avoid broken access control you should develop and configure software with a security-first philosophy. It is important to work with a developer to make sure there are security requirements in place.
The technical recommendations by OWASP to prevent broken access control are:
Note: For example, if a user logs in as “John,” he could only create, read, update or delete records associated with the ID of “John,” never the data from other users.
The Sucuri Firewall can help black attacks and virtually patch known website vulnerabilities.
Previously known as “Sensitive Data Exposure”, it was renamed to better reflect the root cause of the issue. It moves up from number three to runner-up in widespread vulnerabilities on the OWASP list. It consists of a failure to protect sensitive data that should not have been publicly accessible.
Sensitive data that requires protection includes:
It is vital for any organization to understand the importance of protecting users’ information and privacy. All companies should understand and comply with their local privacy laws as well as any regional ones where they conduct business in.
Responsible sensitive data collection and handling has become more noticeable, especially with the advent of the General Data Protection Regulation (GDPR). GDPR is a fairly recent data privacy law that went into effect May 25, 2018. It mandates how companies collect, modify, process, store, delete and use personal data originating in the European Union for both residents and visitors.
There are two types of data:
Both types of data should be protected. When considering data in transit, one way to protect it on a website is by having an SSL certificate
SSL is the acronym for Secure Sockets Layer. It is the standard security technology for establishing an encrypted link between a web server and a browser. SSL certificates help protect the integrity of the data in transit between the host (web server or firewall) and the client (web browser).
We have created a DIY guide to help every website owner learn how to install an SSL certificate.
OWASP provides a few examples of what can happen when sensitive data is exposed:
Over the last few years, sensitive data exposure has been one of the most common attacks around the world. Some examples of data leaks exposed sensitive data include:
Non-encrypted sensitive data is the main reason these attacks are so widespread. However, even if data is encrypted, it can still be broken due to weak areas like:
This vulnerability is difficult to exploit; however, the consequences of a successful attack are profound. If you want to learn more about such impacts, we have written a blog post on the Impacts of a Security Breach.
Some of the ways to prevent data exposure, according to OWASP, are:
A code injection happens when an attacker sends invalid data to the web application with the intention of making it do something that the application is not designed/programmed to do.
Perhaps the most common example around this security vulnerability is the SQL query consuming untrusted data. You can see one of OWASP’s examples below:
String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “‘”;
This query can be exploited by calling up the web page and executing it with the following URL: https://example.com/app/accountView?id=’ or ‘1’=’1 causing the return of all the rows stored on the database table.
The core of a code injection vulnerability is the lack of validation and sanitization of the data used by the web application, which means that this vulnerability can be present on almost any type of technology related to websites.
Anything that accepts parameters as input can be vulnerable to a code injection attack.
We’ve written a lot about code injection attacks. One of the most recent examples was a code injection vulnerability within the very popular Simple 301 Redirects plugin in WordPress. It made it possible for unauthenticated users to inject code that would redirect all website traffic to a malicious domain of the attackers choosing. The vulnerability affected over 300,000 websites and was ranked as a 9.9 on the CVSS scale.
Preventing code injection vulnerabilities really depends on the technology you are using on your website. For example, if you use WordPress, you could minimize code injection vulnerabilities by minimizing the number of plugins and themes installed.
If you have a tailored web application and a dedicated team of developers, you need to make sure to have security requirements your developers can follow when they are designing and writing software. This will allow them to keep thinking about security during the lifecycle of the project.
Here are OWASP’s technical recommendations to prevent SQL injections:
Preventing SQL injections requires keeping data separate from commands and queries.
From these recommendations you can conclude two things:
Without appropriate measures in place, code injections represent a serious risk to website owners. These attacks leverage security loopholes for a hostile takeover or the leaking of confidential information.
A new addition to the OWASP Top Ten, clocking in at number four on the list, is insecure design. This focuses on the ground-up development of web applications from the very beginning of its life cycle. This is not to be confused with insecure implementation of web applications or policies. One can have a secure design and insecure implementation but not the other way around. It is, essentially, the avoidance of hard-coded security protocols and methods within the initial development of a web application, as well as the failure to take into account risks and attack vectors during the planning, development, and implementation of a web application.
Software developers have a responsibility to write secure applications that do not put its users at risk. Applications that were not developed with security in mind from the very beginning are more likely to put user data and security at risk, and require updates, patches, and fixes to prevent these risks. Applications without secure design are low hanging fruit for attackers and can cost incalculable sums of damage in terms of leaked data, tarnished reputations, and paid working-hours of cleanup and future prevention.
Insecure design is unfortunately quite common within web applications. Some examples include:
To borrow from the OWASP top ten list:
“Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods”
By taking security into account from the very bedrock of the development of a web application, many easily preventable risks can be avoided. Secure design is not a ruleset nor a tool, it is a culture, mindset and methodology.
This category moves up one notch from the previous top 10 list published in 2017. The previous category for XML External Entities (XXE) has been rolled into this one. There is a litany of possible security misconfigurations, but here are the most common:
One of the most common webmaster flaws is keeping the CMS default configurations.
Today’s CMS applications (although easy to use) can be tricky from a security perspective for the end users. By far, the most common attacks are entirely automated. Many of these attacks rely on users to have only default settings.
This means that a large number of attacks can be mitigated by changing the default settings when installing a CMS.
There are settings you may want to adjust to control comments, users, and the visibility of user information. The file permissions are another example of a default setting that can be hardened.
Misconfiguration can happen at any level of an application stack, including:
One of the most recent examples of application misconfigurations is the memcached servers used to DDoS huge services in the Tech Industry.
Examples of Security Misconfiguration Attacks
According to OWASP, these are some examples of attack scenarios:
In order to prevent security misconfiguration use:
Even simple websites such as personal blogs have a lot of dependencies, plugins, extensions and third party code. Failing to update every piece of software on the backend and frontend of a website will introduce heavy security risks sooner rather than later. Attackers actively seek out websites using vulnerable components and aggressively exploit them to spread malware, spam and phishing.
For example, in 2019, 56% of all CMS applications were out of date at the point of infection.
The question is, why aren’t we updating their software on time? Why is this still such a huge problem today?
There are some possibilities, such as:
This might sound dramatic, but every time you disregard an update warning you might be allowing a now known vulnerability to survive in your system. Trust us, cybercriminals are quick to investigate software and changelogs.
Whatever the reason for running out-of-date software on your web application, you can’t leave it unprotected. Both Sucuri and OWASP recommend virtual patching for the cases where patching is not possible.
Virtual patching affords websites that are outdated (or with known vulnerabilities) to be protected from attacks by preventing the exploitation of these vulnerabilities on the fly. This is usually done by a firewall and an intrusion detection system (IDS).
Vulnerable applications are usually outdated, according to OWASP guidelines, if:
You can subscribe to our security blog feed to be on top of security issues caused by vulnerable applications.
Some of the ways to prevent the use of vulnerable components are:
Previously number two on the OWASP list, “broken authentication” has been renamed to this and now ranked at number seven. A broken authentication vulnerability can allow an attacker to use manual and/or automatic methods to try to gain control over any account they want in a system – or even worse – to gain complete control over the system.
Websites with broken authentication vulnerabilities are very common on the web. Broken authentication usually refers to logic issues that occur on the application authentication’s mechanism, like bad session management prone to username enumeration – when a malicious actor uses brute-force techniques to either guess or confirm valid users in a system.
To minimize authentication failure risks avoid leaving the login page for admins publicly accessible to all visitors of the website:
Brute force username/password combinations against those pages.
According to the OWASP Top 10, these vulnerabilities can come in many forms. A web application contains a broken authentication vulnerability if it:
Writing insecure software results in most of these vulnerabilities. They can be attributed to many factors such as lack of experience from the developers. It can also be the consequence of more institutionalized failures such as lack of security requirements or organizations rushing software releases, in other words, choosing working software over secure software.
In order to avoid authentication failure make sure the developers apply to the best practices of website security. Support them by providing access to external security audits and enough time to properly test the code before deploying to production.
OWASP’s technical recommendations are the following:
Another new addition to the 2021 roster is software and data integrity failures. These failures can take many forms, particularly since as the web evolves it is more and more common to use third party code and services within web applications. These failures can be summarised as follows:
WordPress website administrators make heavy usage out of the official WordPress repository. Other CMS platforms have similar libraries that are used. Unlike proprietary software platforms these repositories are all open source and the code is publicly accessible and able to be scrutinised. This is a major advantage but not foolproof. Many open source plugins over the last few years have been targeted by attackers after serious vulnerabilities were discovered within them.
It is also unfortunately common for website owners to use hacked or “nulled” plugins/themes on their website. These are almost always coupled with backdoors that will be used to compromise the website environment.
As our list of examples above indicates, sometimes verifying proper integrity of software is impossible. However, to do our best due diligence the following principles should be adhered to:
The importance of securing a website cannot be understated. While 100% security is not a realistic goal, there are ways to keep your website monitored on a regular basis. This allows you to take immediate action when something happens.
Not having an efficient logging and monitoring process in place can increase the damage of a website compromise.
Here at Sucuri, we highly recommend that every website is properly monitored. If you need to monitor your server, OSSEC is freely available to help you. OSSEC actively monitors all aspects of system activity with file integrity monitoring, log monitoring, root check, and process monitoring.
According to OWASP, these are some examples of attack scenarios due to insufficient logging and monitoring:
Keeping audit logs give visibility to suspicious changes to your website. An audit log is a document that records the events in a website so you can spot anomalies and confirm with the person in charge that the account hasn’t been compromised.
Whatever the reason for running out-of-date software on your web application, you can’t leave it unprotected. Both Sucuri and OWASP recommend virtual patching for the cases where patching is not possible.
We know that it may be hard for some users to perform audit logs manually. If you have a WordPress website, you can use our free WordPress Security Plugin to help you with your audit logs. The plugin can be downloaded from the official WordPress repository.
OWASP resource:
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).
As cloud services increase in usage and popularity as well as their complexity, the prevalence and risk of SSRF attacks increase too. As cloud services increase in usage and popularity as well as their complexity, the prevalence and risk of SSRF attacks increase too.
Attackers can use SSRF to attack systems protected behind web application firewalls, firewalls, or network ACLs, using scenarios such as:
Scenario #1 – Port scan internal servers:
If the network architecture is unsegmented, attackers can map out internal networks and determine if ports are open or closed on internal servers from connection results or elapsed time to connect or reject SSRF payload connections.
Scenario #2 – Sensitive data exposure:
Attackers can access local files such as or internal services to gain sensitive information such as file:///etc/passwd and https://localhost:28017/.
Scenario #3 – Access metadata storage of cloud services:
Most cloud providers have metadata storage such as https://169.254.169.254/. An attacker can read the metadata to gain sensitive information.
Scenario #4 – Compromise internal services:
The attacker can abuse internal services to conduct further attacks such as Remote Code Execution (RCE) or Denial of Service (DoS).
Since 2001, OWASP has been compiling research from over 32,000 volunteers world-wide to educate you on the most dangerous risks facing your website. The change in order and the introduction on new categories has marked a change in the threatscape of the internet. These risks and the strategies provided to mitigate them will put your website security ahead of the curve and out of hackers’ reach.
Say on top emerging website security threats with our helpful guides, email, courses, and blog content.
