OWASP Top 10 Vulnerabilities and Security Risks
The OWASP Top 10 is a list of the ten most common web application security risks. By performing robust application testing and writing code with these risks, software developers can create secure applications that keep their user’s confidential information safe from attackers.
Table of contents:
- What is OWASP?
- What is the OWASP Top 10?
- Meeting Open Web Application Security Project (OWASP) compliance to ensure secure coding.
- OWASP Top 10 security vulnerabilities
What is OWASP?
Open Web Application Security Project, or OWASP, is a nonprofit organization focused on software security. Their projects include several open source software development programs, methodologies and toolkits, conferences, and local chapters, among other things. One of the OWASP projects is the maintenance of the OWASP Top 10.
What is the OWASP Top 10?
The OWASP Top 10 is a frequently-updated report outlining security concerns for web application security, concentrating on the 10 most critical risks. The report is compiled by a team of security experts globally. OWASP refers to the Top 10 security risks list as an awareness document, and they recommend that all businesses include the report in their processes to reduce or mitigate critical security risks.
Meeting Open Web Application Security Project (OWASP) compliance to ensure secure coding
The OWASP Top Ten is a great foundational resource when developing a secure code. According to statistics, almost 68-percent of apps have a security flaw that falls into the OWASPs Top ten.
The OWASP Top 10 is not just a list. It evaluates every flaw class deploying the OWASP Risk Rating Methodology and offers guidelines, best practices for preventing attacks, examples, and references for every risk. By learning the vulnerabilities on the OWASP Top 10 chart and how to solve them, application developers can take concrete steps towards a more secure application that keeps users safe when it comes to malicious attacks.
Of course, the security vulnerabilities listed by OWASP are not the only things developers need to consider.
OWASP Top 10 security vulnerabilities
OWASP shared the latest Top 10, where there are four categories with naming and scoping changes, three new categories, and some consolidation with the Top 10. Here are the top 10 security risks.
Broken authentication vulnerability (identification and authentication failures)
Among the OWASP top ten critical vulnerabilities is the broken authentication vulnerabilities where applications incorrectly execute functions related to session management; attackers and hackers exploit to impersonate a legitimate user online. This category has been renamed to identification and authentication failures to include CWEs that are more related to identification failures.
Attackers use different means to take advantage of this risk, ranging from credential stuffing to some other highly targeted ways of gaining unauthorised access to someone’s credentials. Following OWASP, this form of security vulnerability can come in various ways.
Injection
An injection attack happens when untrusted data is sent to a code interpreter via a form input or other data submission to a web application. For instance, an attacker could enter SQL database code into a form that anticipates a plaintext username. If that form input is not properly secured, this can lead to that SQL code being executed. This is called an SQL injection attack. Examples of injection include:
- LDAP injections
- CRLF injections
- Command injections
Application security testing can divulge injection flaws and suggest remediation approaches or writing parameterized SQL queries, or stripping special characters from user input.
Injection vulnerabilities can be mitigated by validating/ or sanitizing user-submitted data. (Validation indicates rejecting suspicious-looking data, while sanitization denotes cleaning up the suspicious-looking parts of the information). Additionally, a database admin can set controls to reduce the amount of information injection attacks expose.
Cryptographic failures, formerly known as sensitive data exposure
APIs, which enable developers to connect their software to third-party services such as Google Maps, are great time-savers. However, some APIs depend on insecure data transmission methods, which hackers can exploit to access passwords, credit cards, usernames, and other sensitive information.
Proper key management, tokenization, data encryption, encrypting all sensitive data at rest using strong encryption algorithms, and disabling response caching can help lower the risk of sensitive data exposures/ a02:2021-cryptographic failure.
Insufficient logging and monitoring
Poor monitoring practices or failing to log attacks or errors can introduce a human element to security risks. Threat actors bank on a lack of monitoring and slower remediation times so they can attack before you have time to react or notice. This category has been expanded to include more types of failures, including those that are not well represented in the CVE/CVSS data. Failures in this section affect visibility, alerting, and forensics.
To prevent security logging and monitoring failures, ensure that server-side input validation failures and access control failures are logged with context so that you can recognize suspicious activity. Penetration testing is a great method of finding areas of your application with insufficient logging. Establishing effective monitoring practices is also vital.
A01:2021-Broken access control
During the OWASP Top 10 list update, broken access control moved up from the fifth position; 94-percent of applications were tested for broken access control. The 34 common weakness enumerations (CWEs) mapped to broken access control had more occurrences in applications than any other category.
Insecure access control practices and configuration errors are hard to detect since automated processes cannot always test for them. Penetration testing can reveal missing authentication, but other methods must be deployed to determine configuration problems. Issues with credentials management and weak controls are preventable with a secure code and preventative measures such as locking down administrative accounts and controls and deploying multi-factor authentication.
It is worth noting that a broken access control attack redirects browsers to other targeted URLs
Security misconfiguration
Security misconfigurations moved up from number six in the previous edition; 90-percent of applications were tested for some form of misconfiguration, including:
- Storage
- Containers
- Pre-installed virtual machines
- Custom code
- Frameworks
- Database
- Application server
- Webserver
- Platform
- Network services
Generally, misconfiguration can happen at any level of an application stack. An application can be vulnerable to misconfiguration if the cloud services permissions are not configured well. The former XML External Entities (XXE) category is now part of this vulnerability.
Many numerous misconfigurations expose the organization to cybersecurity risk. Some of the common vulnerabilities include:
- Verbose error messages that comprise sensitive information
- Misconfigured HTTP headers
- Incomplete configurations
- Overly accessible cloud storage resources
- Accepting insecure default settings
Dynamic testing can assist you in discovering misconfigured security in your software application. Additionally, you should remove unused features, unnecessary features, unused dependencies, files and any vulnerable components.
a04:2021-Insecure design
Insecure design is a new edition for 2021, focusing on application vulnerabilities related to design flaws. Some applications have a secure design but have implementation flaws that lead to exploitable security flaws. If application development genuinely wants to move to the justify, it calls for more use of threat modeling, reference architectures and secure design patterns. To prevent insecure design, integrate plausibility checks into your application at each level (from frontend to backend).
Vulnerable and outdated components
The vulnerable and outdated components edition was previously titled using components with known security issues. It is now the second position in the Top community survey and also has enough data to make the Top 10 through data analysis. This edition moved from #9 in the previous edition and is a known issue that developers struggle to test and assess risk. Vulnerability and outdated components are the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so default exploits and potential impact weights of 5.0 are factored into their scores.
Insecure deserialization
Deserialization, or retrieving objects and data that have been written to disks or saved, can be deployed to remotely execute code in your software program or as a window to further attacks. The composition that an object is serialized into is either structured or binary text via common serialization systems such as XML and JSON. This flaw happens when an attacker deploys untrusted data to manipulate an application, initiates a denial of service (DoS) attack, or executes unpredictable code to change the behavior of the software application.
Even though deserialization is hard to exploit, penetration testing or application security tools can lower the risk further. You can also implement integrity checks like digital signatures on serialized objects to prevent hostile object creation or data tampering.
According to WASP, the Top 10 insecure deserialization was added by an industry survey and not based on quantifiable data research.
Software and data integrity failures
This year, the new category, Software and Data Integrity Failures, refer to code and infrastructure that fails to protect against integrity violations. This includes critical data, software updates, and CI/CD pipelines adopted without verification. An example of this includes data or objects encoded or serialized into a structure that a hacker can modify. Another example is an application that depends upon libraries, plugins, or modules from untrusted sources. Insecure CI/CD pipelines that can introduce the potential for malicious code, unauthorized access, or system compromise also fit into this category.
To prevent data integrity failures, ensure dependencies and libraries such as maven or npm are pulled from trusted repositories.
a10:2021-Server-side request forgery (ssrf)
Serverside Request Forgery denotes data that shows a relatively low incidence rate with above average testing coverage and above-average ratings for Exploit and Impact potential. A server-side request forgery fault occurs when a web application fetches a remote resource without validating the user-supplied URL. Even if the program is secured by VPN, a firewall, or a network access control list, a hacker can force it to send a forged request to an expected location.
Cross-site scripting (XSS)
With cross site scripting, attackers take advantage of DOM and APIs manipulation to send commands or retrieve data from your application. Cross-site scripting broadens the attack surface for threat actors, allowing them to get access to user accounts, spread Trojans and worms, access browser histories, control browsers remotely, and more.It is another user data validation error that enables injecting JavaScript to the user’s browser for execution.
Training application security experts and application security professionals in best practices like data encoding and input validation lower the possibility of this threat. Sanitize your data/information by validating that it is the content you anticipate for that field and by encoding data for the endpoint as an extra layer of protection.
Types of XSS
According to OWASP Top 10, there are three types of cross-site scripting.
| XXS Type | Client | Server |
| Stored | Stored client | Stored server |
| Reflected | Reflected client | Reflected server |
| DOM-based | Subset of client |
Using components with known vulnerabilities
Regardless of how secure your own code is, attackers can exploit APIs, dependencies and other third-party components if they are not themselves secure. A static analysis along with a software composition analysis can locate and help neutralize insecure components in your software. Veracode’s static code analysis tools can assist developers in finding secure components in their code before publishing an application. Also, obtain components only from official sources.
XML external entities
This risk happens when attackers can upload or include hostile XML content because of insecure code, dependencies, or integrations. An SCA scan can expose risks in third-party components with a known security weakness and will warn you about them. Disabling XML external entity processing also lowers the probability of an XML entity attack. To prevent XML, use a very good SAST functionality that can help detect XXE in your source code.
Comprehensive AppSec Guides and Services
Veracode provides comprehensive guides for training developers in application security and scalable web-based tools to make developing secure applications simple.
