In the rapid-fire environment of today’s development cycles, security can often be left as a checkbox item without any real consideration. Understanding the vulnerabilities that can be built into applications is a good place to increase overall security hygiene. The OWASP Foundation puts out the OWASP Top 10 vulnerabilities list to help organizations and developers accomplish this.
The OWASP Top 10 is a collection of security vulnerabilities reported from actual web application data and other sources. The list provides detailed information about these vulnerabilities, including examples of each.
In this blog, we’ll dive into each point in the OWASP Top 10 2022 list and look at security precautions organizations can adopt to prevent these risks.
- What is the OWASP Top 10?
- Methodology: How are the vulnerabilities ranked?
- New vulnerability categories
- OWASP Top 10 application vulnerabilities 2022
- How to protect against application security vulnerabilities
- Next steps
What is the OWASP Top 10?
The OWASP Top 10 is put out by the Open Web Application Security Project (OWASP) Foundation. OWASP is a non-profit organization with a mission to bolster software security across industries. To further that mission, OWASP maintains and publicly shares the OWASP Top 10, an awareness document for web application security vulnerabilities.
For each ranking period, OWASP collects application data from a variety of sources and conducts a survey to gather important information about the top vulnerabilities developers encounter but that may not be expressed in the application data received. These are usually trends developers observe that may have the potential to cause damage. Submitted web application data and survey results are used together to rank the top ten security vulnerabilities.
Methodology: How are the vulnerabilities ranked?
Vulnerabilities are ranked based on a range of factors, which include analysis of actual web application data submitted by individuals and organizations. Contributed data can be attributed to companies/organizations or kept pseudo-anonymous. Data sources also include bug bounty programs, security consultancies, and vendors. Contributors provide details of the time period for the data, the total number of web applications, and the list of common weakness enumerations (CWEs) as defined by MITRE. Contributors must also provide the number of applications containing each core CWE.
During analysis, OWASP finds the number of applications with one or more instances of a CWE. The incidence rate is calculated by totaling all the applications that were tested and then comparing that number to the total number of applications where a CWE occurred. The top ten results are then ranked based on additional input from the accompanying survey of application and security experts. Analysis focuses on the root cause of vulnerabilities above the symptom whenever possible.
The OWASP Top 10 for 2021 contained more application data than any previous report the foundation had put out. A record 500,000 applications were submitted. The 2021 list was also the most data-driven version. The data volume required a shift in how the project categorized vulnerabilities.
New vulnerability categories
These new categories were created to highlight trends in application data and to provide additional training benefits for companies that focus on specific CWEs related to the programming languages or frameworks they actively use.
- Insecure design: This category contains risks related to design and infrastructure flaws. Differentiated from other vulnerabilities, insecure design cannot be fixed through proper implementation.
- Software and data entry failures: This category includes risks related to accepting software updates without verifying integrity. This vulnerability focuses on the assumption these updates can always be trusted.
- Server-side request forgery (SSRF): Risks related to URL fetching from one application to another, at the user’s request, without verifying the URL’s integrity are grouped under this category. This server-side vulnerability is considered risky because forged requests can bypass security measures such as firewalls, VPNs, or other access controls.
OWASP Top 10 application vulnerabilities 2022
1. Broken access control
Access control limits what users can access, restricting them to resources within their assigned permissions. Access control failure commonly results in users performing business functions that require different permissions than they were assigned, among other activities. Failure also leads to unauthorized information disclosure, modification, or data destruction.
Access control vulnerabilities include:
- Violating the principle of least privilege by giving all users access to resources intended for specific roles, users, or permissions groups.
- Bypassing access control checks through URL modification, internal application state modification, or HTML page modification. An API attack tool can also be used to bypass access control checks.
- Missing API access controls for PUT, POST, or DELETE.
- Elevation of privilege, where an attacker has access as a user without logging in or can perform admin-level functions from a lower-privilege user account.
Limit access to resources with access control. Access control works in a trusted server environment where data cannot be modified by the attacker. Protection methods include:
- Access should be denied by default, unless the item is a public resource.
- Reuse access control mechanisms throughout the application
- Enforce application business limits
- Disable directory listings for web servers
- Rate-limit API and controller access
2. Cryptographic failures
Cryptographic failures are a broad symptom of a breakdown or deficiency in cryptography, which can lead to system compromise or sensitive data exposure. Personally identifiable data and credit card numbers are among the data types that require extra protection. Data protection methods are determined by the type of data and whether or not it is subject to data privacy laws such as the EU General Data Protection Regulation (GDPR).
Cryptographic failures include:
- Unenforced encryption in the browser where HTTP security headers are missing.
- Invalid server certificate trust chain.
- Data transmitted in clear text over browser protocols such as FTP, SMTP, and HTTP.
- Deploying weak cryptographic algorithms and protocols; ignoring weak cryptographic algorithms in legacy code.
Preventing cryptographic failure depends on application functionality and the type of data used. There are a wide range of aspects to protecting data appropriately. Prevention includes the following (and much more which is covered in OWASP reference guides):
- Classify data that an application has processed, transmitted, or stored. Classify sensitive data according to applicable privacy laws, business requirements, or regulatory obligations.
- Store only the data needed, then discard once the action is completed.
- Encrypt all data during transmission and at rest.
- Avoid using legacy protocols to transport sensitive data.
Injection vulnerabilities can be detected through source-code review. This category includes cross-site scripting, SQL injection, and XML injection among many others. Automation can help here by making sure all parameters and data inputs are tested to identify vulnerabilities.
Applications are vulnerable to injection when:
- User-entered data is accepted without validation, sanitization, or filtering.
- Hostile data is used to extract sensitive information.
Keeping queries and commands separate from data is critical to preventing attempts at injection:
- Ensure that escape syntax includes special characters for the interpreter being used.
- Use query controls to prevent unexpected input from performing unauthorized actions.
- Use prepared statements with parameterized queries through a safe API, separate from the interpreter.
4. Insecure design
Insecure design differs from insecure implementation. A secure design can be implemented imperfectly resulting in vulnerabilities. Insecure design can’t be fixed through implementation since the design itself doesn’t contain appropriate security controls. A failure to accurately assess business risk associated with the software or system under development leads to insufficient levels of security.
A culture of security includes using a secure design methodology that evaluates threats and ensures code is designed and tested against known attack methods. Prevention includes methods that foster a secure development culture:
- Partner with application security professions to help evaluate and design controls around privacy and security. Use a secure development lifecycle.
- Components should be ready to use and design patterns that are secure.
- Apply threat modeling against access controls, key data flows, business logic, and critical authentication.
5. Security misconfiguration
Security misconfigurations can be caused by an array of inappropriately configured controls as well as other factors which contribute to application vulnerability. This category includes many common misconfigurations:
- Misconfigured permissions for cloud services.
- Enabling unnecessary features, which may lead to needless opened ports, services, or incorrectly elevated privileges.
- Unchanged default account login credentials.
Prevention begins with a thorough security configuration process that is repeatable across systems and preferably automated:
- Establish a repeatable security hardening process, ideally through automation, to ensure new environments are secured appropriately with every deployment.
- Use only what is needed. Uninstall or remove unneeded features and components.
- Deploy an automated process to review security settings across environments.
White paper: Cloud security risks in 2022, where we stand?
6. Vulnerable and outdated components
Unpatched and legacy components that remain in production well after vulnerabilities are discovered and disclosed can be a major risk. Applications can be vulnerable when they aren’t running the latest software version. If it’s unclear which library or component version is being used, the application may be vulnerable. Components that aren’t scanned for vulnerabilities may also be at risk.
Establishing a patch-management process can help alleviate the potential for attack by closing vulnerabilities before they become an issue. This should include:
- Removal of unused or unnecessary libraries, components, frameworks, documentation, and files.
- Continual monitoring and inventory of server-side and client-side components.
- Use of only official libraries and sources through secure links.
- Monitoring for unsupported libraries and components that are no longer maintained or have reached end of life.
7. Identification and authentication failures
Authentication and identification failures happen when user identity, authentication, and session information aren’t confirmed before the user is permitted to access systems and data. Factors that may put an application at risk due to these failures include allowing weak passwords; using weakly hashed, plain-text password data stores; and allowing bots, which can perform automated attacks such brute-force and credential stuffing.
Prevention focuses on providing secure password storage and retrieval and includes:
- Implementing multi-factor authentication.
- Avoiding deployment using default credentials, especially for administrative accounts.
- Limit exposure to account enumeration.
8. Software and data integrity failures
New to the OWASP list is the CWE of failures in software and data integrity. The risk here is trusting data and software updates without checking their integrity. Attackers have used the software supply chain to issue malware through seemingly legitimate software updates. Many systems use automated software update features that do not verify the integrity of updates.
Prevention begins with verification and includes:
- Using digital signatures or other verification methods to digitally sign software updates to ensure they’ve come from expected sources and have arrived intact.
- Verifying that third-party libraries and other dependencies originate from legitimate sources.
- Verifying that third-party resources contain no vulnerabilities by using automated security tools designed for the software supply chain.
9. Security logging and monitoring failures
The security logging and monitoring failures category focuses on issues with audit logs and monitoring during an attack. Security monitoring and logs are essential to detect and mitigate an active breach. Failures happen when:
- Logging doesn’t keep track of transactions with high value, login attempts, and failed login attempts.
- Errors and warnings generate unclear, inadequate, or no log entries.
- APIs and applications aren’t monitored for suspicious activities.
- Security logs are only available locally.
- Applications that can neither detect nor issue timely alerts for attacks in progress.
Prevention focuses on enabling security logging and monitoring across applications. Developers should ensure security controls are implemented where appropriate. Security controls should include the following:
- Login, access control, and server-side validation failures should be logged with user context to ensure malicious and suspicious activity can be preserved long enough to allow for analysis.
- Logs should be generated in an appropriate format for log management tools to read.
- Enable monitoring and alerting for suspicious activities.
- Adopt an incident response and mitigation plan.
10. Server-side request forgery (SSRF)
The server-side request forgery category focuses on weaknesses within user-convenience features. SSRF flaws happen when web applications fetch user-requested remote sources without verifying the destination first. Specific requests can be sent to the application through the unexpected source.
Applications commonly fetch URLs to enable easier task-switching for end-users, often keeping them in the application while providing access to another feature through the fetched URL. Ever-increasing cloud architecture complexity means SSRF is occurring at a higher frequency.
SSRF occurs at the network and application levels. Protect networks by using network segmentation to separate remote resources. Block other, nonessential traffic with “deny-by-default” policies.
Application protection methods should include:
- Data input sanitization, validation, and filtering.
- Disabling HTTP redirection at the server level
- Ensuring server responses received conform to expected results. Raw responses from the server should never be sent to the client.
How to protect against application security vulnerabilities
Traditionally, security is difficult to incorporate into development processes. If DevSecOps isn’t an option for the organization or development process/stage, security tools can help surface issues early so they can be addressed.
Design with security in mind. Security contributes to an application’s overall security success since securely designed apps prevent attackers from wreaking havoc, ensure compliance requirements are met, and help build consumer trust.
White paper: Secure coding best practices you should know about
Application security best practices focus on controlling who has access to information and systems while also accounting for secure data storage and transmission. Application logs provide historical records of system and network activity.
- Authentication: The authentication method must be robust and reliable. Passwords, multi-factor authentication (MFA), and PIN codes are examples of authentication methods. Verification of login activity must be strong enough to prevent verification bypass.
- Authorization: Users and systems don’t require the same access, nor should they, since they will have different needs. Following the principle of least privilege helps when there are tasks that require data to be accessed. Use role-based policies to set boundaries on who can perform which type of task.
- Encryption: Encrypting data at rest and during transmission is essential to protecting assets. Secured data should be accessible to protect its integrity.
- Log files: Maintaining essential system and network level logs is critical to ensure historical data is preserved for security incident investigation. Logs can reveal weaknesses that can be addressed to harden application security.
- Monitoring, vulnerability awareness, and alerts: As applications evolve through rapid development cycles, they require continuous monitoring to ensure vulnerabilities and other security issues are addressed. Vulnerabilities can change from version to version, so it’s important for development teams to understand the current threat landscape and any vulnerabilities within the code libraries and third-party resources they’re using.
Development and security teams should also review the latest security vulnerability alerts on a regular basis. The National Institute of Standards and Technology (NIST) maintains the public National Vulnerability Database. The MITRE Corporation maintains a public CVE data feed.
- Vulnerability-based application security scanning: Vulnerability scanning can identify application security weaknesses early on for faster remediation. Security vulnerability scanning tools can prioritize vulnerabilities by security, application type (customer-defined), asset importance, vulnerability popularity, disclosure date, and time to remediate. Prioritizing vulnerabilities by severity helps development teams focus on high-priority vulnerabilities.
Balancing security against tight deadlines can be challenging, especially in today’s fast-paced development environments. Application security is an ongoing process that requires deliberate action to achieve. The OWASP Top 10 2022 is an invaluable resource of known and possible vulnerabilities for development teams looking to create secure web applications.
It’s important to prioritize application vulnerabilities against business impact in addition to other aspects of the overall threat profile. The OWASP Top 10 can help you identify where to strengthen, but making sure that happens is up to you.
Find the threats that matter to your business application environments. The Vulcan Cyber® risk management platform helps you make informed decisions so you can own your risk. Find out more about our application security programs or request a free demo.
What does OWASP stand for?
OWASP stands for the Open Web Application Security Project. It is a nonprofit organization that works to improve the security of software and web applications. OWASP provides resources, tools, and guidelines for developers, security professionals, and organizations to help them build and maintain secure applications.
In which year did the OWASP Top 10 begin?
How often is OWASP Top 10 updated?
Every three to four years.
Why was OWASP created?
OWASP (Open Web Application Security Project) was created to improve the security of software and web applications. The project was founded in 2001 by a group of like-minded individuals who recognized the need for a collaborative effort to address the growing security threats facing web applications.
At the time, there was little emphasis on security during the software development process, and most security measures were implemented after the application had been deployed. The founders of OWASP believed that this reactive approach to security was insufficient and that security should be integrated into the software development process from the beginning.
OWASP was established as a non-profit organization to provide developers, security professionals, and organizations with resources, tools, and guidelines to help them build and maintain secure applications. The organization has since grown to become a global community of professionals and volunteers who work together to promote best practices, education, and awareness in the field of web application security.