Owasp 10 2017
Owasp 10 2017
A10:2017 - Insufficient Logging & Monitoring 16 OWASP is a new kind of organization. Our freedom from
commercial pressures allows us to provide unbiased,
+D - 17 practical, and cost-effective information about application
+T - 18 security.
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.
2
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
Developers, , , which is suitable for CIOs and CISOs, and
, which is suitable for application managers or anyone responsible for the lifecycle of
the application.
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
Maturity Model.
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:
https://github.com/OWASP/Top10/issues
You can find the OWASP Top 10 project and translations here:
https://www.owasp.org/index.php/top10
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!
Organizations and individuals that have provided vulnerability prevalence data or other assistance are listed on the
Acknowledgements page.
3
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
organizations.
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.
Don't stop at 10. There are hundreds of issues that could We'd like to thank the organizations that contributed their
affect the overall security of a web application as discussed vulnerability data to support the 2017 update. We received
in the OWASP Developer's Guide and the OWASP Cheat more than 40 responses to the call for data. For the first
Sheet Series. These are essential reading for anyone time, all the data contributed to a Top 10 release, and the full
developing web applications and APIs. Guidance on how to list of contributors is publicly available. We believe this is one
effectively find vulnerabilities in web applications and APIs of the larger, more diverse collections of vulnerability data
is provided in the OWASP Testing Guide. ever publicly collected.
Constant change. The OWASP Top 10 will continue to As there are more contributors than space here, we have
change. Even without changing a single line of your created a dedicated page to recognize the contributions
application's code, you may become vulnerable as new made. We wish to give heartfelt thanks to these
flaws are discovered and attack methods are refined. organizations for being willing to be on the front lines by
Please review the advice at the end of the Top 10 in What's publicly sharing vulnerability data from their efforts. We hope
Next For Developers, Security Testers, Organizations, and this will continue to grow and encourage more organizations
Application Managers for more information. to do the same and possibly be seen as one of the key
milestones of evidence-based security. The OWASP Top 10
Think positive. When you're ready to stop chasing would not be possible without these amazing contributions.
vulnerabilities and focus on establishing strong application
security controls, the OWASP Proactive Controls project A big thank you to the more than 500 individuals who took
provides a starting point to help developers build security the time to complete the industry ranked survey. Your voice
into their application and the OWASP Application Security helped determine two new additions to the Top 10. The
Verification Standard (ASVS) is a guide for organizations additional comments, notes of encouragement,
and application reviewers on what to verify. and criticisms were all appreciated. We know your time is
valuable and we wanted to say thanks.
Use tools wisely. Security vulnerabilities can be quite
complex and deeply buried in code. In many cases, the We would like to thank those individuals who have
most cost-effective approach for finding and eliminating contributed significant constructive comments and time
these weaknesses is human experts armed with advanced reviewing this update to the Top 10. As much as possible,
tools. Relying on tools alone provides a false sense of Acknowledgements
security and is not recommended.
And finally, we'd like to thank in advance all the translators
Push left, right, and everywhere. Focus on making out there who will translate this release of the Top 10 into
security an integral part of your culture throughout your numerous different languages, helping to make the OWASP
development organization. Find out more in the OWASP Top 10 more accessible to the entire planet.
Software Assurance Maturity Model (SAMM).
4
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.
Single page applications, written in JavaScript frameworks such as Angular and React, allow the creation of highly modular
feature-rich front ends. Client-side functionality that has traditionally been delivered server-side brings its own security challenges.
JavaScript is now the primary language of the web with node.js running server side and modern web frameworks such as
Bootstrap, Electron, Angular, and React running on the client.
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.
A1 Injection A1:2017-Injection
A5 Security Misconfiguration
A9 Using Components with Known Vulnerabilities A9:2017-Using Components with Known Vulnerabilities
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.
The OWASP Top 10 focuses on identifying the most serious web application OWASP
security risks for a broad array of organizations. For each of these risks, we
provide generic information about likelihood and technical impact using the OWASP Risk Rating Methodology
following simple ratings scheme, which is based on the OWASP Risk Rating Article on Threat/Risk Modeling
Methodology.
Threat
Agents
An application is vulnerable to attack when: Preventing injection requires keeping data separate from
User-supplied data is not validated, filtered, or sanitized by the commands and queries.
application. The preferred option is to use a safe API, which avoids the use
Dynamic queries or non-parameterized calls without context- of the interpreter entirely or provides a parameterized interface,
aware escaping are used directly in the interpreter. or migrate to use Object Relational Mapping Tools (ORMs).
Hostile data is used within object-relational mapping (ORM) Note: Even when parameterized, stored procedures can still
search parameters to extract additional, sensitive records. introduce SQL injection if PL/SQL or T-SQL concatenates
Hostile data is directly used or concatenated, such that the queries and data, or executes hostile data with EXECUTE
SQL or command contains both structure and hostile data in IMMEDIATE or exec().
dynamic queries, commands, or stored procedures. Use positive or "whitelist" server-side input validation. This is
Some of the more common injections are SQL, NoSQL, OS not a complete defense as many applications require special
command, Object Relational Mapping (ORM), LDAP, and characters, such as text areas or APIs for mobile applications.
Expression Language (EL) or Object Graph Navigation Library For any residual dynamic queries, escape special characters
(OGNL) injection. The concept is identical among all interpreters. using the specific escape syntax for that interpreter.
Source code review is the best method of detecting if Note: SQL structure such as table names, column names, and
applications are vulnerable to injections, closely followed by so on cannot be escaped, and thus user-supplied structure
thorough automated testing of all parameters, headers, URL, names are dangerous. This is a common issue in report-writing
cookies, JSON, SOAP, and XML data inputs. Organizations can software.
include static source (SAST) and dynamic application test Use LIMIT and other SQL controls within queries to prevent
(DAST) tools into the CI/CD pipeline to identify newly introduced mass disclosure of records in case of SQL injection.
injection flaws prior to production deployment.
Threat
Agents
Confirmation of the user's identity, authentication, and session Where possible, implement multi-factor authentication to
management are critical to protect against authentication-related prevent automated, credential stuffing, brute force, and stolen
attacks. credential re-use attacks.
There may be authentication weaknesses if the application: Do not ship or deploy with any default credentials, particularly
Permits automated attacks such as credential stuffing, where for admin users.
the attacker has a list of valid usernames and passwords. Implement weak-password checks, such as testing new or
Permits brute force or other automated attacks. changed passwords against a list of the top 10000 worst
Permits default, weak, or well-known passwords, such as passwords.
Align password length, complexity and rotation policies with
Uses weak or ineffective credential recovery and forgot- NIST 800-63 B's guidelines in section 5.1.1 for Memorized
password processes, such as "knowledge-based answers", Secrets or other modern, evidence based password policies.
which cannot be made safe. Ensure registration, credential recovery, and API pathways are
Uses plain text, encrypted, or weakly hashed passwords (see hardened against account enumeration attacks by using the
A3:2017-Sensitive Data Exposure). same messages for all outcomes.
Has missing or ineffective multi-factor authentication. Limit or increasingly delay failed login attempts. Log all failures
and alert administrators when credential stuffing, brute force, or
Exposes Session IDs in the URL (e.g., URL rewriting). other attacks are detected.
Does not rotate Session IDs after successful login. Use a server-side, secure, built-in session manager that
Does not properly invalidate Session IDs. User sessions or generates a new random session ID with high entropy after
authentication tokens (particularly single sign-on (SSO) tokens) login. Session IDs should not be in the URL, be securely stored
and invalidated after logout, idle, and absolute timeouts.
Threat
Agents
The first thing is to determine the protection needs of data in Do the following, at a minimum, and consult the references:
transit and at rest. For example, passwords, credit card numbers, Classify data processed, stored, or transmitted by an
health records, personal information and business secrets application. Identify which data is sensitive according to privacy
require extra protection, particularly if that data falls under laws, regulatory requirements, or business needs.
privacy laws, e.g. EU's General Data Protection Regulation Apply controls as per the classification.
(GDPR), or regulations, e.g. financial data protection such as
PCI Data Security Standard (PCI DSS). For all such data: Discard it as soon as
possible or use PCI DSS compliant tokenization or even
Is any data transmitted in clear text? This concerns protocols truncation. Data that is not retained cannot be stolen.
such as HTTP, SMTP, and FTP. External internet traffic is
especially dangerous. Verify all internal traffic e.g. between Make sure to encrypt all sensitive data at rest.
load balancers, web servers, or back-end systems. Ensure up-to-date and strong standard algorithms, protocols,
Is sensitive data stored in clear text, including backups? and keys are in place; use proper key management.
Are any old or weak cryptographic algorithms used either by Encrypt all data in transit with secure protocols such as TLS
default or in older code? with perfect forward secrecy (PFS) ciphers, cipher prioritization
by the server, and secure parameters. Enforce encryption
Are default crypto keys in use, weak crypto keys generated or using directives like HTTP Strict Transport Security (HSTS).
re-used, or is proper key management or rotation missing?
Disable caching for responses that contain sensitive data.
Is encryption not enforced, e.g. are any user agent (browser)
security directives or headers missing? Store passwords using strong adaptive and salted hashing
functions with a work factor (delay factor), such as Argon2,
Does the user agent (e.g. app, mail client) not verify if the scrypt, bcrypt, or PBKDF2.
received server certificate is valid?
Verify independently the effectiveness of configuration and
See ASVS Crypto (V7), Data Prot (V9) and SSL/TLS (V10) settings.
Threat
Agents
Applications and in particular XML-based web services or Developer training is essential to identify and mitigate XXE.
downstream integrations might be vulnerable to attack if: Besides that, preventing XXE requires:
The application accepts XML directly or XML uploads, Whenever possible, use less complex data formats such as
especially from untrusted sources, or inserts untrusted data into JSON, and avoiding serialization of sensitive data.
XML documents, which is then parsed by an XML processor. Patch or upgrade all XML processors and libraries in use by
the application or on the underlying operating system. Use
Any of the XML processors in the application or SOAP based
dependency checkers. Update SOAP to SOAP 1.2 or higher.
web services has document type definitions (DTDs) enabled.
As the exact mechanism for disabling DTD processing varies Disable XML external entity and DTD processing in all XML
by processor, it is good practice to consult a reference such as parsers in the application, as per the OWASP Cheat Sheet
the . 'XXE Prevention'.
Implement positive ("whitelisting") server-side input validation,
If your application uses SAML for identity processing within filtering, or sanitization to prevent hostile data within XML
federated security or single sign on (SSO) purposes. SAML documents, headers, or nodes.
uses XML for identity assertions, and may be vulnerable. Verify that XML or XSL file upload functionality validates
If the application uses SOAP prior to version 1.2, it is likely incoming XML using XSD validation or similar.
susceptible to XXE attacks if XML entities are being passed to SAST tools can help detect XXE in source code, although
the SOAP framework. manual code review is the best alternative in large, complex
Being vulnerable to XXE attacks likely means that the applications with many integrations.
application is vulnerable to denial of service attacks including If these controls are not possible, consider using virtual
the Billion Laughs attack. patching, API security gateways, or Web Application Firewalls
(WAFs) to detect, monitor, and block XXE attacks.
Threat
Agents
Access control enforces policy such that users cannot act Access control is only effective if enforced in trusted server-side
outside of their intended permissions. Failures typically lead to code or server-less API, where the attacker cannot modify the
unauthorized information disclosure, modification or destruction access control check or metadata.
of all data, or performing a business function outside of the limits With the exception of public resources, deny by default.
of the user. Common access control vulnerabilities include: Implement access control mechanisms once and re-use them
Bypassing access control checks by modifying the URL, throughout the application, including minimizing CORS usage.
internal application state, or the HTML page, or simply using a Model access controls should enforce record ownership, rather
custom API attack tool. than accepting that the user can create, read, update, or delete
Allowing the primary key to be changed to another users any record.
record, permitting viewing or editing someone else's account. Unique application business limit requirements should be
enforced by domain models.
Elevation of privilege. Acting as a user without being logged in,
or acting as an admin when logged in as a user. Disable web server directory listing and ensure file metadata
(e.g. .git) and backup files are not present within web roots.
Metadata manipulation, such as replaying or tampering with a
Log access control failures, alert admins when appropriate
JSON Web Token (JWT) access control token or a cookie or
(e.g. repeated failures).
hidden field manipulated to elevate privileges, or abusing JWT
Rate limit API and controller access to minimize the harm from
invalidation
automated attack tooling.
CORS misconfiguration allows unauthorized API access.
JWT tokens should be invalidated on the server after logout.
Force browsing to authenticated pages as an unauthenticated Developers and QA staff should include functional access control
user or to privileged pages as a standard user. Accessing API unit and integration tests.
with missing access controls for POST, PUT and DELETE.
Threat
Agents
The application might be vulnerable if the application is: Secure installation processes should be implemented, including:
Missing appropriate security hardening across any part of the A repeatable hardening process that makes it fast and easy to
application stack, or improperly configured permissions on deploy another environment that is properly locked down.
cloud services. Development, QA, and production environments should all be
Unnecessary features are enabled or installed (e.g. configured identically, with different credentials used in each
unnecessary ports, services, pages, accounts, or privileges). environment. This process should be automated to minimize
Default accounts and their passwords still enabled and the effort required to setup a new secure environment.
unchanged. A minimal platform without any unnecessary features,
Error handling reveals stack traces or other overly informative components, documentation, and samples. Remove or do not
error messages to users. install unused features and frameworks.
For upgraded systems, latest security features are disabled or A task to review and update the configurations appropriate to
not configured securely. all security notes, updates and patches as part of the patch
management process (see A9:2017-Using Components with
The security settings in the application servers, application
Known Vulnerabilities). In particular, review cloud storage
frameworks (e.g. Struts, Spring, ASP.NET), libraries,
permissions (e.g. S3 bucket permissions).
databases, etc. not set to secure values.
A segmented application architecture that provides effective,
The server does not send security headers or directives or they
secure separation between components or tenants, with
are not set to secure values.
segmentation, containerization, or cloud security groups.
The software is out of date or vulnerable (see A9:2017-Using
Sending security directives to clients, e.g. Security Headers.
Components with Known Vulnerabilities).
An automated process to verify the effectiveness of the
Without a concerted, repeatable application security
configurations and settings in all environments.
configuration process, systems are at a higher risk.
Threat
Agents
There are three forms of XSS, usually targeting users' browsers: Preventing XSS requires separation of untrusted data from
Reflected XSS: The application or API includes unvalidated and active browser content. This can be achieved by:
unescaped user input as part of HTML output. A successful Using frameworks that automatically escape XSS by design,
attack can allow the attacker to execute arbitrary HTML and such as the latest Ruby on Rails, React JS. Learn the
limitations of each framework's XSS protection and
interact with some malicious link that points to an attacker- appropriately handle the use cases which are not covered.
controlled page, such as malicious watering hole websites, Escaping untrusted HTTP request data based on the context in
advertisements, or similar. the HTML output (body, attribute, JavaScript, CSS, or URL) will
Stored XSS: The application or API stores unsanitized user resolve Reflected and Stored XSS vulnerabilities. The OWASP
input that is viewed at a later time by another user or an Cheat Sheet 'XSS Prevention' has details on the required data
administrator. Stored XSS is often considered a high or critical escaping techniques.
risk. Applying context-sensitive encoding when modifying the
DOM XSS: JavaScript frameworks, single-page applications, and browser document on the client side acts against DOM XSS.
APIs that dynamically include attacker-controllable data to a When this cannot be avoided, similar context sensitive
page are vulnerable to DOM XSS. Ideally, the application would escaping techniques can be applied to browser APIs as
not send attacker-controllable data to unsafe JavaScript APIs. described in the OWASP Cheat Sheet 'DOM based XSS
Prevention'.
Typical XSS attacks include session stealing, account takeover,
Enabling a Content Security Policy (CSP) is a defense-in-depth
MFA bypass, DOM node replacement or defacement (such as
mitigating control against XSS. It is effective if no other
trojan login panels), attacks against the user's browser such as
vulnerabilities exist that would allow placing malicious code via
malicious software downloads, key logging, and other client-side
local file includes (e.g. path traversal overwrites or vulnerable
attacks.
libraries from permitted content delivery networks).
Threat
Agents
Applications and APIs will be vulnerable if they deserialize hostile The only safe architectural pattern is not to accept serialized
or tampered objects supplied by an attacker. objects from untrusted sources or to use serialization mediums
This can result in two primary types of attacks: that only permit primitive data types.
Object and data structure related attacks where the attacker If that is not possible, consider one of more of the following:
modifies application logic or achieves arbitrary remote code Implementing integrity checks such as digital signatures on any
execution if there are classes available to the application that serialized objects to prevent hostile object creation or data
can change behavior during or after deserialization. tampering.
Typical data tampering attacks, such as access-control-related Enforcing strict type constraints during deserialization before
attacks, where existing data structures are used but the content object creation as the code typically expects a definable set of
is changed. classes. Bypasses to this technique have been demonstrated,
Serialization may be used in applications for: so reliance solely on this is not advisable.
Remote- and inter-process communication (RPC/IPC) Isolating and running code that deserializes in low privilege
environments when possible.
Wire protocols, web services, message brokers
Logging deserialization exceptions and failures, such as where
Caching/Persistence
the incoming type is not the expected type, or the
Databases, cache servers, file systems deserialization throws exceptions.
HTTP cookies, HTML form parameters, API authentication Restricting or monitoring incoming and outgoing network
tokens connectivity from containers or servers that deserialize.
Monitoring deserialization, alerting if a user deserializes
constantly.
Threat
Agents
You are likely vulnerable: There should be a patch management process in place to:
If you do not know the versions of all components you use Remove unused dependencies, unnecessary features,
(both client-side and server-side). This includes components components, files, and documentation.
you directly use as well as nested dependencies. Continuously inventory the versions of both client-side and
If software is vulnerable, unsupported, or out of date. This server-side components (e.g. frameworks, libraries) and their
includes the OS, web/application server, database dependencies using tools like versions, DependencyCheck,
management system (DBMS), applications, APIs and all retire.js, etc. Continuously monitor sources like CVE and NVD
components, runtime environments, and libraries. for vulnerabilities in the components. Use software composition
If you do not scan for vulnerabilities regularly and subscribe to analysis tools to automate the process. Subscribe to email
security bulletins related to the components you use. alerts for security vulnerabilities related to components you
If you do not fix or upgrade the underlying platform, use.
frameworks, and dependencies in a risk-based, timely fashion. Only obtain components from official sources over secure links.
This commonly happens in environments when patching is a Prefer signed packages to reduce the chance of including a
monthly or quarterly task under change control, which leaves modified, malicious component.
organizations open to many days or months of unnecessary Monitor for libraries and components that are unmaintained or
exposure to fixed vulnerabilities. do not create security patches for older versions. If patching is
If software developers do not test the compatibility of updated, not possible, consider deploying a virtual patch to monitor,
upgraded, or patched libraries. detect, or protect against the discovered issue.
If you do not secure the components' configurations Every organization must ensure that there is an ongoing plan for
(see A6:2017-Security Misconfiguration). monitoring, triaging, and applying updates or configuration
changes for the lifetime of the application or portfolio.
Threat
Agents
Insufficient logging, detection, monitoring and active response As per the risk of the data stored or processed by the
occurs any time: application:
Auditable events, such as logins, failed logins, and high-value Ensure all login, access control failures, and server-side input
transactions are not logged. validation failures can be logged with sufficient user context to
Warnings and errors generate no, inadequate, or unclear log identify suspicious or malicious accounts, and held for sufficient
messages. time to allow delayed forensic analysis.
Logs of applications and APIs are not monitored for suspicious Ensure that logs are generated in a format that can be easily
activity. consumed by a centralized log management solutions.
Logs are only stored locally. Ensure high-value transactions have an audit trail with integrity
Appropriate alerting thresholds and response escalation controls to prevent tampering or deletion, such as append-only
processes are not in place or effective. database tables or similar.
Penetration testing and scans by DAST tools (such as OWASP Establish effective monitoring and alerting such that suspicious
ZAP) do not trigger alerts. activities are detected and responded to in a timely fashion.
The application is unable to detect, escalate, or alert for active Establish or adopt an incident response and recovery plan,
attacks in real time or near real time. such as NIST 800-61 rev 2 or later.
You are vulnerable to information leakage if you make logging There are commercial and open source application protection
and alerting events visible to a user or an attacker (see A3:2017- frameworks such as OWASP AppSensor, web application
Sensitive Information Exposure). firewalls such as ModSecurity with the OWASP ModSecurity
Core Rule Set, and log correlation software with custom
dashboards and alerting.
Whether you are new to web application security or already very familiar with these risks, the task of producing a secure web
application or fixing an existing one can be difficult. If you have to manage a large application portfolio, this task can be
daunting.
To help organizations and developers reduce their application security risks in a cost-effective manner, OWASP has
produced numerous free and open resources that you can use to address application security in your organization. The
following are some of the many resources OWASP has produced to help organizations produce secure web applications and
APIs. On the next page, we present additional OWASP resources that can assist organizations in verifying the security of
their applications and APIs.
There are numerous additional OWASP resources available for your use. Please visit the OWASP Projects page, which lists all the
Flagship, Labs, and Incubator projects in the OWASP project inventory. Most OWASP resources are available on our wiki, and
many OWASP documents can be ordered in hardcopy or as eBooks.
18
correctly
implemented, and used everywhere it is supposed to be. The goal of application security testing is to provide this evidence.
The work is difficult and complex, and modern high-speed development processes like Agile and DevOps have put extreme
pressure on traditional approaches and tools. So we strongly encourage you to put some thought into how you are going to
-effectively.
Modern risks move quickly, so the days of scanning or penetration testing an application for vulnerabilities once every year or
so are long gone. Modern software development requires continuous application security testing across the entire software
development. Whatever approach you choose, consider the annual cost to test, triage, remediate, retest, and redeploy a
single application, multiplied by the size of your application portfolio.
19
Application security is no longer optional. Between increasing attacks and regulatory pressures, organizations must establish
effective processes and capabilities for securing their applications and APIs. Given the staggering amount of code in the
numerous applications and APIs already in production, many organizations are struggling to get a handle on the enormous
volume of vulnerabilities.
OWASP recommends organizations establish an application security program to gain insight and improve security across
their applications and APIs. Achieving application security requires many different parts of an organization to work together
efficiently, including security and audit, software development, business, and executive management. Security should be
posture. Focus on the activities and outcomes that actually help improve enterprise security by eliminating or reducing risk.
OWASP SAMM and the OWASP Application Security Guide for CISOs is the source of most of the key activities in this list.
20
Applications belong to the most complex systems humans regularly create and maintain. IT management for an application
should be performed by IT specialists who are responsible for the overall IT lifecycle of an application. We suggest
establishing the role of application manager as technical counterpart to the application owner. The application manager is in
charge of the whole application lifecycle from the IT perspective, from collecting the requirements until the process of retiring
systems, which is often overlooked.
21
The Risk Rating methodology for the Top 10 is based on the OWASP Risk Rating Methodology. For each Top 10 category,
we estimated the typical risk that each weakness introduces to a typical web application by looking at common likelihood
factors and impact factors for each common weakness. We then ordered the Top 10 according to those weaknesses that
typically introduce the most significant risk to an application. These factors get updated with each new Top 10 release as
things change and evolve.
The OWASP Risk Rating Methodology defines numerous factors to help calculate the risk of an identified vulnerability.
However, the Top 10 must talk about generalities, rather than specific vulnerabilities in real applications and APIs.
Consequently, we can never be as precise as application owners or managers when calculating risks for their application(s).
You are best equipped to judge the importance of your applications and data, what your threats are, and how your system
has been built and is being operated.
Our methodology includes three likelihood factors for each weakness (prevalence, detectability, and ease of exploit) and one
impact factor (technical impact). The risk scales for each factor range from 1-Low to 3-High with terminology specific for each
factor. The prevalence of a weakness is
supplied prevalence statistics from a number of different organizations (as referenced in the Acknowledgements on page 25),
and we have aggregated their data together to come up with a Top 10 likelihood of existence list by prevalence. This data
was then combined with the other two likelihood factors (detectability and ease of exploit) to calculate a likelihood rating for
each weakness. The likelihood rating was then multiplied by our estimated average technical impact for each item to come up
with an overall risk ranking for each item in the Top 10 (the higher the result the higher the risk). Detectability, Ease of Exploit,
and Impact were calculated from analyzing reported CVEs that were associated with each of the Top 10 categories.
Note: This approach does not take the likelihood of the threat agent into account. Nor does it account for any of the various
technical details associated with your particular application. Any of these factors could significantly affect the overall likelihood
of an attacker finding and exploiting a particular vulnerability. This rating does not take into account the actual impact on your
business. Your organization will have to decide how much security risk from applications and APIs the organization is willing
to accept given your culture, industry, and regulatory environment. The purpose of the OWASP Top 10 is not to do this risk
analysis for you.
The following illustrates our calculation of the risk for A6:2017-Security Misconfiguration.
Threat
Agents
The following table presents a summary of the 2017 Top 10 Application Security Risks, and the risk factors we have assigned
to each risk. These factors were determined based on the available statistics and the experience of the OWASP Top 10
team. To understand these risks for a particular application or organization, you must consider your own specific threat
agents and business impacts. Even severe software weaknesses may not present a serious risk if there are no threat agents
in a position to perform the necessary attack or the business impact is negligible for the assets involved .
Score
Threat
Agents Exploitability Prevalence Detectability Technical Business
A1:2017- App App
EASY: 3 COMMON: 2 EASY: 3 SEVERE: 3 8.0
Injection Specific Specific
The Top 10 covers a lot of ground, but there are many other risks you should consider and evaluate in your organization.
Some of these have appeared in previous versions of the Top 10, and others have not, including new attack techniques that
are being identified all the time. Other important application security risks (ordered by CWE-ID) that you should additionally
consider include:
CWE-352: Cross-Site Request Forgery (CSRF)
CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion', 'AppDoS')
CWE-434: Unrestricted Upload of File with Dangerous Type
CWE-451: User Interface (UI) Misrepresentation of Critical Information (Clickjacking and others)
CWE-601: Unvalidated Forward and Redirects
CWE-799: Improper Control of Interaction Frequency (Anti-Automation)
CWE-829: Inclusion of Functionality from Untrusted Control Sphere (3rd Party Content)
CWE-918: Server-Side Request Forgery (SSRF)
23
At the OWASP Project Summit, active participants and community members decided on a vulnerability view, with up to two
(2) forward looking vulnerability classes, with ordering defined partially by quantitative data, and partially by qualitative
surveys.
mentioned in feedback to 2017 RC1 on the Top 10 mailing list. We put them into a ranked survey and asked respondents to
rank the top four vulnerabilities that they felt should be included in the OWASP Top 10 - 2017. The survey was open from
Aug 2 Sep 18, 2017. 516 responses were collected and the vulnerabilities were ranked.
Exposure of Private Information is clearly the highest-ranking vulnerability, but fits very easily as an additional emphasis into
the existing A3:2017-Sensitive Data Exposure. Cryptographic Failures can fit within Sensitive Data Exposure. Insecure
deserialization was ranked at number three, so it was added to the Top 10 as A8:2017-Insecure Deserialization after risk
rating. The fourth ranked User-Controlled Key is included in A5:2017-Broken Access Control; it is good to see it rank highly
on the survey, as there is not much data relating to authorization vulnerabilities. The number five ranked category in the
survey is Insufficient Logging and Monitoring, which we believe is a good fit for the Top 10 list, which is why it has become
A10:2017-Insufficient Logging & Monitoring. We have moved to a point where applications need to be able to define what
may be an attack and generate appropriate logging, alerting, escalation and response.
Traditionally, the data collected and analyzed was more along the lines of frequency data: how many vulnerabilities were
found in tested applications. As is well known, tools traditionally report all instances found of a vulnerability and humans
traditionally report a single finding with a number of examples. This makes it very difficult to aggregate the two styles of
reporting in a comparable manner.
For 2017, the incidence rate was calculated by how many applications in a given data set had one or more of a specific
vulnerability type. The data from many larger contributors was provided in two views. The first was the traditional frequency
style of counting every instance found of a vulnerability, while the second was the count of applications in which each
vulnerability was found in (one or more times). While not perfect, this reasonably allows us to compare the data from Human
Assisted Tools and Tool Assisted Humans. The raw data and analysis work is available in GitHub. We intend to expand on
this with additional structure for future versions of the Top 10.
We received 40+ submissions in the call for data, and because many were from the original data call that was focused on
frequency, we were able to use data from 23 contributors covering ~114,000 applications. We used a one-year block of time
where possible and identified by the contributor. The majority of applications are unique, though we acknowledge the
likelihood of some repeat applications between the yearly data from Veracode. The 23 data sets used were either identified
as tool assisted human testing or specifically provided incidence rate from human assisted tools. Anomalies in the selected
data of 100%+ incidence were adjusted down to 100% max. To calculate the incidence rate, we calculated the percentage of
the total applications there were found to contain each vulnerability type. The ranking of incidence was used for the
prevalence calculation in the overall risk for ranking the Top 10.
24
many organizations that contributed their vulnerability data to support the 2017 update:
For the first time, all the data contributed to a Top 10 release, and the full list of contributors is publicly available.
the individual contributors who spent many hours collectively contributing to the Top 10 in GitHub:
ak47gen drwetter ilatypov neo00 starbuck3000
alonergan dune73 irbishop nickthetait stefanb
ameft ecbftw itscooper ninedter sumitagarwalusa
anantshri einsweniger ivanr ossie-git taprootsec
bandrzej ekobrin jeremylong PauloASilva tghosth
bchurchill eoftedal jhaddix PeterMosmans TheJambo
binarious frohoff jmanico pontocom thesp0nge
bkimminich fzipi joaomatosf psiinon toddgrotenhuis
Boberski gebl jrmithdobbs pwntester troymarshall
borischen Gilc83 jsteven raesene tsohlacol
Calico90 gilzow jvehent riramar vdbaan
chrish global4g katyanton ruroot yohgaki
clerkendweller grnd kerberosmansour securestep9
D00gs h3xstream koto securitybits
davewichers hiralph m8urnett SPoint42
drkknight HoLyVieR mwcoates sreenathsasikumar
And everyone else who provided feedback via Twitter, email, and other means.
We would be remiss not to mention that Dirk Wetter, Jim Manico, and Osama Elnaggar have provided extensive assistance.
Also, Chris Frohoff and Gabriel Lawrence provided invaluable support in the writing of the new A8:2017-Insecure
Deserialization risk.