Blog
Cybersecurity
What are the OWASP Top 10?
BlogBreachesResourcesNews
Cybersecurity

What are the OWASP Top 10?

Abi Tyas Tunggal
Abi Tyas Tunggal
updated Sep 16, 2024
updated
Download the PDF guide
Free trial
Contents

Download Now

The OWASP Top 10 is a regularly-updated report outlining the top 10 list of security concerns for web application security. 

The report is put together by a team of security experts around the world. OWASP refers to the Top 10 as an 'awareness document' and they recommend all companies incorporate the report's findings into the cybersecurity processes. 

What is OWASP?

The Open Web Application Security Project (OWASP) is an international non-profit organization dedicated to improving web application security. 

OWASP produces freely-available articles, methodologies, documentation, tools, and technologies, making it possible for anyone to improve their web application security. 

The OWASP Top 10 is one of their most well-known projects.

What are the Top 10 Web Application Security Risks?

1. Injection

Injection attacks happen when unvalidated or untrusted data is sent to a code interpreter through form input or another data submission field to a web application.

Successful injection attacks can result in data leaks, data corruption, data breaches, loss of accountability, and denial of access.

Almost any source of data can be an injection vector including environment variables, parameters, external and internal web services, and all types of users.

For example, an attacker could inject SQL code into a form that expects a plain text username. If the web application developer has not properly sanitized the input, it could result in the SQL code being executed. This is known as an SQL injection attack. 

SQL injection is not the only injection flaw. Common vulnerabilities include XPath, NoSQL, LDAP injections, as well as OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. 

In general, an application is vulnerable if:

  • User input is not validated, filtered or sanitized
  • Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter
  • Hostile data is used within object-relational mapping (ORM) search parameters to extract sensitive records
  • Hostile data is directly used or concatenated, such that the SQL or command contains the structure and hostile data in dynamic queries, commands or stored procedures 

To prevent injection attacks, user input should be validated and/or sanitized, and where possible use an API that avoids the use of the interpreter entirely. 

For server-side input, whitelist input validation, and use LIMIT and other SQL controls within queries to minimize the amount of sensitive data that can be exposed.

To learn more about preventing injection attacks, OWASP recommends:

2. Broken Authentication

Authentication systems are some of the most poorly designed and/or implemented systems on many web applications. Additionally, session management is the foundation of any authentication and access control system and is present in all stateful applications. 

These vulnerabilities can be detected by an attacker using manual means and exploited using automated tools, brute force attacks, and dictionary attack tools. Read our full post on brute force attacks here.

The success rate of these attacks can be high. Hundreds of millions of username and password combinations have been exposed in large data breaches. And many people reuse passwords across services or don't bother to change the default administrative login credentials. 

Additionally, session management attacks, like cookie hijacking, are well understood and easily exploitable. 

OWASP states that a web application has poor authentication if it:

  • Permits automated attacks, e.g. credential stuffing
  • Permits brute force or other automated attacks
  • Permits default, weak or well-known passwords (read our password security checklist)
  • Uses weak or ineffective credential recovery or forgot password flows, that rely on knowledge-based answers that can be exposed on social media 
  • Uses plain text, unencrypted or weakly hashed passwords
  • Has missing or ineffective multi-factor authentication (e.g. no 2FA and biometrics) 
  • Exposes Session IDs in the URL
  • Does not rotate Session IDs after login
  • Does not properly invalidate session tokens

There are a number of ways to prevent cyber attacks that exploit poor or broken authentication, including:

  • Multi-factor authentication that prevents automated credential stuffing, brute force, and stolen credential re-use attacks
  • Never using default credentials
  • Weak password checks that disallow the top 10,000 worst passwords and ones exposed in known data breaches
  • Aligning password length, complexity, and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets
  • Ensuring registration, credential recovery, and API pathways are hardened against enumeration attacks by returning the same message for all outcomes
  • Limiting and/or increasing the delay for failed login attempts
  • Logging all login failures and alerting your security team when credential stuffing, brute force or other attacks are detected
  • Using server-side, secure, built-in session management that generates a new, random Session ID with high entropy after login
  • Not exposing Session IDs in the URL
  • Invalidating user sessions on logout, idle, and absolute timeouts

To learn more about preventing broken authentication attacks, OWASP recommends:

3. Sensitive Data Exposure

Many web applications and their APIs don't sufficiently protect sensitive data, such as financials, PHI, and PII. 

This means rather than attacking the cipher directly, attackers may steal keys, execute man-in-the-middle attacks or steal clear text data from the server, while in transit, from the victim's browser, and increasingly, from a third-party vendor who has poor information security. 

As organizations store and process more sensitive data and worldwide data protection laws are introduced, this becomes a larger cybersecurity risk for any web application. With the most common mistake simply not encrypting data at all. 

When encryption is employed, weak key generation and management, weak algorithm, protocol, and cipher usage are common, particularly weak password hashing storage techniques. 

Failure to protect sensitive data can result in industrial espionage, reputational damage, financial cost, and increasingly, regulatory action. Driven by new laws and regulations, such as GDPR, LGPD, CCPA, PIPEDA, HIPAA, and CPS 234 that require the protection of PII, PHI and other sensitive information.

Once exposed, credit card numbers, health records, personal information, and trade secrets and result in fraud, identity theft, loss of market position, and cybercrime.

To prevent sensitive data exposure, OWASP recommends:

  • Classifying data processed, stored or transmitted into sensitivity buckets based on laws, regulations, and business needs
  • Applying controls adequate for the data classification
  • Not storing sensitive data unless necessary
  • Encrypting sensitive data at rest
  • Ensuring encryption algorithms are up-to-date and strong
  • Using proper key management
  • Encrypting data in transit with secure protocols (e.g. TLS)
  • Enforcing encryption through HTTP Strict Transport Security (HSTS)
  • Not caching sensitive data
  • Storing passwords using strong, adaptive, and salted hashing functions e.g. Argon2, scrypt, bcrypt or PBKDF2.
  • Verifying the effectiveness of configuration and settings

UpGuard BreachSight can help you detect leaked credentials and exposed data before it falls into the wrong hands. We were able to detect data exposed in a GitHub repository by an AWS engineer in 30 minutes. We were able to do this because we actively discover exposed datasets on the open and deep web, scouring S3 buckets, public GitHub repos, and unsecured RSync and FTP servers.

To learn more about preventing sensitive data exposures, OWASP recommends:

4. XML External Entities (XXE)

Attackers can exploit vulnerable Extensible Markup Language (XML) processors that upload XML or include hostile content in an XML document. 

This is because many old XML processors allow the specification of an external entity, e.g. a hard drive.  

This means that, like injection attacks, XML parsers can be coerced into sending data to an unauthorized external entity, which then passes the sensitive data directly to an attacker. 

These flaws can also be used to execute remote requests from the server, scan internal systems, and perform denial-of-service attacks.

To prevent XXE attacks: 

  • Use simple data formats (like JSON) and avoid serialization of sensitive data
  • Patch or upgrade all XML processors and libraries in use
  • Disable XML external entity and DTD processing in XML parsers
  • Whitelist server-side input
  • Validate, filter or sanitize input to prevent hostile data within XML documents, headers, and nodes
  • Verify that XML and XSL upload functionality validates incoming XML using XSD validation or something similar 
  • Manually review code and use SAST tools to help detect XXEs in source code. 

To learn more about preventing XXE attacks, OWASP recommends:

5. Broken Access Control

Access control refers to the systems that control access to information or functionality. 

Poor access control implementation allows attackers to bypass authorization or perform tasks as though they are privileged users. 

For example, a web application may allow a user to change which account they are logged into by changing part of the URL, without any additional verification. 

Common access control security vulnerabilities include:

  • Bypassing access control checks by modifying the URL, internal application state, HTML of the web page, or by using a custom API attack tool 
  • Allowing the primary key to be changed to another user record, permitting viewing or editing of another user's account
  • Privilege escalation attacks that impersonate a user or allow a user to impersonate an admin
  • Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT), access control token, cookie, or hidden field
  • CORS misconfiguration that allows unauthorized API access
  • Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user

To prevent access control access, ensure that access control checks and metadata cannot be modified by:

  • Denying access by default (the principle of least privilege)
  • Implementing access control mechanisms once and reusing them across the application
  • Enforcing record ownership rather than accepting users can create, read, update or delete any record
  • Disabling web server directory listing
  • Ensuring metadata and backup files are not present within web roots
  • Logging access control failures and alerting the security team where necessary
  • Rate limiting APIs and controller access to minimize the impact of automated attacks
  • Invalidating JWT tokens on logout

To learn more about preventing access control exploits, OWASP recommends:

6. Security Misconfiguration

Attackers can exploit unpatched application vulnerabilities or access default accounts, unused pages, unprotected and directories to gain unauthorized access to or gather information on a system. 

Misconfiguration can happen at any level of an application stack including network services, platform, web server, application server, database, frameworks, custom code, pre-installed virtual machines, containers, and storage. 

To prevent misconfiguration:

  • Implement an automated configuration management policy
  • Run a repeatable hardening process that makes it easy to deploy another secure environment. See our Windows Server Hardening Checklist
  • Use a minimal platform without unnecessary features, components, documentation, and samples
  • Implement vulnerability management processes
  • Segment application architecture to separate components or tenants with segmentation, containerization or cloud security groups 

Misconfiguration doesn't end with your organization. Use UpGuard Vendor Risk to send security questionnaires to third-parties and your security ratings to automatically detect first, third and fourth-party configuration issues and vulnerabilities. 

To learn more about preventing misconfiguration, OWASP recommends:

7. Cross-Site Scripting (XSS)

Cross-site scripting (XSS) occurs when web applications allow users to add custom code to a URL path or a website that will be seen by other users. 

These vulnerabilities can be exploited to run malicious JavaScript on the victim's browser. 

For example, an attacker could send a phishing email to a victim that appears to be from their bank, with a link to the bank's legitimate website.  

If the bank doesn't prevent cross-site scripting, the attacker could add malicious JavaScript to the end of the URL, and run it when the link is clicked.  

Attackers can also use XSS to stop any automated Cross-Site Request Forgery (CSRF) defenses.

To prevent cross-site scripting:

  • Use modern frameworks that escape XSS by design, such as Ruby on Rails or React
  • Learn the limitations of a framework's XSS protection and appropriately handle the exceptions 
  • Escape untrusted HTTP requests 
  • Validate, filter or sanitize user-generated content
  • Use a Content Security Policy (CSP) as a defense-in-depth control

To learn more about preventing XSS, OWASP recommends:

8. Insecure Deserialization

This web security risk targets web applications that frequently serialize and deserialize data.

Serialization is the process of translating data structures or object states into a format that can be stored or transmitted, then reconstructed later.

Deserialization is the opposite, converting serialized data into objects the application can use. 

When data from an untrusted source is deserialized it can result in DDoS attacks and remote code execution. 

To prevent insecure deserialization:

  • Implement integrity checks, such as digital signatures, on any serialized objects to prevent object creation and data tampering
  • Enforce strict type constraints during deserialization and before object creation 
  • Isolate and run deserialization code in low privilege environments
  • Log exceptions and failures, such as when the incoming type is not the expected type or when an exception is thrown
  • Restrict and monitor incoming and outgoing network traffic from containers or servers that deserialize
  • Monitor deserialization and alert DevOps if a user deserializes constantly 

To learn how to prevent insecure deserialization, OWASP recommends:

9. Using Components with Known Vulnerabilities

The use of libraries and frameworks is on the rise, which can introduce vulnerable components that attackers can exploit. 

These components speed up software development, helping developers avoid redundant work and providing needed functionality. 

Common examples include front-end frameworks like React, back-end frameworks like Ruby on Rails, shared icons or A/B testing solutions. 

The most popular components are used by millions of websites, which means if attackers can find security issues in one can leave millions of web applications exposed. 

Component developers issue software security patches and updates to fix or mitigate known vulnerabilities (like those listed on CVE), but developers don't always install patches or use the most recent version of components. 

To minimize this risk, developers should remove unused components and ensure they are receiving components from a trusted source as malicious sites may post as open source projects to spread malware.

To prevent known vulnerabilities, OWASP recommends:

10. Insufficient Logging & Monitoring

Many web applications do not take the necessary steps to detect data breaches. In fact, the average discovery time for breach discovery was 206 days in 2019.

This can give attackers a long time to cause damage before incident response plans can kick in.

OWASP recommends that applications:

  • Ensure all login, access control failures, and server-side input validation failures are logged with sufficient context to identify suspicious or malicious accounts and held for sufficient time to allow for delayed forensic analysis
  • Have logs generated in a format that can be easily consumed by a centralized log management solution
  • Have an audit trail for high-value transactions with integrity controls to prevent tampering or deletion, such as append-only database tables
  • Have effective monitoring and alerting so suspicious activity can be detected and responded to in a timely manner
  • Establish an incident response plan and disaster recovery plan as outlined in NIST 700-61 rev 2

For further reading, OWASP recommends:

How UpGuard Can Reduce Web Risks

UpGuard Vendor Risk can minimize the amount of time your organization spends assessing related and third-party information security controls by automating vendor questionnaires and providing vendor questionnaire templates.

We can help you continuously monitor your vendors' external security controls and provide an unbiased security rating based on the analysis of 70+ attack vectors including:

Reviewed by
Kaushik Sen
Kaushik Sen
Chief Marketing Officer

Ready to see
UpGuard in action?

Free trial

Ready to save time and streamline your trust management process?

Get started
Tags:
Cybersecurity
Attack Surface Management
Author
Abi Tyas Tunggal
Abi Tyas Tunggal
Reviewed by
Kaushik Sen
Kaushik Sen
Join 27,000+ cybersecurity newsletter subscribers

Download Now
UpGuard logo
UpGuard is a complete third-party risk and attack surface management platform.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Contact sales
Free trial
Products
Tools
Company
Insights
Products
Compare
Solutions
Company
Insights
© UpGuard, Inc.
Research GuidelinesPlatform Terms & ConditionsWebsite Terms & ConditionsPrivacyCookies