Understanding the OWASP Top 10 2021 Application Security Risks

Web application vulnerabilities remain one of the most significant cybersecurity challenges organizations face today. According to recent data, web apps are involved in over 40% of reported breaches, often allowing attackers initial access or exposing sensitive customer and business data. Preventing these flaws in custom-built and third party web applications has never been more critical.

That’s why over the last 18 years, the OWASP Top 10 list has become an absolutely essential resource for anyone involved in designing, developing, testing, or running web apps and APIs. Today, it represents the bare minimum awareness of risks – a common baseline that development teams reference throughout the software development lifecycle.

While entire conferences, training courses, certifications, tools, and consulting practices are built around the Top 10 list, it can still seem confusing particularly for anyone new to the concepts it represents. That’s the purpose of this blog – to fully explain the significance of the OWASP Top 10, how the list is compiled, what type of threats it contains, and break down each of the top application security risks developers need to address.

Whether you’re new to web app sec or an experienced professional, this blog will help cement your understanding of the seminal industry-standard Top 10 risks including injection attacks, access control issues, security misconfigurations, cryptography failures, and more. Let’s start unraveling the fundamentals of the OWASP Top 10.

What is the OWASP Top 10?

The OWASP Top 10 list identifies the 10 most critical web application security risks organizations face. Updated every 2-3 years based on comprehensive industry data, the Top 10 represents the absolute bare minimum risks development and security teams need to be aware of when designing, developing, testing, and running web apps and APIs.

While OWASP provides many resources, the Top 10 list is arguably their most well known and influential project outside of application security circles. Countless organizations mandate familiarity with the list before working on critical web apps. Various training courses, certification exams, tools, auditing checklists, and more use the Top 10 risks as a baseline.

At the highest level, the list contains broad categories of vulnerabilities like injection attacks, access control issues, security misconfigurations, cross-site scripting, improper input validation, and more. Each category contains dozens of more specific weaknesses and thousands of common vulnerabilities that have been mapped to real-world software flaws behind major breaches.

See also  What Is A Privilege Escalation Attack? How To Prevent Privilege Escalation Attacks?

The list is completely open and available for anyone to reference. It’s developed by leading application security experts who carefully analyze the latest vulnerability data to determine what the most prevalent and critical risks are. The project relies on community support and feedback from across the industry.

While the list focuses on awareness over technical detail, it manages to break down each risk category describing common errors, providing demonstrative vulnerable code examples, listing potential impacts, and offering high level remediation guidance. This makes it the ideal starting point for anyone looking to learn application security basics.

The OWASP Top 10 won’t make you an expert or teach highly technical secure coding techniques. But it will ensure you understand exactly where developers, security champions, and business executives should focus their efforts for maximum impact. That’s why the list proves so invaluable as a common language and reference point for application security.

How OWASP Creates the Top 10 List?

OWASP took lot of parameters and factors into account to prepare the list. To let you understand how the list has been prepared we divided this into a several steps or stages. Let’s see one after other.

Relationship Between Owasp Cwe And Cve
Gathering the Raw Vulnerability Data

The first critical step in creating the OWASP Top 10 is gathering vulnerability data from a wide range of industry sources. This includes statistics from major application security testing vendors who conduct millions of scans against their customer bases. Additional data is sourced from major bug bounty platforms based on what flaws their crowdsourced ethical hackers are uncovering. And large enterprises share anonymized internal application testing results through OWASP as well.

This raw data provides invaluable visibility into vulnerability frequency and distribution across tens of thousands of real-world applications. But to analyze risks systematically, the flaws need to be categorized consistently.

Normalizing Vulnerabilities with CWEs

This is where MITRE’s Common Weakness Enumeration standard comes into play. The CWE list contains over 1000 entries describing nearly all known categories of software weaknesses. Each CWE covers a specific type of flaw like input validation errors, access control issues, injection attacks, buffer overflows, and so on.

See also  How To Fix CVE-2022-30190- A Zero-Click RCE Vulnerability In MSDT

For example, CWE-434 specifically describes unrestricted file upload vulnerabilities often leading to remote code execution.

By mapping every vulnerability to its related CWE, analyzing risk becomes more consistent. Instead of each vendor calling the same type of flaw something different, they can normalize around CWE-434.

CVEs – Public Vulnerability Catalog

CWEs describe weakness categories, but actual software vulnerabilities and exposures get assigned Common Vulnerability and Exposure (CVE) identifiers through MITRE as well. For instance, CVE-2021-44228 refers specifically to the Log4j remote code execution bugdiscovered in late 2021.

By linking CVEs to associated CWEs, critical analytics can be performed – such as identifying the most prevalent and exploited CWEs over the past few years.

Connecting CWEs to Top Risks

The key purpose of gathering such a critical mass of normalized vulnerability data is to pinpoint the most widespread and critical CWEs behind various flaws. By mapping CWEs to the OWASP Top 10 risks, the most high frequency and high severity weaknesses bubble up based on sheer volume.

The latest 2021 OWASP Top 10 release is linked to nearly 400 CWEs identifying numerous varieties of weaknesses within each Top 10 category. Compare this to just 30 CWE mappings in 2017 – showcasing OWASP’s commitment to more data-backed risk analysis.

Surveying Emerging Risks

Since the CWE data is based on past vulnerabilities and weaknesses, OWASP also surveys security professionals to nominate emerging risks not necessarily visible yet through vulnerability data. This allows the Top 10 to balance reactive and proactive risk awareness.

Ordering by Severity

The final steps aggregate the total corpus of vulnerability data associated with each identified CWE and analyze additional factors like these to generate an overall severity score:

  • Incident rate – how often the vulnerabilities were found in testing

  • Exploitability/impact scores

  • Testing coverage

  • Total occurrences

  • Community survey feedback

This methodology is how OWASP transforms huge amounts of raw vulnerability data into actionable intelligence – the data-backed OWASP Top 10 risks we should be most aware of and concerned by from an application security perspective.

Overview of the OWASP Top 10 Application Security Risks

Here’s a quick rundown of each Top 10 category for 2021:

  1. Broken Access Control: Flaws allowing attackers to bypass authorization checks to access unauthorized functionality or data (34 related CWEs, 19,000+ CVEs).

  2. Cryptographic Failures: Failing to encrypt sensitive data or use weak/insecure encryption algorithms (29 CWEs, 3,000+ CVEs).

  3. Injection: Untrusted data injected into a web app is interpreted as code commands (e.g. SQL injection) (33 CWEs, 32,000+ CVEs).

  4. Insecure Design: Design flaws that compromise security across the app (40 CWEs, 2,600+ CVEs).

  5. Security Misconfiguration: Insecure default configurations, missing security hardening, etc. (20 CWEs, 200,000+ occurrences).

  6. Vulnerable Components: Using outdated libraries/frameworks with known vulnerabilities (3 CWEs, 30,000+ occurrences).

  7. Identification and Authentication Failures: Flawed user identification, authentication, and session management (22 CWEs, 4,000+ CVEs).

  8. Software Integrity Failures: Code and dependencies compromised via insecure update processes, CI/CD pipelines, etc. (10 CWEs, 48,000+ occurrences).

  9. Logging & Monitoring Failures: Insufficient logging, sensitive data exposure in logs, etc. (4 CWEs).

  10. Server-Side Request Forgery (SSRF): Attacker exploits app to access unauthorized internal resources/functionality (1 CWE, low occurrence but high 8.3 impact score).

See also  How I Detected Vulnerabilities on Client’s Network?

What Should Developers Do?

The first step is getting familiar with these risks and the many resources OWASP provides around them, including:

  • Cheat Sheets: Concise guides with tips for avoiding common pitfalls

  • Application Security Verification Standard (ASVS): Detailed secure coding checklist

  • Testing Guide: Recommendations for incorporating security testing

  • Top 10 Proactive Controls: Design and coding best practices

Beyond awareness, organizations should adopt secure software development lifecycle (SSDLC) processes addressing security at every stage – from planning through design, coding, testing, and delivery.

OWASP’s SSDLC guidance and threat modeling resources are extremely helpful for putting an SSDLC in place.

Don’t Stop at 10!

The Top 10 risks are clearly not the only issues developers face. As a reminder, OWASP calls out several other common problems as “Next Steps” like code quality, denial of service, and memory management vulnerabilities.

Visit OWASP.org to explore many other application security domains and continue advancing your security knowledge.

Leave a Reply

Your email address will not be published. Required fields are marked *