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?
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.
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 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:
- OWASP Proactive Controls: Parameterize Queries
- OWASP ASVS: V5 Input Validation and Encoding
- OWASP Testing Guide: SQL Injection, Command Injection, and ORM Injection
- OWASP Cheat Sheet: Injection Prevention
- OWASP Cheat Sheet: SQL Injection Prevention
- OWASP Cheat Sheet: Injection Prevention in Java
- OWASP Cheat Sheet: Query Parameterization
- OWASP Automated Threats to Web Applications – OAT-014
- CWE-77: Command Injection
- CWE-89: SQL Injection
- CWE-564: Hibernate Injection
- CWE-917: Expression Language Injection
- PortSwigger: Server-side template injection
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:
- OWASP Proactive Controls: Implement Identity and Authentication Controls
- OWASP Application Security Verification Standard: V2 Authentication
- OWASP Application Security Verification Standard: V3 Session Management
- OWASP Testing Guide: Identity, Authentication
- OWASP Cheat Sheet: Authentication
- OWASP Cheat Sheet: Credential Stuffing
- OWASP Cheat Sheet: Forgot Password
- OWASP Cheat Sheet: Session Management
- OWASP Automated Threats Handbook
- NIST 800-63b: 5.1.1 Memorized Secrets
- CWE-287: Improper Authentication
- CWE-384: Session Fixation
3. Sensitive data exposure
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:
- OWASP Proactive Controls: Protect Data
- OWASP Application Security Verification Standard (V7, 9, 10)
- OWASP Cheat Sheet: Transport Layer Protection
- OWASP Cheat Sheet: User Privacy Protection
- OWASP Cheat Sheet: Password and Cryptographic Storage
- OWASP Cheat Sheet: HSTS
- OWASP Testing Guide: Testing for weak cryptography
- CWE-220: Exposure of sens. information through data queries
- CWE-310: Cryptographic Issues
- CWE-311: Missing Encryption
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-319: Cleartext Transmission of Sensitive Information
- CWE-326: Weak Encryption
- CWE-327: Broken/Risky Crypto
- CWE-359: Exposure of Private Information (Privacy Violation)
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:
- OWASP Application Security Verification Standard
- OWASP Testing Guide: Testing for XML Injection
- OWASP XXE Vulnerability
- OWASP Cheat Sheet: XXE Prevention
- OWASP Cheat Sheet: XML Security
- CWE-611: Improper Restriction of XXE
- Billion Laughs Attack
- SAML Security XML External Entity Attack
- Detecting and exploiting XXE in SAML Interfaces
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:
- OWASP Proactive Controls: Access Controls
- OWASP Application Security Verification Standard: V4 Access Control
- OWASP Testing Guide: Authorization Testing
- OWASP Cheat Sheet: Access Control
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
- CWE-284: Improper Access Control (Authorization)
- CWE-285: Improper Authorization
- CWE-639: Authorization Bypass Through User-Controlled KeyPortSwigger: Exploiting CORS misconfiguration
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:
- OWASP Testing Guide: Configuration Management
- OWASP Testing Guide: Testing for Error Codes
- NIST Guide to General Server Hardening
- CWE-2: Environmental Security Flaws
- CWE-16: Configuration
- CWE-388: Error Handling
- CIS Security Configuration Guides/Benchmarks
- Amazon S3 Bucket Discovery and Enumeration
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.
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.
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:
- OWASP Proactive Controls: Encode Data
- OWASP Proactive Controls: Validate Data
- OWASP Application Security Verification Standard: V5
- OWASP Testing Guide: Testing for Reflected XSS
- OWASP Testing Guide: Testing for Stored XSS
- OWASP Testing Guide: Testing for DOM XSS
- OWASP Cheat Sheet: XSS Prevention
- OWASP Cheat Sheet: DOM based XSS Prevention
- OWASP Cheat Sheet: XSS Filter Evasion
- OWASP Java Encoder Project
- CWE-79: Improper neutralization of user supplied input
- PortSwigger: Client-side template injection
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:
- OWASP Cheat Sheet: Deserialization
- OWASP Proactive Controls: Validate All Inputs
- OWASP Application Security Verification Standard
- OWASP AppSecEU 2016: Surviving the Java Deserialization Apocalypse
- OWASP AppSecUSA 2017: Friday the 13th JSON Attacks
- CWE-502: Deserialization of Untrusted Data
- Java Unmarshaller Security
- OWASP AppSec Cali 2015: Marshalling Pickles
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:
- OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling
- OWASP Dependency Check (for Java and .NET libraries)
- OWASP Testing Guide - Map Application Architecture (OTG-INFO-010)
- OWASP Virtual Patching Best Practices
- The Unfortunate Reality of Insecure Libraries
- MITRE Common Vulnerabilities and Exposures (CVE) search
- National Vulnerability Database (NVD)
- Node Libraries Security Advisories
- Ruby Libraries Security Advisory Database and Tools
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:
- OWASP Proactive Controls: Implement Logging and Intrusion Detection
- OWASP Application Security Verification Standard: V8 Logging and Monitoring
- OWASP Testing Guide: Testing for Detailed Error Code
- OWASP Cheat Sheet: Logging
- CWE-223: Omission of Security-relevant Information
- CWE-778: Insufficient Logging
How UpGuard can reduce web risks
Companies like Intercontinental Exchange, Taylor Fry, The New York Stock Exchange, IAG, First State Super, Akamai, Morningstar, and NASA use UpGuard's security ratings to protect their data, prevent data breaches and assess their security posture.
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.
We base our ratings on the analysis of 70+ vectors including:
- Susceptibility to man-in-the-middle attacks
- Insecure SSL/TLS certificates
- SPF, DKIM and DMARC settings
- HTTP Strict Transport Security (HSTS)
- Email spoofing and phishing risk
- Malware susceptibility
- Unnecessary open administration, database, app, email and file sharing ports
- Exposure to known data breaches and data leaks
- Vulnerable software
- HTTP accessibility
- Secure cookie configuration
- Results of intelligent security questionnaires
We can also help you instantly benchmark your current and potential vendors against their industry, so you can see how they stack up.
For the assessment of your information security controls, UpGuard BreachSight can monitor your organization for 70+ security controls providing a simple, easy-to-understand cyber security rating and automatically detect leaked credentials and data exposures in S3 buckets, Rsync servers, GitHub repos and more.
You can read more about what our customers are saying on Gartner reviews.
If you'd like to see your organization's security rating, click here to request your free Cyber Security Rating.