OWASP Top10 2021 Web Application Security Made Simple

Coming in at number one and moving up from the fifth position from the 2017 list, 94% of tested applications were shown to have some form of broken access control. Notable Common Weakness Enumerations (CWEs) included are CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Exposure of Sensitive Information Through Sent Data, and CWE-352: Cross-Site Request Forgery.

Shifting up one position from the 2017 list to Number 2 is Cryptographic Failures. This was previously known as "Sensitive Data Exposure" which is more of a broad symptom rather than a root cause, and the focus is on failures related to cryptography (or lack thereof). This can often lead to exposure of sensitive data. In this video we'll discuss how these vulnerabilities occur and what to do to prevent them.

Injection attacks move down from the #1 spot on the 2017 list to the #3 spot on the 2021 list. Injection attacks refer to a broad class of attack vectors (not just SQL). In an injection attack, an attacker sends untrusted input to an application. This input gets processed by an interpreter as part of a command or query. In turn, this alters the execution of that program. Injections are among the oldest and most dangerous attacks aimed at web applications. They can lead to data theft, data loss, loss of data integrity, denial of service, as well as full system compromise. I'll explain it all in this video, so check it out!

Insecure design 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. So lets talk about what we can do in these cases.

Security Misconfiguration happens when you fail to implement all the security controls for a server or web application, or implement the security controls, but with errors. This security risk moves up from the #6 spot on the 2017 list. I'll explain the importance of proper security configuration and gives some examples of what to do and what to avoid.

This risk was #9 on the 2017 OWASP Top Ten list but moves up to #7 on the 2021 list. This was a very highly scored risk on the Top 10 community survey but it also had enough data to make the Top 10 even without the survey score. Vulnerable Components are a known issue that we struggle to test, but they can cause a wide variety of problems for applications. Check out the video to learn more about this important security risk!

Previously known as Broken Authentication, this category slid down from the second position in the 2017 list. Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks. Check out the video to learn all about this security risk!

A new category for 2021, this risk focuses on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. 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. Lastly, 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. Another example is where objects or data are encoded or serialized into a structure that an attacker can see and modify is vulnerable to insecure deserialization.

Returning to the OWASP Top 10 (and up to #9 from #10 in the 2017 list), this category is to help detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected. Many organizations don't log application activities properly, and even when they do, they don't monitor those logs to see what happened (or what is currently happening). Check out the video to learn more!

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 modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.

Shifting security to the left means introducing security early on in the development pipeline. The goal is to detect issues quickly, when they can be easily fixed. When security, performance, and availability issues are detected after the product is complete or released, remediation can turn into a time-consuming and expensive process. In this video we will discuss Shift-Left and DevSecOps and how it can enable your teams to take ownership of security.

Thank you so much for watching, I hope you learned something useful! If you have any questions or comments, please leave them in the course, or reach out to me on Twitter. Remember you can always find more on my website.