The Most Common Security Weaknesses: CWE Top 25 and OWASP Top 10

As software became an integral part of our life, software security became critical for the privacy of our data and the availability of services. Over the years, organizations and individuals developed ingenious ways to secure their software and shared the common security pitfalls to inform and educate others. Two well-known non-profit organizations, MITRE and OWASP, share their knowledge on the most common security weaknesses with CWE Top 25 and OWASP Top 10 lists.

In this blog, we listed common security weaknesses from both lists and how software developers and security professionals can address them.

Simulate Common Security Vulnerabilities with the Picus Platform

MITRE CWE Top 25 Most Dangerous Software Weaknesses

Security weaknesses threaten the safe operation of software and are often the root cause of vulnerabilities. These weaknesses have different impacts and risks associated with them and encompass a wide range of issues. Identifying and classifying all the weaknesses is a challenging task that can be addressed best collaboratively.

MITRE's Common Weakness Enumeration (CWE) is a community-develop list of common software and hardware weakness types. CWE is an integral part of the cybersecurity ecosystem that represents a unified, measurable set of software faults that have the potential to introduce security vulnerabilities into a system. Software developers and security professionals worldwide use the list as a common language to identify, classify and share software weaknesses.

Each year, MITRE compiles the top 25 common security weaknesses observed in the last two years as CWE Top 25 list. The research takes CVE Record and CVSS scores into consideration, and the most impactful and common weaknesses make the list. Each weakness in the list is explained in great detail with real-life examples and vulnerabilities. While each item in the CWE list represents a type of security weakness, the list as a whole serves as a useful tool for developers and security professionals to understand the crucial areas that require their attention for securing their software. By integrating it into their security practices, they can contribute substantially to reducing cybersecurity risks.

The latest CWE Top 25 list was published on June 29th, 2023.

OWASP Top Ten

Security weaknesses in any application may have a significant impact on the affected software. However, weaknesses in web applications impact organizations on a larger scale when exploited. Therefore, software developers and security professionals pay extra attention to security weaknesses in web applications. Although it is a subset of security weaknesses in all software, the types and number of security weaknesses in web applications are still too large and need to be addressed with a joint effort.

The Open Web Application Security Project (OWASP) is an open-source project that aims to help organizations, developers, and security teams understand and counteract the most critical web application security risks. Similar to MITRE, OWASP is valuable to the web application ecosystem and has various projects that help the community improve the security posture of their web applications.

The OWASP Top 10 list is the most popular of OWASP's projects, and it is a regularly updated report outlining the ten most critical security risks to web applications. Each category in the list provides detailed information on common issues identified in web applications and how to prevent them. Additionally, OWASP Top 10 gives a list of mapped CWEs for each category. 

While the OWASP Top 10 list is not exhaustive nor complete regarding all the potential risks, it is a great starting point for developers to understand the key security problems faced by web applications. It also provides a standard for application security that developers and organizations can adhere to for improved web application security. 

The latest OWASP Top 10 list was published on September 24th, 2021.

Common Security Weaknesses from CWE Top 25 and OWASP Top 10 Lists

As comprehensive research, CWE Top 25 and OWASP Top 10 have reached similar conclusions in many respects and listed common security weaknesses. The common weakness can be categorized into two categories. The first category is "Access Control Management Issues", and the other one is "Input Validation and Sanitization Issues".

Figure 1: Matching Weaknesses in CWE Top 25 and OWASP Top Ten 2021 Lists

Access Control Management Issues

Access control is a critical component of software security, and its importance is highlighted in many security standards and industry best practices. However, managing access control is often complex, owing to the diverse range of users, roles, data types, and system interfaces. Due to the intricate nature of access control, many software suffers from weakness in access control. Adversaries may abuse these weaknesses for unauthorized disclosure, modification, or destruction of sensitive data. The consequences of weak access control can be severe, involving the loss of sensitive data, impacts on reputation, and regulatory fines.

CWE Top 25 and OWASP Top 10 lists include the following common weaknesses related to access control.

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-22 is a common security weakness that enables unauthorized users to access files and directories under a restricted parent directory. This weakness arises when an application uses the input information to construct a file path that is intended to identify a file or directory located underneath a restricted parent directory. However, the software does not properly neutralize special elements within the filename that can cause the pathname to resolve to a location that is outside of the restricted directory.

CWE-22 is often exploited for Directory Traversal and Path Traversal Attacks. In these attacks, adversaries manipulate a URL in such a way that the web server will access unintended parts of the file system. This can potentially lead to the attacker executing commands directly on the operating system, which can further lead to stealing data, overriding data, or executing malicious commands.

To mitigate the risk against CWE-22, developers should apply one or more of the following recommendations:

• User inputs should be validated before being used as a file path. All characters that have a special meaning for the filesystem should be either disallowed or escaped.
• User inputs should be mapped in a way that bypasses the use of file paths entirely.
• Instead of constructing file paths with untrusted inputs, trusted library calls, such as open(), should be used to enforce necessary constraints to prevent directory traversal problems.
• In terms of server configuration, files located outside the intended directory should be disallowed. Adjusting file and folder permissions to limit access can significantly reduce the associated risk.

CWE-276 Incorrect Default Permissions

Secure by default is a security principle that suggests developers that designed software should be secure and come with limited permissions out of the box. CWE-276 describes the weaknesses in software that grants overly permissive access rights or privileges to a user or a process in the default configuration, creating potential security risks. These incorrect default permissions can lead to unauthorized access, data leakage, or even system exploitation by malicious actors, as they can read, modify, or delete sensitive data or configurations that they should not have access to.

To mitigate the risk against CWE-276, developers should apply one or more of the following recommendations:

• Users should be granted the minimum level of access they need to perform their necessary functions. This is also known as the principle of least privilege.
• User and process permissions should be reviewed periodically, and overly permissive defaults should be rectified.

CWE-352 Cross-Site Request Forgery (CSRF)

CWE-352, also known as Cross-Site Request Forgery (CSRF), refers to a situation when a web application allows an attacker to initiate actions on behalf of a user without their knowledge or consent. In a practical example, an attacker tricks a victim's browser into executing an unwanted action in a web application in which they're authenticated. Unsuspecting users activate this when they click the link or load the webpage, which can result in actions like changing their email address, password or even executing financial transactions on their behalf.

To mitigate the risk against CWE-352, developers should apply one or more of the following recommendations:

• Using Anti-CSRF Tokens, also known as synchronizer tokens, adds a random, unique token in every form or state-changing request. Since the attacker doesn't know this token, they cannot craft a valid form submission and bypass validation of server-side applications without the Anti-CSRF token. 
• Setting the SameSite attribute to strict for cookie-based applications instructs the browser to only send the cookie if the request originated from the same domain. This prevents a potential attacker from sending requests from another domain.
• Requiring re-authentication for sensitive actions such as password changes can significantly reduce the risk of CSRF within web applications.

CWE-862 Missing Authorization

CWE-862 represents a situation where an application does not perform adequate authorization checks to ensure that a user is permitted to access specific information or execute specific actions. For example, a social media site may allow users to view and edit their own profile page - including username, email, and daily posts. However, without proper authorization checks, an attacker may modify the website's URL or launch a specific request to view or alter another user's profile. This could expose sensitive user information and undermine the normal functioning of the application.

To mitigate the risk against CWE-862, developers should apply one or more of the following recommendations:

• An effective authentication process that correctly identifies an individual user should be implemented. Then, each user request should be thoroughly checked for appropriate permissions before the software executes any actions or displays sensitive data.
• Applications should use indirect object references instead of direct ones. Instead of exposing actual identifiers or file paths, a more secure design would employ index, tokens, or other indirect methods to point to the resources. This approach enforces access control checks each time the user attempts to access the resource, preventing unauthorized access.

CWE-863 Incorrect Authorization

CWE-863 refers to the software's failure to assign permissions to only users and services with associated roles. This weakness could lead to the circumvention of intended access restrictions and potentially allow unauthorized privilege escalation. For instance, a customer service agent in an online banking system has the right to view a customer's transaction history but not to make any transactions. If the software fails to distinguish between these different roles correctly, the customer service agent might gain access rights to perform transactions on a customer's account, leading to a serious security issue.

To mitigate the risk against CWE-863, developers should apply one or more of the following recommendations:

• The principle of least privilege should be followed, and users should be provided only with the minimum level of access rights that they need to perform their roles.
• Each functionality and data access point should validate the user has the required permissions for the requested resource.
• Frequent audits and timely rectification of authorization rights help organizations track changes in roles and permissions.

CWE-269 Improper Privilege Management

CWE-269 is a weakness that occurs when a software program does not properly manage privileges for users and processes, creating potential loopholes for the escalation of privileges or unauthorized actions. Adversaries abuse these weaknesses to perform malicious actions that they should be constrained from doing, such as reading sensitive data, writing data, running administrative commands, or altering access controls.

To mitigate the risk against CWE-269, developers should apply one or more of the following recommendations:

• Every user and process should be granted the minimal set of privileges necessary to complete their job function. By strictly limiting access rights, the potential damage that can be done by an attacker is greatly reduced, even if they manage to infiltrate the system.
• Granting and revoking privileges of users and processes should be subject to stringent checks. These operations should also be robustly logged.

CWE-287 Improper Authentication

CWE-287 describes the software weakness that allows adversaries to provide credentials that incorrectly convince the software system to assume a particular identity. A classic example of this is in a scenario where the web application relies solely on client-side cookies for user authentication. In such cases, an attacker may forge a cookie value to impersonate an existing user and bypass any password security measures, potentially gaining unauthorized access to sensitive data or making alterations under the assumed identity.

To mitigate the risk against CWE-287, developers should apply one or more of the following recommendations:

• Multi-factor authentication (MFA) should be implemented. MFA adds layers to the authentication process by requiring multiple pieces of evidence or factors to validate the user's purported identity.
• Session expiration methods such as session time-out and secure logout are helpful in managing sessions created post-authentication.

CWE-306 Missing Authentication for Critical Function

CWE-306 is a type of security weakness in the system that allows an attacker to perform critical functionalities that should have been bound with some level of authentication. Simply put, this weakness occurs when a critical function does not require the user to authenticate, enabling unauthorized parties to perform actions that have serious implications for the system. For instance, a web application that has direct object references, like URL parameters pointing directly to database keys, might allow adversaries to access and manipulate entries by simply changing these references. If authentication is not enforced before allowing access to these direct object references, an unidentified attacker could potentially access confidential information or manipulate sensitive data.

To mitigate the risk against CWE-306, developers should apply one or more of the following recommendations:

• For any critical operation, user requests must be verified for validated user identities before they are executed.
• The use of hardware tokens that implement authentication protocols like time-based one-time password (TOTP) or HMAC-based one-time password (HOTP) adds an extra layer of security that increases the security posture of any software, making them much less prone to exploitation by potential attackers.

CWE-798 Use of Hard-coded Credentials

CWE-798 is a specific type of security issue that describes embedding sensitive data, such as passwords, encryption keys, or similar credentials, directly into the source code. Adversaries extract these hard-coded credentials using debugging techniques and abuse them for unauthorized access and privilege escalation. The use of hard-coded credentials should be avoided if possible.

To mitigate the risk against CWE-798, developers should apply one or more of the following recommendations:

• Applications should utilize secure storage solutions for credentials. Operating systems usually provide mechanisms like secure key chains or credential stores that can be harnessed in a secure manner.
•  Application-level encrypted containers can be used to store credentials.

Input Validation and Sanitization Issues

Sanitizing user inputs is an instrumental part of developing secure software applications. The handling of user-supplied data is often a key source of security vulnerabilities, leading to a range of attacks from SQL Injection to Cross-Site Scripting (XSS). As a rule of thumb for secure software development, software developers and security professionals should never fully trust input originating from users and always assume that user-supplied data can possibly contain malicious exploits. Web forms, URL parameters, or data received over network communications are all examples of user inputs that may be manipulated by adversaries or legitimate users. Therefore, input validation and sanitization should be enforced at all relevant points of your application due to these potential risks.

These security weaknesses are commonly categorized as injection weaknesses, and they are used in injection attacks. CWE Top 25 and OWASP Top 10 lists include the following common weaknesses related to injection attacks.

CWE-20 Improper Input Validation

CWE-20 refers to the security weaknesses where an application doesn't validate or improperly validates input from an upstream component. Weak input validation can result in critical issues such as the execution of malicious scripts, potential breaches of database integrity, or bypassing of business logic restrictions. For example, the root cause of Gitlab CVE-2021-22205 Remote Code Execution vulnerability was CWE-20. In vulnerable versions, user-provided images were handled without proper validation by the service's embedded version of ExifTool. Adversaries abuse this weakness to execute arbitrary commands.

To mitigate the risk against CWE-20, developers should apply one or more of the following recommendations:

• All input data should be validated for length, datatype, syntax, and business rules before being used by any application. Using Web Application Firewalls (WAF) or similar security tools can be beneficial to detect and block common attack patterns, providing an extra layer of security.
• Strong error-handling mechanisms should be implemented, and applications should not expose any detailed error messages or application internals to the end-user, as this information could be used by an attacker to craft targeted attacks.

CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')

CWE-77, also known as Command Injection, refers to security weaknesses that occur when an application does not sufficiently sanitize user-provided input before using it in a system command. Adversaries abuse Command Injection weaknesses to execute arbitrary commands in the target system. For example, if an application takes a filename as input and uses this input to construct a command such as "delete input file", an attacker could provide a file name like "; rm -rf /," which may cause the deletion of all files in the system.

To mitigate the risk against CWE-77, developers should apply one or more of the following recommendations:

• The use of external system commands in applications should be avoided. If this is not a viable option, robust input validation, such as whitelisting input values, restricting data types and lengths, and excluding special characters, should be implemented.
• Special characters in user inputs should be neutralized using encoding and escaping techniques before passing to a system shell.

CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

CWE-78, also known as OS Command Injection, describes the security issue when an application accepts user-supplied input and uses it to construct operating system commands without adequately sanitizing the input. OS Command Injection can be abused by adversaries to control the final OS command's structure and content, leading to unauthorized and often destructive actions. This weakness is very similar to CWE-77, and the same mitigation recommendations should be applied.

CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CWE-79 or more commonly known as Cross-site Scripting (XSS), is a type of security weakness that manifests when an application includes unvalidated and unescaped user input within the output it generates. Adversaries exploit XSS by injecting malicious scripts into content viewed by other users, enabling them to execute scripts in the victims' browsers, steal sensitive data, or perform actions on behalf of the victims. In 2014, a user exploited an XSS vulnerability in Twitter's TweetDeck application and created a worm that affected more than 83,000 Twitter users, which led Twitter to disable TweetDeck until they fixed the issue. While this incident is nearly ten years old, the risk of XSS is still very much present in many applications.

To mitigate the risk against CWE-79, developers should apply one or more of the following recommendations:

• Any HTML metacharacters in user inputs should be escaped and neutralized so the browser doesn't interpret them as part of an HTML tag or an entity.
• Using libraries or functions that automatically encode data to the appropriate context for output encoding is recommended. 
• Implementing Content Security Policy (CSP) can be beneficial. CSP limits what and where scripts can be executed, thus curtailing XSS attacks, even if one manages to inject a malicious script.

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89, also known as SQL Injection (SQLi), is a widespread security weakness that crops up when an application does not correctly separate SQL commands and data. An SQL Injection attack happens when an attacker is able to manipulate the query being sent to the database through user-provided input. For example, if a web application sends a query to authenticate a user by matching the input username and password against its database, an attacker could alter the input such that the application authenticates them without requiring a matching password. Recently, a SQL injection vulnerability found in Progress MOVEit Transfer led to a massive spree of CL0P ransomware breaches.

To mitigate the risk against CWE-89, developers should apply one or more of the following recommendations:

• The use of parameterized queries or prepared statements is recommended. This segregates the query's structure from the data, making it impossible for adversaries to manipulate the query structure through user inputs. Environments like .NET, Java, and PHP provide capabilities to perform such parameterized queries.
• The use of stored procedures may be effective against SQL injection attacks. Stored procedures are predefined SQL commands that are stored and executed in the database. While their use can limit SQL injection, proper input sanitization should still be in place.
• Strict input validation rules for acceptable characters, data length, and types  should be implemented. Web Application Firewalls (WAFs) provide a robust protective layer against SQL injection, as they can block input patterns that attempt to exploit the vulnerability.

CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-94, also known as Code Injection, corresponds to the security weaknesses in applications that use unsanitized user inputs within the code that the application generates. When exploited, Code Injection weakness often leads to Loss of Data or Remote Code Execution (RCE). For example, Python's eval() and exec() functions are known to be abused for Code Injection attacks. If the application that uses these functions does not sanitize user inputs, adversaries may create and send malicious code to be executed by the application. This weakness is very similar to CWE-77, and the same mitigation recommendations should be applied.

CWE-434 Unrestricted Upload of File with Dangerous Type

CWE-434 is a security weakness that occurs when an application doesn't properly validate or restrict the types of files being uploaded. This weakness can allow adversaries to upload malicious files that can lead to serious security threats, such as the installation of malicious software, running malicious scripts, or stealing sensitive data. For example, if a web application permits the uploading of profile pictures without adequately checking the file type and content, an attacker may craft and upload a webshell-embedded image file. Using the uploaded webshell, the attacker can execute commands on the host that runs the vulnerable web application.

To mitigate the risk against CWE-434, developers should apply one or more of the following recommendations:

• User input should be validated for both file type and content thoroughly. The file extensions should match the actual file type that is on the list of acceptable, predetermined files. The content of file uploads should also be carefully validated and scanned with antimalware software before being accepted by the server.
• All uploaded files should be stored outside the webroot or in a place that's inaccessible from the web directly. The application must also maintain strict access controls to limit what can be done with uploaded files.
• Employing strong and multi-layered security mechanisms such as authentication, authorization, or CAPTCHA  can deter unnamed users or bots from uploading files.

CWE-502 Deserialization of Untrusted Data

CWE-502 is a security weakness that crops up when software deserializes data from an untrusted source without performing proper validation or sanitization. Deserialization is a process that converts data from a raw format into an object. If adversaries can control the raw data, they can potentially manipulate the resulting object and execute malicious actions such as remote code execution, denial of service, or access control bypass. For example, a Java deserialization weakness in the Log4j library was essential to exploiting the infamous Log4Shell vulnerability that allows remote attackers to execute arbitrary commands in vulnerable applications.

To mitigate the risk against CWE-502, developers should apply one or more of the following recommendations:

• Applications should refrain from deserializing data from untrusted or unauthenticated sources. If the application needs to understand complex user-specified data structures, consider using formats that only represent data and cannot represent arbitrary code execution, such as JSON or XML.
• User inputs should be sanitized and validated before serialization. Additionally, implementing typing controls can restrict what classes can be created during deserialization, preventing an attacker from utilizing a potentially dangerous class.

CWE-918 Server-Side Request Forgery (SSRF)

CWE-918, also known as Server-Side Request Forgery (SSRF), is a weakness that allows adversaries to trick a server-side application into making requests to internal-only services within its network. Applications vulnerable to SSRF take an untrusted URL or server name from user-provided data and send a request using this information without rigorous validation or sanitization. When exploited, this weakness may lead to information disclosure, execution of unintended actions, or other adverse consequences. In 2021, the Chinese APT group HAFNIUM exploited an SSRF vulnerability found in Microsoft Exchange Server to steal sensitive information from defense contractors, schools, and other entities in the United States.

To mitigate the risk against CWE-918, developers should apply one or more of the following recommendations:

• User-provided URLs should be validated for correct formatting. The requested host in the URL should be validated against a whitelist of known safe hosts.
• Network-level controls, such as firewalls, should restrict outbound traffic from internal-only hosts to lower the chance of an attacker being able to interact with them.
• Disclosing detailed error messages should be avoided during the request retrieval process. Error messages could provide useful information to an attacker who's testing for vulnerabilities.

Conclusion

In the past, software developers would not consider security as a priority in their design process, and security was often an afterthought. However, modern applications cannot ignore the security needs and requirements of users and organizations. Regardless of their specialization, all software developers and cybersecurity professionals should be aware of, and adhere to, industry best practices for secure software design and development. It can be said that following industry best practices in secure software design is no longer a luxury but a necessity. 

MITRE's CWE Top 25 and OWASP Top 10 Lists are valuable and comprehensive resources that professionals can use as guides to secure software development and testing. By integrating security into the software's design, managing access controls properly, validating and sanitizing all user inputs, adopting stronger and multi-layered authentication mechanisms, and supporting continuous learning and adaptation, organizations can develop more robust and secure software against evolving cyber threats.