TechKnowSurge
VideoSecurityFree

Common Weakness Enumeration (CWE)

Common Weakness Enumeration (CWE) is a structured, numbered database of software and hardware weaknesses maintained at cwe.mitre.org that helps security professionals categorize and track recurring coding flaws before they become real-world vulnerabilities. Understanding CWE alongside CVE provides a clear framework for distinguishing between general weakness categories and the specific incidents they produce.

Complete this video to capture a CTF flag worth 1 point.

About this video

Common Weakness Enumeration (CWE) is a structured, publicly available database maintained at cwe.mitre.org that catalogs and numbers recurring weaknesses found in software and hardware. Currently tracking nearly 950 entries, the database organizes weaknesses into a hierarchy that moves from broad pillars such as Improper Access Control and Improper Neutralization, down through classes, base entries, and variants, with each level representing a more specific type of flaw. Every entry carries a unique numeric identifier, which allows security teams, developers, and researchers to reference a particular weakness precisely and consistently across tools, reports, and standards. A critical concept within CWE is the distinction between a weakness and a vulnerability. A weakness is a general category of coding error or design flaw that could exist in any system, such as SQL injection or a race condition in multithreaded code. A vulnerability, by contrast, is a specific, real-world instance of that weakness present in an actual product, tracked separately through the Common Vulnerabilities and Exposures (CVE) database. The relationship between the two is that CWE entries describe the class of problem, while CVE records document individual occurrences, often linking back to the relevant CWE to provide context on the underlying cause. Each CWE entry provides a detailed profile of the weakness it describes, including a plain-language description, alternative terminology, common consequences of exploitation, potential mitigations, detection methods, and mapped CVE examples drawn from real incidents. The SQL injection entry, CWE-89, illustrates this depth well, offering extended descriptions of how improper handling of user input can expose database contents, alongside historical CVE cases, attack pattern associations, and code-level examples. This combination of classification structure and detailed reference material makes CWE a practical resource for developers looking to write more secure code and for security professionals working to understand, communicate, and remediate the root causes behind known vulnerabilities.

What you'll learn

What's covered

Common Weakness Enumeration (CWE)

Key terms

Common Weakness Enumeration
CWE
Common Weakness Enumeration is a community-developed catalog of software and hardware weaknesses that serves as a common language for describing security flaws, enabling developers and researchers to identify and remediate root causes of vulnerabilities.
Common Vulnerabilities and Exposures
CVE
Common Vulnerabilities and Exposures is a publicly maintained dictionary that assigns unique identifiers to known software and hardware vulnerabilities, providing a common reference point for vulnerability tracking, disclosure, and remediation.
Vulnerability
A weakness in a system, application, or process that can be exploited by a threat actor.
SQL Injection
SQLi
An attack that inserts malicious SQL code into a query to manipulate a database.
Exploit
A piece of software or technique that takes advantage of a vulnerability to gain unauthorized access or cause harm.

Topics

Common Weakness Enumeration Cve Cwe Vulnerability Management Sql Injection Application Security Mitre Frameworks

Transcript

A vulnerability you build in

Let's say I build a house and I don't put a lock on the front door. What I've done is I've introduced a vulnerability, a vulnerability that somebody could exploit. They could exploit it by walking in the door anytime that they wanted. Well, this could be a problem. At least in the United States, it's common practice to put a lock on the front door.

The same thing is true when you're coding. You put certain things in your code to make sure that it's secure, and if you don't do it, you introduce a vulnerability. So what we do is we actually track all of these vulnerabilities, and we also track the weaknesses, these common weaknesses that are out there. So let's get into common weakness enumeration, or CWE.

Let's say I'm creating a multi-threaded application and the processor could be processing many things at once. What could happen is that these two processes could step on each other's toes. We call this a race condition. We'll talk more about it in another lesson, but essentially, if I don't take proper steps to make sure that this doesn't happen, it can easily work its way into my program when I'm developing a program. And this could be problematic. So this is a common weakness that can happen out there.

The CWE database

We keep track of these common weaknesses. I'm here at the cwe.mitre.org website, so this is the database of all those weaknesses: common weakness enumeration. Enumeration because we're counting them, or we're labeling them, or we're actually categorizing them, so we're doing some sort of enumeration where we're keeping track of these. And the weakness part of this is because they're weaknesses and they're common.

First of all it shows here all weaknesses, 943 total, so they are tracking 943 total weaknesses here. We can sort this by software, we could sort it by hardware, or we're just going to take a look at all weaknesses. So I'm going to click on all weaknesses.

If we scroll down about halfway through, we see these different categories here. This is a tree that we can open up the different branches of and look inside of them. At the top level here, we call these pillars. If I hover over the P right here, it actually gives us a description of what the pillar is. So we see all of these different pillars here. Some examples: improper access control, or incorrect calculation, or incorrect comparison. And then the numbers at the end here, these are because they're numbered, they're enumerated. So these are the number that we associate with each one of these categories, with each one of these pillars. So incorrect comparison is number 697. Improper neutralization is 707.

Digging down through the tree

What we're going to do is look inside one of these and start digging a little bit further down. Let's get into improper neutralization. I'm going to open that up. Under here we've got several classes. We've got these base right here, we've got classes, and if you notice, most of the classes we can dig down further. Once again, this is like a subcategory here. So we've got pillars, which are like categories, and classes, which are like subcategories.

We can open up a class. The one I'm going to look more into is this improper neutralization of special elements in output used by a downstream component. That's a lot to say there, but it says injection here. We're going to get into injections, and that's a real common one, so we're going to open up injections and take a look inside of it.

Notice that there are also subcategories to the subcategories. So we've got classes here, we've also got some base here, and in here we see several injection types and attacks. These are all categories of injection types and attacks. We've got special element injection, a command injection, cross-site scripting injection, CRLF. So we've got different ones that we have here.

We're going to take a further look into this code injection, which is a base. A lot of these can be categorized under this base here, improper control of generation of code, or code injection. We also see another one popping up here. This variant is going to be a variant on these, so it's really the same thing. It's just a way to bury these down into these different categories here. You could really classify it into most of these, but you try to get as specific as you can. So if it applies to this eval injection, if it applies to this one, this is what you want to categorize it as. But if it doesn't apply to any of these subcategories, then you could apply it to this just code injection 94.

So what we're trying to do is categorize all of these vulnerabilities into these weaknesses. We're going to jump into this 943, so I'm going to break this down. One of the things we see here is this 89. This is the SQL injection. SQL injection is a common one that we're going to take a look at, and you can see that there's a variant of this. SQL injection is a common one that we talk about, so we'll take a look at this SQL injection.

Inside a weakness entry

With each one of these, what we could actually do is take a further in-depth look into, well, what is SQL injection? I'm going to open that up in a new tab. Here's the information on SQL injection. Once again, what we do is we give it a tracking number, so this is CWE9. That is the category, or the number, that we associate with SQL injection.

Now this has a ton of information that we have on it. One of the first things that we can do is categorize, or be able to shuffle through, this information. Do we just want to know the conceptual information? Notice that the page has eliminated some of the categories then. Or do we want the operational information, or are we just going to take a look at the complete information?

In this first section right here we have a vulnerability mapping, and it says allowed, which just means that we can assign this to a real-world vulnerability. There are other ones here, like if we were to take a look at the pillar here, it says it's discouraged, which means that we could utilize it, we could categorize a vulnerability to this improper access control, but it's not recommended to do that really. We want to assign it to this SQL injection right here.

Weakness versus vulnerability

We also are going to track a lot of common vulnerabilities that are out there, and so we can now categorize these vulnerabilities according to their common weakness. So one question might arise: what is the difference between a weakness and a vulnerability?

A weakness is, once again, more like a category of vulnerabilities. So an example might be SQL injection. SQL injection is something that commonly happens out there because we have not written our code correctly. However, if I were to actually write a piece of code and then put it out there and people started using this, now I've created a vulnerability. So a vulnerability is much more specific to an incident.

Here's a little bit of an analogy. Let's say that people don't have locks on their front door. This could be a weakness; at least in the United States, that's a common practice, so we consider this a weakness. Any house could have that weakness. Now, if I were to create a house that doesn't have that lock on the front door, I've now created a vulnerability. So what we do is we track these specific incidents, and those are called vulnerabilities. And then we can also track weaknesses, which is just the not having a lock on the front door.

So a SQL injection is a weakness, and if we were to do improper coding and implement that weakness, we would now create a vulnerability. We track those vulnerabilities using CVE, and we track these weaknesses using CWE. There are two different databases that we track these different vulnerabilities and these weaknesses in.

So the vulnerability mapping is showing us whether we should be allowed to map a specific vulnerability to this weakness right here. And down below we'll actually see several of the mappings.

The rest of the entry

Then what we have here is a description: a description of what a SQL injection is, and how it happens, and how you can put input data into here and get data out of the database that you might not necessarily be able to have access to. So that's an example. It gives a description of what the SQL injection attack is.

So what else do we have? We have alternative terms, because there are a lot of people that will use different terminology for this, so it gives some alternative terms. Some common consequences: if you were to actually have this type of vulnerability, what are the consequences of that? And then potential mitigations: how can we fix the situation? So it gives us a ton of great information around this SQL injection attack, what it's related to, and some examples. It goes through the examples and what the examples look like, which is a great way to wrap our mind around what this looks like.

And then also these common vulnerabilities and exposures. So this is how it relates to the common vulnerabilities, and as I mentioned, the weakness is more of a category of a common weakness that gets implemented, and then what are specific examples of this. Notice it's just examples. There are a lot more vulnerabilities that have happened out there, but we see here from 2017, 2008, 2003, 2023, a bunch of different examples.

A specific vulnerability

Let's see if we can get a specific example here. Let's take a look at this CVE 2021. So this happened in 2021, and it's the 42,253 vulnerability that was categorized in 2021. It has to do with some time and billing software, so let's take a look at that. We see a specific software here, BillQuick Web Suite 2018. It gives specific dates that this vulnerability was out there, and a little information on it: it was using MSSQL Server for this. So it gives a bunch of data around what this vulnerability was.

So once again, a vulnerability is the specific incident of what has happened, with this CVE, versus the weakness, which is the SQL injection, the category of weakness.

Scrolling down a little bit further, we've got some detection methods of how to detect if this is a problem, and some other information here. So this has just a ton of great information. This is interesting: attack pattern. So it associates it with attack patterns, which I go over in another lesson, so how it could actually be utilized out there. And then some references here.

To finish this off, let's go ahead and go back to here. What we can do is we can expand all, and it's going to show us all of the different, all the 9 and whatever different weaknesses that we have within this database, things that they're tracking within this database.

About TechKnowSurge

TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.

Explore free tools and programs →