OWASP Top 10 – 2017 The Ten Most Critical Web Application Security Risks
This work is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International Licensehttps://owasp.org
Copyright and License
Copyright © 2003 – 2017 The OWASP Foundation
This document is released under the Creative Commons Attribution Share-Alike 4.0 license.
For any reuse or distribution, you must make it clear to others the license terms of this work.
Table of Contents About OWASP
The Open Web Application Security Project (OWASP) is an
open community dedicated to enabling organizations to
develop, purchase, and maintain applications and APIs that
can be trusted.
At OWASP, you’ll find free and open:
• Application security tools and standards.
• Complete books on application security testing, secure code development, and secure code review.
• Presentations and videos. • Cheat sheets on many common topics. • Standard security controls and libraries. • Local chapters worldwide. • Cutting edge research. • Extensive conferences worldwide. • Mailing lists.
Learn more at: https://www.owasp.org.
All OWASP tools, documents, videos, presentations, and
chapters are free and open to anyone interested in improving
We advocate approaching application security as a people,
process, and technology problem, because the most
effective approaches to application security require
improvements in these areas.
OWASP is a new kind of organization. Our freedom from
commercial pressures allows us to provide unbiased,
practical, and cost-effective information about application
OWASP is not affiliated with any technology company,
although we support the informed use of commercial security
technology. OWASP produces many types of materials in a
collaborative, transparent, and open way.
The OWASP Foundation is the non-profit entity that ensures
the project’s long-term success. Almost everyone associated
with OWASP is a volunteer, including the OWASP board,
chapter leaders, project leaders, and project members.
We support innovative security research with grants and
Come join us!
TOC Table of Contents
TOC – About OWASP ……………………………… 1
FW – Foreword …………..………………………… 2
I – Introduction ………..……………….……..… 3
RN – Release Notes …………..………….…..….. 4
Risk – Application Security Risks…………….…… 5
T10 – OWASP Top 10 Application Security
Risks – 2017 …………..…………..….…… 6
A1:2017 – Injection …….………..……………………… 7
A2:2017 – Broken Authentication ……………………… 8
A3:2017 – Sensitive Data Exposure ………………….. 9
A4:2017 – XML External Entities (XXE) ……………… 10
A5:2017 – Broken Access Control …………………….. 11
A6:2017 – Security Misconfiguration ………………….. 12
A7:2017 – Cross-Site Scripting (XSS) ….…………….. 13
A8:2017 – Insecure Deserialization ……………………14
A9:2017 – Using Components with Known
Vulnerabilities .……………………………… 15
A10:2017 – Insufficient Logging & Monitoring….…..….. 16
+D – What’s Next for Developers ….………..….. 17
+T – What’s Next for Security Testers .……..….. 18
+O – What’s Next for Organizations ……..………. 19
+A – What’s Next for Application Managers …… 20
+R – Note About Risks ……..……………………. 21
+RF – Details About Risk Factors ……………..…. 22
+DAT – Methodology and Data …..………………… 23
+ACK – Acknowledgements ………………..………. 24
Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure. As our software
becomes increasingly complex, and connected, the difficulty of achieving application security increases exponentially. The
rapid pace of modern software development processes makes the most common risks essential to discover and resolve
quickly and accurately. We can no longer afford to tolerate relatively simple security problems like those presented in this
OWASP Top 10.
A great deal of feedback was received during the creation of the OWASP Top 10 – 2017, more than for any other equivalent
OWASP effort. This shows how much passion the community has for the OWASP Top 10, and thus how critical it is for
OWASP to get the Top 10 right for the majority of use cases.
Although the original goal of the OWASP Top 10 project was simply to raise awareness amongst developers and managers,
it has become the de facto application security standard.
In this release, issues and recommendations are written concisely and in a testable way to assist with the adoption of the
OWASP Top 10 in application security programs. We encourage large and high performing organizations to use the OWASP
Application Security Verification Standard (ASVS) if a true standard is required, but for most, the OWASP Top 10 is a great
start on the application security journey.
We have written up a range of suggested next steps for different users of the OWASP Top 10, including What’s Next for
Developers, What’s Next for Security Testers, What’s Next for Organizations, which is suitable for CIOs and CISOs, and
What’s Next for Application Managers, which is suitable for application managers or anyone responsible for the lifecycle of
In the long term, we encourage all software development teams and organizations to create an application security program
that is compatible with your culture and technology. These programs come in all shapes and sizes. Leverage your
organization’s existing strengths to measure and improve your application security program using the Software Assurance
We hope that the OWASP Top 10 is useful to your application security efforts. Please don’t hesitate to contact OWASP with
your questions, comments, and ideas at our GitHub project repository:
You can find the OWASP Top 10 project and translations here:
Lastly, we wish to thank the founding leadership of the OWASP Top 10 project, Dave Wichers and Jeff Williams, for all their
efforts, and believing in us to get this finished with the community’s help. Thank you!
• Andrew van der Stock
• Brian Glas
• Neil Smithline
• Torsten Gigler
Thanks to Autodesk for sponsoring the OWASP Top 10 – 2017.
Organizations and individuals that have provided vulnerability prevalence data or other assistance are listed on the
Welcome to the OWASP Top 10 – 2017!
This major update adds several new issues, including two issues selected by the community – A8:2017-Insecure
Deserialization and A10:2017-Insufficient Logging and Monitoring. Two key differentiators from previous OWASP Top 10
releases are the substantial community feedback and extensive data assembled from dozens of organizations, possibly the
largest amount of data ever assembled in the preparation of an application security standard. This provides us with
confidence that the new OWASP Top 10 addresses the most impactful application security risks currently facing
The OWASP Top 10 – 2017 is based primarily on 40+ data submissions from firms that specialize in application security and
an industry survey that was completed by over 500 individuals. This data spans vulnerabilities gathered from hundreds of
organizations and over 100,000 real-world applications and APIs. The Top 10 items are selected and prioritized according to
this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact.
A primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the
consequences of the most common and most important web application security weaknesses. The Top 10 provides basic
techniques to protect against these high risk problem areas, and provides guidance on where to go from here.
Roadmap for future activities
Don’t stop at 10. There are hundreds of issues that could
affect the overall security of a web application as discussed
in the OWASP Developer’s Guide and the OWASP Cheat
Sheet Series. These are essential reading for anyone
developing web applications and APIs. Guidance on how to
effectively find vulnerabilities in web applications and APIs
is provided in the OWASP Testing Guide.
Constant change. The OWASP Top 10 will continue to
change. Even without changing a single line of your
application’s code, you may become vulnerable as new
flaws are discovered and attack methods are refined.
Please review the advice at the end of the Top 10 in What’s
Next For Developers, Security Testers, Organizations, and
Application Managers for more information.
Think positive. When you’re ready to stop chasing
vulnerabilities and focus on establishing strong application
security controls, the OWASP Proactive Controls project
provides a starting point to help developers build security
into their application and the OWASP Application Security
Verification Standard (ASVS) is a guide for organizations
and application reviewers on what to verify.
Use tools wisely. Security vulnerabilities can be quite
complex and deeply buried in code. In many cases, the
most cost-effective approach for finding and eliminating
these weaknesses is human experts armed with advanced
tools. Relying on tools alone provides a false sense of
security and is not recommended.
Push left, right, and everywhere. Focus on making
security an integral part of your culture throughout your
development organization. Find out more in the OWASP
Software Assurance Maturity Model (SAMM).
We’d like to thank the organizations that contributed their
vulnerability data to support the 2017 update. We received
more than 40 responses to the call for data. For the first
time, all the data contributed to a Top 10 release, and the full
list of contributors is publicly available. We believe this is one
of the larger, more diverse collections of vulnerability data
ever publicly collected.
As there are more contributors than space here, we have
created a dedicated page to recognize the contributions
made. We wish to give heartfelt thanks to these
organizations for being willing to be on the front lines by
publicly sharing vulnerability data from their efforts. We hope
this will continue to grow and encourage more organizations
to do the same and possibly be seen as one of the key
milestones of evidence-based security. The OWASP Top 10 would not be possible without these amazing contributions.
A big thank you to the more than 500 individuals who took
the time to complete the industry ranked survey. Your voice
helped determine two new additions to the Top 10. The
additional comments, notes of encouragement,
and criticisms were all appreciated. We know your time is
valuable and we wanted to say thanks.
We would like to thank those individuals who have
contributed significant constructive comments and time
reviewing this update to the Top 10. As much as possible,
we have listed them on the ‘Acknowledgements’ page.
And finally, we’d like to thank in advance all the translators
out there who will translate this release of the Top 10 into
numerous different languages, helping to make the OWASP
Top 10 more accessible to the entire planet.
What changed from 2013 to 2017? Change has accelerated over the last four years, and the OWASP Top 10 needed to change. We’ve completely refactored the OWASP Top 10, revamped the methodology, utilized a new data call process, worked with the community, re-ordered our risks, re- written each risk from the ground up, and added references to frameworks and languages that are now commonly used.
Over the last few years, the fundamental technology and architecture of applications has changed significantly:
• Microservices written in node.js and Spring Boot are replacing traditional monolithic applications. Microservices come with their own security challenges including establishing trust between microservices, containers, secret management, etc. Old code never expected to be accessible from the Internet is now sitting behind an API or RESTful web service to be consumed by Single Page Applications (SPAs) and mobile applications. Architectural assumptions by the code, such as trusted callers, are no longer valid.
New issues, supported by data:
• A4:2017-XML External Entities (XXE) is a new category primarily supported by source code analysis security testing tools (SAST) data sets.
New issues, supported by the community:
We asked the community to provide insight into two forward looking weakness categories. After over 500 peer submissions, and removing issues that were already supported by data (such as Sensitive Data Exposure and XXE), the two new issues are:
• A8:2017-Insecure Deserialization, which permits remote code execution or sensitive object manipulation on affected platforms.
• A10:2017-Insufficient Logging and Monitoring, the lack of which can prevent or significantly delay malicious activity and breach detection, incident response, and digital forensics.
Merged or retired, but not forgotten:
• A4-Insecure Direct Object References and A7-Missing Function Level Access Control merged into A5:2017-Broken Access Control.
• A8-Cross-Site Request Forgery (CSRF), as many frameworks include CSRF defenses, it was found in only 5% of applications.
• A10-Unvalidated Redirects and Forwards, while found in approximately 8% of applications, it was edged out overall by XXE.
OWASP Top 10 – 2013 OWASP Top 10 – 2017
A1 – Injection A1:2017-Injection
A2 – Broken Authentication and Session Management A2:2017-Broken Authentication
A3 – Cross-Site Scripting (XSS) A3:2017-Sensitive Data Exposure
A4 – Insecure Direct Object References [Merged+A7] ∪ A4:2017-XML External Entities (XXE) [NEW]
A5 – Security Misconfiguration A5:2017-Broken Access Control [Merged]
A6 – Sensitive Data Exposure A6:2017-Security Misconfiguration
A7 – Missing Function Level Access Contr [Merged+A4] ∪ A7:2017-Cross-Site Scripting (XSS)
A8 – Cross-Site Request Forgery (CSRF) A8:2017-Insecure Deserialization [NEW, Community]
A9 – Using Components with Known Vulnerabilities A9:2017-Using Components with Known Vulnerabilities
A10 – Unvalidated Redirects and Forwards A10:2017-Insufficient Logging&Monitoring [NEW,Comm.]
RN Release Notes
What Are Application Security Risks? Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention.
Sometimes these paths are trivial to find and exploit, and sometimes they are extremely difficult. Similarly, the harm that is caused may be of no consequence, or it may put you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine your overall risk.
Risk Application Security Risks
What’s My Risk? The OWASP Top 10 focuses on identifying the most serious web application security risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using the following simple ratings scheme, which is based on the OWASP Risk Rating Methodology.
In this edition, we have updated the risk rating system to assist in calculating the likelihood and impact of any given risk. For more details, please see Note About Risks.
Each organization is unique, and so are the threat actors for that organization, their goals, and the impact of any breach. If a public interest organization uses a content management system (CMS) for public information and a health system uses that same exact CMS for sensitive health records, the threat actors and business impacts can be very different for the same software. It is critical to understand the risk to your organization based on applicable threat agents and business impacts.
Where possible, the names of the risks in the Top 10 are aligned with Common Weakness Enumeration (CWE) weaknesses to promote generally accepted naming conventions and to reduce confusion.
Easy: 3 Widespread: 3 Easy: 3 Severe: 3
Specific Average: 2 Common: 2 Average: 2 Moderate: 2
Difficult: 1 Uncommon: 1 Difficult: 1 Minor: 1
• OWASP Risk Rating Methodology
• Article on Threat/Risk Modeling
• ISO 31000: Risk Management Std
• ISO 27001: ISMS
• NIST Cyber Framework (US)
• ASD Strategic Mitigations (AU)
• NIST CVSS 3.0
• Microsoft Threat Modelling Tool
T10 OWASP Top 10Application Security Risks – 2017 Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
A3:2017- Sensitive Data
Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
A5:2017-Broken Access Control
Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.
Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
A9:2017-Using Components with Known
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
A10:2017- Insufficient Logging & Monitoring
App. Specific Business ?
Example Attack Scenarios Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:
String query = “SELECT * FROM accounts WHERE custID='” + request.getParameter(“id”) + “‘”;
Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g. Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='” + request.getParameter(“id”) + “‘”);
In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ‘ or ‘1’=’1. For example:
http://example.com/app/accountView?id=’ or ‘1’=’1
This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data, or even invoke stored procedures.
Is the Application Vulnerable? An application is vulnerable to attack when:
• User-supplied data is not validated, filtered, or sanitized by the application.
• 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 additional, sensitive records.
• Hostile data is directly used or concatenated, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures.
Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections, closely followed by thorough automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs. Organizations can include static source (SAST) and dynamic application test (DAST) tools into the CI/CD pipeline to identify newly introduced injection flaws prior to production deployment.
References OWASP • OWASP Proactive Controls: Parameterize Queries
• OWASP ASVS: V5 Input Validation and Encoding
• OWASP Testing Guide: SQL Injection, Command Injection, 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
External • CWE-77: Command Injection
• CWE-89: SQL Injection
• CWE-564: Hibernate Injection
• CWE-917: Expression Language Injection
• PortSwigger: Server-side template injection
How to Prevent Preventing injection requires keeping data separate from commands and queries.
• The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs). Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().
• Use positive or “whitelist” server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
Exploitability: 3 Prevalence: 2 Detectability: 3 Technical: 3
Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter.
Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries.
Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws.
Injection can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover.
The business impact depends on the needs of the application and data.
App. Specific Business ?
Example Attack Scenarios Scenario #1: Credential stuffing, the use of lists of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid.
Scenario #2: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.
Scenario #3: Application session timeouts aren’t set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.