You are on page 1of 23

Release Candidate

Comments requested per instructions within

RC Release Candidate

Important Notice
Request for Comments
OWASP plans to release the final public release of the OWASP Top 10 - 2017 in July or August 2017 after a
public comment period ending June 30, 2017.

This release of the OWASP Top 10 marks this project’s fourteenth year of raising awareness of the
importance of application security risks. This release follows the 2013 update, whose main change was
the addition of 2013-A9 Use of Known Vulnerable Components. We are pleased to see that since the 2013
Top 10 release, a whole ecosystem of both free and commercial tools have emerged to help combat this
problem as the use of open source components has continued to rapidly expand across practically every
programming language. The data also suggests the use of known vulnerable components is still prevalent,
but not as widespread as before. We believe the awareness of this issue the Top 10 - 2013 generated has
contributed to both of these changes.

We also noticed that since CSRF was introduced to the Top 10 in 2007, it has dropped from a widespread
vulnerability to an uncommon one. Many frameworks include automatic CSRF defenses which has
significantly contributed to its decline in prevalence, along with much higher awareness with developers
that they must protect against such attacks.

Constructive comments on this OWASP Top 10 - 2017 Release Candidate should be forwarded via email to
OWASP-TopTen@lists.owasp.org. Private comments may be sent to dave.wichers@owasp.org.
Anonymous comments are welcome. All non-private comments will be catalogued and published at the
same time as the final public release. Comments recommending changes to the items listed in the Top 10
should include a complete suggested list of 10 items, along with a rationale for any changes. All comments
should indicate the specific relevant page and section.

Following the final publication of the OWASP Top 10 - 2017, the collaborative work of the OWASP
community will continue with updates to supporting documents including the OWASP wiki, OWASP
Developer’s Guide, OWASP Testing Guide, OWASP Code Review Guide, and the OWASP Prevention Cheat
Sheets, along with translations of the Top 10 to many different languages.

Your feedback is critical to the continued success of the OWASP Top 10 and all other OWASP Projects.
Thank you all for your dedication to improving the security of the world’s software for everyone.

Jeff Williams, OWASP Top 10 Project Creator and Coauthor
Dave Wichers, OWASP Top 10 Coauthor and Project Lead

practical. DISA. The Top 10 project is referenced • Mailing lists by many standards. you must make it clear to others the license terms of this work. and technology problem. The OWASP Top Learn more at: https://www. The 2010 version was revamped to prioritize by All of the OWASP tools. the mistakes of other organizations. because the most We encourage you to use the Top 10 to get your organization effective approaches to application security require started with application security. documents. secure tolerate relatively simple security problems like those code development. The rapid pace of modern software development processes makes risks even more critical to • Application security tools and standards discover quickly and accurately. Instead. comments. OWASP In the long term. and ideas. and project members. • Standard security controls and libraries • Local chapters worldwide The goal of the Top 10 project is to raise awareness about • Cutting edge research application security by identifying some of the most critical • Extensive conferences worldwide risks facing organizations.org or privately to infrastructure. and organizations. These programs come in all shapes and sizes. As our open community dedicated to enabling organizations to software becomes increasingly critical. The Open Web Application Security Project (OWASP) is an defense. We advocate approaching application security as a people. OWASP and you should avoid attempting to do everything prescribed produces many types of materials in a collaborative.owasp. although we security program that is compatible with your culture and support the informed use of commercial security technology.org.wichers@owasp.0 license. Come join us! Copyright and License Copyright © 2003 – 2017 The OWASP Foundation This document is released under the Creative Commons Attribution ShareAlike 3. leverage your organization’s existing strengths to do and measure what works for you. The OWASP Foundation is the non-profit entity that ensures the project’s long-term success. including MITRE. healthcare. open way. Almost everyone associated We hope that the OWASP Top 10 is useful to your application with OWASP is a volunteer. either publicly to support innovative security research with grants and owasp-topten@lists. tools. Please don’t hesitate to contact OWASP with Chapter Leaders. security. Executives should start thinking about how to manage the risk that software OWASP is a new kind of organization. complex. dave.org 10 was first released in 2003. cost-effective information about application security. Developers can learn from improvements in all of these areas. For any reuse or distribution. and secure code review presented in this OWASP Top 10. we encourage you to create an application is not affiliated with any technology company. process. . the difficulty of achieving application security can be trusted. not just prevalence. books. and develop. At OWASP you’ll find free and open … increases exponentially. PCI DSS. and this pattern was continued in free and open to anyone interested in improving application 2013 and this latest 2017 release. and maintain applications and APIs that connected. in some process model. and many more. We your questions. Project Leaders.owasp. commercial pressures allows us to provide unbiased. security efforts. and other critical infrastructure. purchase. FTC. Our freedom from applications and APIs create in their enterprise. technology. with minor updates in 2004 and 2007. and chapters are risk. including the OWASP Board. Similar to many open source software projects. O About OWASP Foreword About OWASP Insecure software is undermining our financial. We can no longer afford to • Complete books on application security testing. energy. forums.

in combination with consensus estimates of exploitability. I Introduction Welcome Welcome to the OWASP Top 10 2017! This major update adds two new vulnerability categories for the first time: (1) Insufficient Attack Detection and Prevention and (2) Underprotected APIs. Verifiers. And finally. We’d like to thank the many organizations that contributed their vulnerability prevalence data to support the 2017 Constant change. When you’re ready to stop chasing  Vantage VeracodePoint. In many cases. The Top 10 items are selected and prioritized according to this prevalence data. Find out more in the OWASP Top 10 more accessible to the entire planet. We made room for these two new categories by merging the two access control categories (2013-A4 and 2013-A7) back into Broken Access Control (which is what they were called in the OWASP Top 10 . Security vulnerabilities can be quite update to the Top 10 and to: complex and buried in mountains of code. BrandingBrand.  iBLISS and Organizations” for more information. Veracode vulnerabilities and focus on establishing strong application For the first time. including 8 consulting companies and 3 product vendors. Branding Contrast Security attack methods are refined.  Networks. version of this Top 10 release as he’s done previously. and organizations about the consequences of the most important web application security weaknesses. you may become vulnerable as new flaws are discovered and  AspectSecurity. managers. leading. and everywhere.2004). which was added to the Top 10 in 2010. right. Aspect  AsTech Consulting SecurityAsTech Consulting  BrandContrast Security. is publicly available. and dropping 2013-A10: Unvalidated Redirects and Forwards. Even update.  EdgeScaniBLISS EdgeScan. There are hundreds of issues that could Thanks to Aspect Security for initiating. The OWASP Top 10 for 2017 is based primarily on 11 large datasets from firms that specialize in application security. security controls. These are essential reading for anyone developing web applications and APIs. detectability. Focus on making security there that will translate this release of the Top 10 into an integral part of your culture throughout your numerous different languages. architects. Series. all the data contributed to a Top 10 release. Software Assurance Maturity Model (SAMM) and the Rugged Handbook. designers. SecurityPaladion Paladion Networks  Softtek Softtek  Vantage Point Think positive. including these large data set providers: without changing a single line of your application’s code. We would like to thank in advance those who contribute significant constructive comments and time reviewing this Use tools wisely. Please review the advice at the end of the Top 10 in “What’s Next For Developers.000 real-world applications and APIs. Guidance on how to effectively find vulnerabilities in web applications and APIs is provided in the OWASP Testing Guide and the OWASP Code Review Guide. OWASP is maintaining and promoting the and the full list of contributors. This Top 10 will continue to change. The Top 10 provides basic techniques to protect against these high risk problem areas – and also provides guidance on where to go from here. and updating affect the overall security of a web application as discussed in the OWASP Top 10 since its inception in 2003. helping to make the OWASP development organization. . Warnings Attribution Don’t stop at 10. we’d like to thank in advance all the translators out Push left. and impact. Application Security Verification Standard (ASVS) as a guide to organizations and application reviewers on what to verify. The primary aim of the OWASP Top 10 is to educate developers. the most cost-effective approach for finding and eliminating  Neil Smithline – For (hopefully) producing the wiki these weaknesses is human experts armed with good tools. This data spans vulnerabilities gathered from hundreds of organizations and over 50. and to its the OWASP Developer’s Guide and the OWASP Cheat Sheet primary authors: Jeff Williams and Dave Wichers.  Minded MindedSecurity.

3) We added 2017-A10: Underprotected APIs: + Modern applications and APIs often involve rich client applications. we see that the majority of applications and APIs lack basic capabilities to detect. Organizations should consider establishing initiatives to stamp out these issues. and some the asset. In this 2017 release. some the vulnerability.Merged with A4 A7 – Insufficient Attack Protection (NEW) A8 – Cross-Site Request Forgery (CSRF) A8 – Cross-Site Request Forgery (CSRF) A9 – Using Components with Known Vulnerabilities A9 – Using Components with Known Vulnerabilities A10 – Unvalidated Redirects and Forwards . or a strict taxonomy.Merged with A7 A4 – Broken Access Control (Original category in 2003/2004) A5 – Security Misconfiguration A5 – Security Misconfiguration A6 – Sensitive Data Exposure A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control . we periodically update the OWASP Top 10. the acceleration and automation of software development processes like Agile and DevOps. We include it here to help organizations focus on this major emerging exposure. some the defense. the data shows that this issue isn’t as prevalent as expected. Based on the data call. and can significantly change the threat landscape. Application and API owners also need to be able to deploy patches quickly to protect against attacks. that connect to an API of some kind (SOAP/XML. we’ve considered adding insufficient defenses against automated attacks. GWT. we made the following changes: 1) We merged 2013-A4: Insecure Direct Object References and 2013-A7: Missing Function Level Access Control back into 2017- A4: Broken Access Control. These APIs are often unprotected and contain numerous vulnerabilities. We no longer feel that is necessary so we merged them back together. etc. However. Some of them are organized around the attacker. containers.Dropped A10 – Underprotected APIs (NEW) . o In 2007. non-overlapping.). we added this category to raise awareness of this problem. and respond to both manual and automated attacks. prevent. and they are not intended to be airtight. the explosion of third-party libraries and frameworks. and advances made by attackers. this time it didn’t make the cut. and APIs). we split Broken Access Control into these two categories to bring more attention to each half of the access control problem (data and functionality). such as JavaScript in the browser and mobile apps. These factors frequently make applications and APIs more difficult to analyze. REST/JSON. 4) We dropped: 2013-A10: Unvalidated Redirects and Forwards: – In 2010. So after being in the last two releases of the Top 10. Key factors in this evolution are the rapid adoption of new technologies (including cloud. NOTE: The T10 is organized around major risk areas. RN Release Notes What Changed From 2013 to 2017? The threat landscape for applications and APIs constantly changes. RPC. 2) We added 2017-A7: Insufficient Attack Protection: + For years. OWASP Top 10 – 2013 (Previous) OWASP Top 10 – 2017 (New) A1 – Injection A1 – Injection A2 – Broken Authentication and Session Management A2 – Broken Authentication and Session Management A3 – Cross-Site Scripting (XSS) A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References . To keep pace.

which is based on the OWASP Risk Rating Methodology. To determine the risk to your organization. Threat Attack Security Security Technical Business Agents Vectors Weaknesses Controls Impacts Impacts Attack Weakness Control Impact Asset Attack Weakness Control Impact Function Attack Weakness Impact Asset Weakness Control Sometimes. and security weakness and combine it with an estimate of the technical and business impact to your organization. . or it may put you out of business. these paths are trivial to find and exploit and sometimes they are extremely difficult. Therefore. align with common terminology most likely to raise awareness. focusing on the threat agents. and business impacts in your enterprise. We list Threat Agents as Application Specific. the harm that is caused may be of no consequence. Together.Risk Application Security Risks What Are Application Security Risks? Attackers can potentially use many different paths through your application to do harm to your business or organization. We chose names that accurately reflect the risks and. Each of these paths represents a risk that may. For each of these risks. attack vector. security controls. For any given application. you should evaluate each risk for yourself. What’s My Risk? References The OWASP Top 10 focuses on identifying the most serious risks for a broad array of organizations. the type of weakness. The names of the risks in the Top 10 stem from the type of attack. Similarly. or the technical impact may not make any difference to your business. we provide generic information about OWASP likelihood and technical impact using the following simple ratings scheme. there may not be a threat agent that can perform the relevant attack. or may not. you can evaluate the likelihood associated with each threat agent. or the type of impact they cause. be serious enough to warrant attention. where possible. these factors determine your overall risk. and Business Impacts as Application / Business Specific to indicate these are clearly dependent on the details about your application in your enterprise. • OWASP Risk Rating Methodology • Article on Threat/Risk Modeling Threat Attack Weakness Weakness Technical Business Agents Vectors Prevalence Detectability Impacts Impacts Easy Widespread Easy Severe External App / App • FAIR Information Risk Framework Average Common Average Moderate Business Specific • Microsoft Threat Modeling Tool Difficult Uncommon Difficult Minor Specific Only you know the specifics of your environment and your business.

such as access other Control users' accounts. allowing attackers to compromise passwords. Secure settings Misconfiguration should be defined. deface web sites. such as JavaScript in the Underprotected browser and mobile apps. RPC. prevent. and PII. A6 – Sensitive Data healthcare. database server. implemented. responding. etc. XXE. . view sensitive files. application server. including the victim’s session cookie and any other automatically included authentication information. Such an attack allows the attacker to force a victim’s browser to (CSRF) generate requests the vulnerable application thinks are legitimate requests from the victim. change access rights. identity theft. Sensitive data deserves extra protection such as encryption at rest or in transit. and respond to A7 – Insufficient both manual and automated attacks. or redirect the user to malicious sites. A4 – Broken Access Restrictions on what authenticated users are allowed to do are not properly enforced. and LDAP injection occur when untrusted data is sent to an A1 – Injection interpreter as part of a command or query. keys. The majority of applications and APIs lack the basic ability to detect. and maintained. or updates an existing web page with user supplied data using a Scripting (XSS) browser API that can create JavaScript. APIs GWT. OWASP Top 10 Application T10 Security Risks – 2017 Injection flaws. A5 – Security frameworks. platform. Attackers can exploit these flaws to access unauthorized functionality and/or data. Attack protection goes far beyond basic input validation Attack Protection and involves automatically detecting. Additionally. logging. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. such as libraries. Attackers may steal or modify such weakly protected data to conduct credit Exposure card fraud. Management XSS flaws occur whenever an application includes untrusted data in a new web page without A3 – Cross-Site proper validation or escaping. Many web applications and APIs do not properly protect sensitive data. A2 – Broken Authentication and Application functions related to authentication and session management are often implemented incorrectly. or to exploit Session other implementation flaws to assume other users’ identities (temporarily or permanently). A9 – Using Components. software should be kept up to date. OS. Good security requires having a secure configuration defined and deployed for the application. REST/JSON. Application owners also need to be able to deploy patches quickly to protect against attacks. or other crimes. to a Request Forgery vulnerable web application. A8 – Cross-Site A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request. Applications and APIs using components with known Vulnerabilities vulnerabilities may undermine application defenses and enable various attacks and impacts. as defaults are often insecure. that connect to an API of some kind (SOAP/XML. or session tokens. and other software modules. These APIs are often unprotected and contain numerous vulnerabilities. If a vulnerable component is exploited. run with the same Components with privileges as the application. such as SQL. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions. web server. such an attack can facilitate Known serious data loss or server takeover. modify other users’ data. and even blocking exploit attempts. frameworks. etc. such as financial.). as well as special precautions when exchanged with the browser. A10 – Modern applications often involve rich client applications and APIs. etc.

. Example Attack Scenarios References Scenario #1: An application uses untrusted data in the OWASP construction of the following vulnerable SQL call: • OWASP SQL Injection Prevention Cheat Sheet String query = "SELECT * FROM accounts WHERE • OWASP Query Parameterization Cheat Sheet custID='" + request. these issues by crafting exploits that confirm the vulnerability. XML parsers. stored procedures. They are often accountability. All data partners. XPath. Scanners and fuzzers reputation be can help attackers find injection flaws. (e. XXE). harmed? Am I Vulnerable To Injection? How Do I Prevent Injection? The best way to find out if an application is vulnerable to Preventing injection requires keeping untrusted data injection is to verify that all use of interpreters clearly separate from commands and queries. expression languages. the syntax of the particularly in legacy code. LDAP. Hibernate Query Language (HQL)): • OWASP Testing Guide: Chapter on SQL Injection Testing Query HQLQuery = session. it is recommended to avoid the interpreter.createQuery("FROM accounts External WHERE custID='" + request. you should application uses interpreters safely. such as variables in all prepared statements and stored procedures. business interpreter. For SQL calls. other any source of data SMTP Headers. • CWE Entry 77 on Command Injection In both cases. but frequently hard to takeover. including examining code. that are parameterized. and vector. • OWASP Command Injection Article Scenario #2: Similarly. Be careful with APIs. systems. Positive or “white list” input validation is also Automated dynamic scanning which exercises the application recommended. In 1. only approaches (1) and (2) have difficulty detecting whether an attack was successful.getParameter("id") + "'"). or and the platform including external targeted found in SQL.getParameter("id") + "'". internal can be an injection Injection flaws are easy to discover when complete host modified. Could your administrators. More dangerous attacks could modify data or even invoke stored procedures..g. but is not a complete defense as many may provide insight into whether some exploitable injection situations require special characters be allowed. or use of the interpreter entirely or provides a disable it (e. etc. A1 Injection Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific EASY COMMON AVERAGE SEVERE Business Specific Consider anyone Attackers send Injection flaws occur when an application Injection can result Consider the who can send simple text-based sends untrusted data to an interpreter. If a parameterized API is not available. the attacker modifies the ‘id’ parameter value • CWE Entry 89 on SQL Injection in her browser to send: ' or '1'='1. sometimes lead to could be stolen. Scanners cannot always reach interpreters and characters are required. 3. use bind parameterized interface. or NoSQL denial of access. above will make their use safe. corruption. internal sources. but can still or avoid dynamic queries. OWASP’s ESAPI has an Poor error handling makes injection flaws easier to discover. extensible library of white list input validation routines. running the users. Almost queries. discover via testing. Checking the code is a fast and accurate way to see if the 2. in data loss or business value of untrusted data to attacks that exploit Injection flaws are very prevalent. Penetration testers can validate and similar libraries provide such escaping routines. . lack of the affected data the system. The preferred option is to use a safe API which avoids the many cases. If special flaws exist. Code analysis tools can carefully escape special characters using the specific help a security analyst find use of interpreters and trace data escape syntax for that interpreter.g.com/app/accountView?id=' or '1'='1 • CWE Entry 611 on Improper Restriction of XXE This changes the meaning of both queries to return all the • CWE Entry 917 on Expression Language Injection records from the accounts table. separates untrusted data from the command or query. Injection can interpreter. OS commands. For example: • CWE Entry 564 on Hibernate Injection http://example. an application’s blind trust in • OWASP XXE Prevention Cheat Sheet frameworks may result in queries that are still vulnerable. OWASP’s Java Encoder flow through the application. deleted. if possible. or users. introduce injection under the hood.

• OWASP Password Storage Cheat Sheet Scenario #2: Application’s timeouts aren’t set properly. logout. management requirements defined in OWASP’s Application Security Verification Standard (ASVS) 3. a) meet all the authentication and session change password.g. Session IDs don’t timeout. 5. Instead of selecting • OWASP Session Management Cheat Sheet “logout” the user simply closes the browser tab and walks • OWASP Testing Guide: Chapter on Authentication away. use. attacker can do to steal accounts exposed accounts. • CWE Entry 384 on Session Fixation . See 2017-A6. the vulnerability. 6. Session IDs are vulnerable to session fixation attacks. remember anything the victim Also consider the from others. Credentials can be guessed or overwritten through weak account management functions (e. Management). management frequently have flaws in areas such as successful. 2. exposing every users’ password. forgot password. See the ASVS requirement areas V2 and V3 for more details. Such controls should strive to: 2.g. User authentication credentials aren’t properly protected 1. Once and application authorized users. their actions. over unencrypted connections. or user sessions or b) have a simple interface for developers.jsessionid= avoid in this area. to emulate. As a result. User uses a public computer to access site. session IDs. create account... URL rewriting). as each implementation is frequently targeted. Session IDs aren’t rotated after successful login. change password. etc. timeouts. who may attempt functions (e. management controls. secret question. An authenticated user of the site wants to let their friends • OWASP Authentication Cheat Sheet know about the sale. A single set of strong authentication and session when stored using hashing or encryption. Strong efforts should also be made to avoid XSS flaws 7. but building these correctly is all accounts to be the affected data as well as session hard. Example Attack Scenarios References Scenario #1: A travel reservations application supports URL OWASP rewriting. See 2017-A3.g. account creation. When the • OWASP Forgot Password Cheat Sheet friends use the link they use user’s session and credit card. Session IDs are exposed in the URL (e. Broken Authentication and A2 Session Management Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific AVERAGE COMMON AVERAGE SEVERE Business Specific Consider Attackers use leaks Developers frequently build custom Such flaws may Consider the anonymous or flaws in the authentication and session management allow some or even business value of external attackers.com/sale/saleitems. these custom schemes attacked. authentication or schemes. see the ASVS requirements areas for 2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii Authentication (V2) and Session Management (V3). or build upon. weak session IDs). Privileged business impact of consider insiders IDs) to temporarily Finding such flaws can sometimes be accounts are public exposure of wanting to disguise or permanently difficult. areas V2 (Authentication) and V3 (Session 4. the functions. See 2017-A6. recover password. Passwords. User passwords are not properly hashed and salted. unique. session me. putting session IDs in the URL: For a more complete set of requirements and problems to http://example.. Also passwords. could do. External Scenario #3: An insider or external attacker gains access to • CWE Entry 287 on Improper Authentication the system’s password database. and other credentials are sent which can be used to steal session IDs. account update. Am I Vulnerable to Hijacking? How Do I Prevent This? Are session management assets like user credentials and The primary recommendation for an organization is to make session IDs properly protected? You may be vulnerable if: available to developers: 1. User e-mails the above link without knowing they are also giving away their session ID. impersonate users. and that browser is still authenticated. Consider the authentication tokens (particularly single sign-on (SSO) ESAPI Authenticator and User APIs as good examples tokens) aren’t properly invalidated during logout. An attacker uses the same browser an hour later.

attacker. To avoid Server XSS. Detection of most users. escape untrusted data based on the HTML context (body. XSS across your entire site. 1. the preferred option is to avoid Automated tools can find some XSS problems automatically. A3 Cross-Site Scripting (XSS) Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific AVERAGE VERY WIDESPREAD AVERAGE MODERATE Business Specific Consider anyone Attackers send text. • OWASP XSS Prevention Cheat Sheet • OWASP DOM based XSS Prevention Cheat Sheet The attacker modifies the ‘CC’ parameter in his browser to: • OWASP Java Encoder API '><script>document. ActiveX. allowing the attacker to hijack the user’s current session. for details on the required data escaping techniques. Am I Vulnerable to XSS? How Do I Prevent XSS? You are vulnerable to Server XSS if your server-side code uses Preventing XSS requires separation of untrusted data from user-supplied input as part of the HTML output. When this cannot and uses different browser side interpreters such as be avoided. usually using 3rd can be applied to browser APIs as described in the party libraries built on top of these technologies. hijack user sessions. passing untrusted data to JavaScript and other browser However. and insert hostile partners. If a web page uses JavaScript to dynamically add attacker. See External 2017-A8 for info on CSRF. Almost There are two primary categories of XSS deface web sites. such as data from code analysis.com/cgi-bin/cookie. See the OWASP XSS Prevention Cheat Sheet validation can be used to make this safe. and you active browser content. particularly when using modern single-page applications and powerful 3. don’t use context-sensitive escaping to ensure it cannot run. other can be an attack each of these can occur on (a) the Server content. JavaScript. difficult to identify. coverage requires a combination of manual code review and 4. Consider Content Security Policy (CSP) to defend against penetration testing. etc. you would avoid sending attacker-controllable data to unsafe attribute. CSS. 2. complete OWASP’s AntiSamy or the Java HTML Sanitizer Project.cookie</script>'. similar context sensitive escaping techniques JavaScript. business any source of data flaws: (1) Stored. the preferred option is to properly controllable data to a page. and Silverlight.cgi? • ASVS: Output Encoding/Escaping Requirements (V6) foo='+document. For rich content. redirect Also consider the systems. Client XSS can be very using malware. users. and all the data it including external browser. or URL) that the data will be JavaScript APIs. • OWASP Code Review Guide: Chapter on XSS Review Note that attackers can also use XSS to defeat any • OWASP XSS Filter Evasion Cheat Sheet automated CSRF defense the application might employ. but escaping (and to a lesser extent) input placed into. Therefore. XSS flaws occur when an application Attackers can Consider the who can send based attack scripts updates a web page with attacker execute scripts in a business value of untrusted data to that exploit the controlled data without properly escaping victim’s browser to the affected system the system. and internal sources Server XSS flaws is fairly easy via testing or user’s browser public exposure of administrators. • CWE Entry 79 on Cross-Site Scripting . you may have Client XSS. interpreter in the that content or using a safe JavaScript API. including or (b) on the Client. consider auto-sanitization libraries like JavaScript frameworks and libraries. internal vector. • OWASP AntiSamy: Sanitization Library This attack causes the victim’s session ID to be sent to the • Testing Guide: 1st 3 Chapters on Data Validation Testing attacker’s website. the database. Example Attack Scenario References The application uses untrusted data in the construction of the OWASP following HTML snippet without validation or escaping: • OWASP Types of Cross-Site Scripting (String) page += "<input name='creditcard' type='TEXT' value='" + request. in addition to automated approaches. and (2) Reflected. the vulnerability.getParameter("CC") + "'>". This OWASP DOM based XSS Prevention Cheat Sheet. Ideally. each application builds output pages differently APIs that can generate active content. Flash. processes. To avoid Client XSS. diveristy makes automated detection difficult.location= 'http://www. hijack the business impact of users.

g. applications and APIs frequently Such flaws can Consider the of authorized users authorized users. data? shows whether authorization is correct. Testers enforced. For data references. request. URLs and function names are that is accessible. A4 Broken Access Control Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific EASY WIDESPREAD EASY MODERATE Business Specific Consider the types Attackers. Code analysis quickly stolen. • OWASP Top 10-2007 on Function Level Access Control ResultSet results = pstmt. the attacker can access any user’s account. a drop down list of six resources authorized for the current user could use the Code review of the application can verify whether these numbers 1 to 6 to indicate which value the user selected. properly verified. Leverage automation to verify what requires protection or what is safe or unsafe. If not • ESAPI Access Control API (See isAuthorizedForData(). Use per user or session indirect object references. consider: 1. Automated verification. see the ASVS requirements area for Access Control (V4). Reference weakness) . Admin rights are also required for access to the admin page. This coding pattern prevents attackers from directly targeting 2. For example. does the application ensure the user untrusted source must include an access control check to is authorized by using a reference map or access control ensure the user is authorized for the requested resource. Check access.. isAuthorizedForFile().setString( 1. Is authorized for the target resource. Am I Vulnerable? How Do I Prevent This? The best way to find out if an application is vulnerable to Preventing access control flaws requires selecting an access control vulnerabilities is to verify that all data and approach for protecting each function and each type of data function references have appropriate defenses. filename). it’s a flaw. Scenario #2: An attacker simply force browses to target URLs. Are simply change a when generating web pages. or abused. proper authorization deployment. For non-public function requests. Also consider the unauthenticated authorized for. check to ensure the user is authorized for that data? 2. To determine (e. Each use of a direct reference from an 1. Applications and Unless references and data? Are they aren’t APIs don’t always verify the user is are unpredictable. controls are implemented correctly and are present OWASP’s ESAPI includes both sequential and random everywhere they are required. this is also a flaw. and functionality. do not look for such flaws because they cannot recognize 3. functionality or granted? detect such flaws. isAuthorizedForFunction() ) http://example. data and public exposure of access to any functionality or data can easily manipulate parameters to functionality can be the vulnerability. Manual testing is also effective access reference maps that developers can use to for identifying access control flaws. Example Attack Scenario References Scenario #1: The application uses unverified data in a SQL call OWASP that is accessing account information: • OWASP Top 10-2007 on Insecure Direct Object References pstmt. External http://example. certain functions another resource frequently easy to guess. does the application unauthorized resources. if you are vulnerable.executeQuery( ). who are For data. Automated tools typically eliminate direct object references.com/app/accountInfo?acct=notmyacct For additional access control requirements. • CWE Entry 22 on Path Traversal (an example of a Direct Object If a non-admin can access the admin page. object number.com/app/getappInfo • CWE Entry 285 on Improper Access Control (Authorization) http://example. This is often custom. instead of using ensure the user is authenticated. and has the required roles or privileges to use that function? the resource’s database key. For functionality or data the exposed data users restricted to parameter value to functions.getParameter("acct")). use the actual name or key of an object compromise all the business value of of your system. • ESAPI Access Reference Map API An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want.com/app/admin_getappInfo • CWE Entry 639 on Insecure Direct Object References If an unauthenticated user can access either page. This or access control is business impact of users allowed access to this results in an access control flaw.

any level of an application stack.. Attacker then finds a • OWASP Top 10 2004 . logs in with default passwords. components and libraries as well (see 2017-A9). Am I Vulnerable to Attack? How Do I Prevent This? Is your application missing the proper security hardening The primary recommendations are to establish all of the across any part of the application stack? Including: following: 1. Web/App Server. accounts. Default accounts aren’t changed. applications. and takes over. settings are properly configured in all environments. Struts. such slowly over time. libraries. compromise. An automated process to verify that configurations and configuration process. potentially exposing underlying flaws External such as framework versions that are known to be vulnerable. DBMS. Are the security settings in your application servers. etc. environments should all be configured identically (with ports. repeatable application security 4. For additional requirements in this area. The attacker finds and downloads all your • OWASP Testing Guide: Testing for Error Codes compiled Java classes. Developers and system to some system knowing it. and production 2.NET). A strong application architecture that provides effective. be returned to users. server. Automated scanners are useful Occasionally. • NIST Guide to General Server Hardening Scenario #4: App server comes with sample applications that are not removed from your production server. This process should be automated to minimize the effort 3. etc. database. All of that may attempt to and directories. misconfigurations. Development. databases. Are default accounts and their passwords still enabled required to setup a new secure environment. locked down. accounts. • CIS Security Configuration Guides/Benchmarks . Attacker discovers the standard admin pages are on your • OWASP Development Guide: Chapter on Configuration server.g. pages. easy to deploy another environment that is properly APIs. application frameworks (e. etc. A5 Security Misconfiguration Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific EASY COMMON EASY MODERATE Business Specific Consider Attackers access Security misconfiguration can happen at Such flaws The system could anonymous default accounts. systems are at a higher risk. which they decompile and reverse engineer to get all your custom code. Example Attack Scenarios References Scenario #1: The app server admin console is automatically OWASP installed and not removed. frameworks. QA. A repeatable hardening process that makes it fast and includes the OS. services. flaws result in a wanting to disguise the system. the platform.. These sample • CWE Entry 2 on Environmental Security Flaws applications have well known security flaws attackers can use to compromise your server. and unchanged? 2. Does your error handling reveal stack traces or other software updates and patches in a timely manner to each overly informative error messages to users? deployed environment. use of default complete system Recovery costs their actions. An attacker discovers they can simply list directories to find any file. Spring. unnecessary services. This process needs to include all 5. see the ASVS Scenario #3: App server configuration allows stack traces to requirements areas for Security Configuration (V11 and V19).Insecure Configuration Management serious access control flaw in your application. A process for keeping abreast of and deploying all new 4. • OWASP Code Review Guide: Chapter on Error Handling Scenario #2: Directory listing is not disabled on your web • OWASP Testing Guide: Configuration Management server. Is any of your software out of date? This software 1. consider insiders to or knowledge of for detecting missing patches. Are any unnecessary features enabled or installed (e.g. could be expensive. and all components and libraries (see 2017-A9). Without a concerted. administrators need to work together to data or your data could be compromise the to gain ensure that the entire stack is configured functionality. application attackers compromised as well as unpatched flaws. ASP. Also unauthorized access properly. web server. including frequently give be completely external attackers unused pages. 3. privileges)? different passwords used in each environment). not set to secure values? secure separation between components. and custom unauthorized access without you authorized users unprotected files code. stolen or modified system.

An attacker simply monitors network traffic (like an open wireless network)..For a more complete set of requirements. do the following. and personal said. credit card numbers. or is proper key used. This includes such as steal keys. reputation. and SSL/TLS (V10). and steals the user’s • OWASP Testing Guide: Chapter on SSL/TLS Testing session cookie. etc. or from side flaws due to limited access and they personal data. Alternatives include not storing credit card numbers. External data such as health exposed? Also browsers. external user). 5. What is the data at rest. and even in middle attacks. and sensitive enough to require extra protection. However. Is any of this data stored in clear text long term. Considering the threats you plan to protect this data 1. And more … For a more complete set of problems to avoid. Consider using FIPS 140 validated cryptographic modules. health records. hashing techniques. For all such data: 1. PBKDF2. while attackers have difficulty detecting server records. and weak algorithm usage have been impact to your data. The attacker then replays this cookie and External hijacks the user’s session. insider attack.g. Don’t store sensitive data unnecessarily. Ensure passwords are stored with an algorithm 5. When crypto is compromises all business value of sensitive data and directly. for all sensitive data. For example. Is any of this data transmitted in clear text. SSL/TLS usage. 3. such as when sensitive data is provided by / sent to the browser? bcrypt. Are weak crypto keys generated. They break employed. credentials. but includes sensitive this data is your customers’ steal clear text data hard to exploit on a large scale. 2. make sure you backups of this data? encrypt all sensitive data at rest and in transit in a manner that defends against these threats. using • OWASP Cryptographic Storage Cheat Sheet tokenization. A file upload flaw allows an • CWE Entry 312 on Cleartext Storage of Sensitive Information attacker to retrieve the password file. and disable caching for pages that contain sensitive data. Data you don’t retain can’t be stolen. damage to your internal threats. weak key generation and data that should the lost data and any backups of that something else. internally or 2. reputation. That passwords. or using public key encryption. Typically. accessing the user’s private data. Are any old / weak cryptographic algorithms used? 3. allowing an SQL Communications Security (V10) injection flaw to retrieve credit card numbers in clear text. • OWASP Password Storage Cheat Sheet Scenario #2: A site simply doesn’t use TLS for all • OWASP Transport Layer Protection Cheat Sheet authenticated pages. are also usually hard to exploit. Discard it as externally? Internet traffic is especially dangerous. soon as possible. Example Attack Scenarios References Scenario #1: An application encrypts credit card numbers in a OWASP . and proper key management is in place. or are very common and easy to detect. Browser weaknesses this information your legal liability if transit. including from (e. credit cards. in do man-in-the. Information • CWE Entry 326 on Weak Encryption . A6 Sensitive Data Exposure Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific DIFFICULT UNCOMMON AVERAGE SEVERE Business Specific Consider who can Attackers typically The most common flaw is simply not Failure frequently Consider the gain access to your don’t break crypto encrypting sensitive data. the user’s browser. management. • CWE Entry 310 on Cryptographic Issues Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. Disable autocomplete on forms requesting sensitive data see ASVS areas Crypto (V7). Am I Vulnerable to Data Exposure? How Do I Prevent This? The first thing you have to determine is which data is The full perils of unsafe cryptography. Ensure strong standard algorithms and strong keys are 4. see database using automatic database encryption. or scrypt. this ASVS req’ts on Cryptography (V7). Data Protection (V9) and data is automatically when retrieved. Are any browser security directives or headers missing specifically designed for password protection. management or rotation missing? 4. consider the both external and in transit. is common. particularly weak password protected. data protection are well beyond the scope of the Top 10. at a minimum: information should be protected. Include off the server. All of the unsalted hashes can be exposed with a rainbow table of precalculated • CWE Entry 319 on Cleartext Transmission of Sensitive hashes. Data Prot (V9).

Is it only XSS and SQL Injection? You can HTTP traffic. yet organizations frequently take client can’t generate)? Is the application being used in a weeks or even months to roll out new defenses. • CWE Entry 778 . Does the the attacker attack again and again. Not quickly time. • OWASP Virtual Patching Cheat Sheet While more difficult to detect. • OWASP Automated Threats Project Scenario #2: A skilled human attacker carefully probes for • OWASP Credential Stuffing Cheat Sheet potential vulnerabilities. send in invalid input. Example Attack Scenarios References Scenario #1: Attacker uses automated tool like OWASP ZAP or OWASP SQLMap to detect vulnerabilities and possibly exploit them. Tracking this attacker may require External building a case over time that demonstrates malicious intent. this attack still involves requests that a normal user would never send. vulnerability is discovered. Decide whether to automatically block the attacker and characteristics of the attack. Logs and notifications are critical to the attacks. Detect Attacks.Insufficient Logging How quickly can you deploy a real or virtual patch to block • CWE Entry 799 . Respond to Attacks. Allowing business. Most applications and APIs detect attacks start with of insufficient attack can send your anonymous. and provide details on timely response. or IP ranges. way that an ordinary user would never do (e. If your dev process can’t push out critical Be sure to understand what types of attacks are covered by patches in a day. It should be very obvious if attack detection and response repeated requests)? isn’t in place. A7 Insufficient Attack Protection Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific EASY COMMON AVERAGE MODERATE Business Specific Consider anyone Attackers. Detecting and blocking the likelihood of undiscovered for both manual and respond? Can it both manual and automated attacks. IP addresses..Improper Control of Interaction Frequency continued exploitation of this vulnerability? . deploy a virtual patch that analyzes attack protection. block any viable attacks. 3. If you can’t requests. and/or code execution and use technologies like WAFs. Am I Vulnerable to Attack? How Do I Prevent This? Detecting. tempo too high. Patch Quickly. Simply try manual attacks or run a scanner against the application. responding to. Critical 1. atypical input. Did something occur that is impossible vulnerabilities in both custom code and components are also for legitimate users to cause (e. but simply reject it. and OWASP AppSensor to prevents vulnerabilities from being exploited. detect or block attacks. unusual usage patterns. is successful exploit to long periods of automated attacks? thwart attacks one of the most effective ways to increase 100%. • WASC Article on Insufficient Anti-automation Scenario #3: Attacker starts exploiting a vulnerability in your application that your current attack protection fails to block. letting vulnerability protection on the application a attacks. such as input • OWASP Mod Security Core Ruleset not allowed by the UI.g. Successful request. and expand against known security. and/or virtually patch vulnerabilities. known Applications and APIs are attacked all the Most successful Consider the impact with network access users or time. eventually finding an obscure flaw. go and respond to How does it vulnerabilities. Does your application or API attacks indicate a malicious or such probes to attacks may not be application detect detect the attack? compromised user probing or exploiting continue can raise prevented. How quickly can you patch a deploying patches far beyond their vulnerabilities? critical vulnerability you just discovered? aids attackers. • OWASP Article on Intrusion Detection Attack detection should recognize the application is being targeted with unusual requests and high volume. data flow. Automated • OWASP AppSensor scans should be easy to distinguish from normal traffic. The application or API should identify 2. RASP. Consider disabling or quickly roll out virtual and/or actual patches when a critical monitoring misbehaving user accounts.g. an input a legitimate discovered all the time. initial footprint.. Such probing. you are left exposed to attack. and blocking attacks makes There are three primary goals for sufficient attack protection: applications dramatically harder to exploit yet almost no applications or APIs have such protection.

the Detection of CSRF flaws is fairly easy via purchases. Imagine to submit a request image tags. by tricking apps and APIs into generating arbitrary HTTP 1. Also be an unpredictable token in each HTTP request.NET do so as well. hidden field. An alternate Spring. since those are the most important CSRF targets. Example Attack Scenario References The application allows a user to submit a state changing OWASP request that does not include anything secret. Many and forms lack an unpredictable CSRF token. such as . OWASP’s CSRF Guard submit the request. Django. this runs the risk that the token will OWASP’s CSRF Tester tool can help generate test cases to be exposed to an attacker. which is increasingly supported in browsers. website or other the user is indistinguishable from legitimate ones. demonstrate the dangers of CSRF flaws. attack succeeds.. attackers is authorized to not being sure if can create malicious web pages which to your website.Java CSRF Defense Tool from the victim’s account to the attacker’s account. authorizing the • CWE Entry 352 on CSRF attacker’s request. these forged requests will automatically include the user’s session info. the attacker constructs a request that will transfer money • OWASP CSRFGuard . be unique per user session.g. parameter. Without such a frameworks now include built in CSRF defenses. The unique token can also be included in the URL or a against CSRF since they are included in the forged requests. see if any links The preferred option is to use an existing CSRF defense.com. Cross-Site Request Forgery A8 (CSRF) Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific AVERAGE UNCOMMON EASY MODERATE Business Specific Consider anyone Attackers create CSRF takes advantage of the fact that Attackers can trick Consider the who can load forged HTTP most web apps allow attackers to predict victims into business value of content into your requests and trick a all the details of a particular action. preventing CSRF usually requires the inclusion of Multistep transactions are not inherently immune. OWASP’s Focus on the links and forms that invoke state-changing CSRFProtector does the same for PHP or as an Apache filter. This includes the value in the body of the Note that session cookies. victim into Because browsers send credentials like state changing application and thus force them submitting them via operation the victim functions. and then • OWASP CSRFProtector . avoiding its exposure in the URL. can automatically add CSRF defenses to Java apps. such as token.com/app/transferFunds? • OWASP Testing Guide: Chapter on CSRF Testing amount=1500&destinationAccount=attackersAcct#“ • OWASP CSRFTester . source IP addresses.CSRF Testing Tool width="0" height="0" /> If the victim visits any of the attacker’s sites while already External authenticated to example. Such tokens aware that Server-Side Request Forgery (SSRF) is also possible should. information automatically sent by the browser don’t defend 2. functions. XSS. users intended to including any other techniques. Some web development defense is to require the user to prove they intended to languages.PHP and Apache CSRF Defense Tool embeds this attack in an image request or iframe stored on various sites under the attacker’s control: • ESAPI HTTPUtilities Class with AntiCSRF Tokens <img src="http://example. iframes. However. Am I Vulnerable to CSRF? How Do I Prevent CSRF? To check whether an application is vulnerable. Play. performing any the affected data or users’ browsers. Consider using the “SameSite=strict” flag on all cookies. session cookies automatically. details. Otherwise. modifying data). to your reputation. and other HTTP request. at a minimum. For example: • OWASP CSRF Article http://example. Consider the impact your users visit. attackers can forge malicious requests. or various generate forged requests that are perform (e. The preferred option is to include the unique token in a requests. and AngularJS. 3. If updating account take these actions. • Wikipedia article on CSRF . making HTML feed that authenticated. penetration testing or code analysis.com/app/transferFunds?amount=1500 &destinationAccount=4673243243 • OWASP CSRF Prevention Cheat Sheet So. such as through reauthentication.

The impact application. or with 3. XSS. In some injection. Am I Vulnerable to Known Vulns? How Do I Prevent This? The challenge is to continuously monitor the components Most component projects do not create vulnerability patches (both client-side and server-side) you are using for new for old versions. may be harder to exploit. carefully evaluate whether you are actually components are never loaded or invoked. data flow. the exact component in a product family that has the 1.) • Struts 2 Remote Code Execution – Sending an attack in the • MITRE Common Vulnerabilities and Exposures (CVE) search Content-Type header causes the content of that header to • National Vulnerability Database (NVD) be evaluated as an OGNL expression. vulnerable.g. Worst of all.. Software projects should have a process in place to: them hard to find and search for the details you need (e.. Continuously inventory the versions of both client-side vulnerability).g. and prevents vulnerabilities from being exploited. and announcements for anything that might be a vulnerability. or code execution perform as vulnerability reports can be deliberately vague. 2. making changes. retire. which can require other code because vulnerability reports are not standardized. DependencyCheck. by the affected automated tools. • Ruby Libraries Security Advisory Database and Tools used deeper in an application. Use software composition analysis databases. vulnerabilities. This monitoring can be very difficult upgrade to the next version. • The Unfortunate Reality of Insecure Libraries not to be confused with the Apache Application Server. Check to see if your code uses the vulnerable part 4. etc.NET libraries) intentional (e. This process can be done manually. weak component issues because their development teams weaknesses is vulnerability might framework libraries) through scanning or don’t focus on ensuring their components possible. . If a vulnerability in a component is runtime before making changes. Some example • OWASP Virtual Patching Best Practices exploitable component vulnerabilities discovered are: • Apache CXF Authentication Bypass – By failing to provide an identity token. backdoor in component). Using Components with Known A9 Vulnerabilities Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific AVERAGE COMMON AVERAGE MODERATE Business Specific Some vulnerable Attackers identify a Many applications and APIs have these The full range of Consider what each components (e. as well as keeping abreast of project mailing lists tools to automate the process. coding error) or • OWASP Dependency Check (for Java and . It could expanding the and execute the mind their versions. Such flaws can be accidental (e. (Apache CXF is a services framework. never etc. Decide whether to upgrade component (and rewrite of the component and whether the flaw could result in an application to match if needed) or deploy a virtual patch impact you care about. in the application. the developers don’t even know all access control. which enables execution of arbitrary code on the server. broken business controlled and exploited with They customize the cases. • Retire.js for detecting known vulnerable JavaScript libraries Applications using a vulnerable version of either component • Node Libraries Security Advisories are susceptible to attack as both components are directly accessible by application users. including mean for the can be identified manual analysis. Other vulnerable libraries. Both checks can be difficult to that analyzes HTTP traffic. using tools like versions. Continuously monitor sources like NVD for vulnerabilities Determining if you are vulnerable requires searching these in your components. minimal to mean complete beyond targeted difficult if the used Tools are becoming commonly available complete host compromise. attackers could invoke any web service External with full permission. Analyze libraries to be sure they are actually invoked at automated tools. So the only way to fix the problem is to vulnerability reports.. so flaws in any component can result in serious impact.. as the majority of discovered. compromise. attackers to include component is deep to help detect components with known takeover and data chaotic actors. many vulnerabilities never get and server-side components and their dependencies reported to central clearinghouses like CVE and NVD. Component could range from be trivial or it could threat agent pool attack.g. and libraries are up to date.js. It gets more dependencies make things even worse.g. exploit as needed the components they are using. Example Attack Scenarios References Components almost always run with the full privilege of the OWASP application.

mobile. endpoints) can be vulnerable to the full destruction. just as in a traditional application. protocols and complex data structures. • What Do You Mean My Security Tools Don’t Work on APIs?!! In either of these cases. Some applications and APIs create their from being improperly invoked. can help. These factors can 3. vulnerabilities can and sometimes even static tools don’t to the entire critical. Example Attack Scenarios References Scenario #1: Imagine a mobile banking app that connects to OWASP an XML API at the bank for account information and performing transactions. Ensure that you have a strong authentication scheme for However. just as viable through APIs as they are for normal apps. Protect against injection of all forms. Ultimately. discovered. functions? Many communications are Some API range of attacks. Some frameworks like GWT and some RPC implementations 4. The use of widely-used formats the parser configuration is hardened against attack. Unfortunately. vulnerabilities are often undiscovered. and XML. possibly leading to a false sense of security. access control. All the understand the threat model and what defenses you have: different types of injection. JSON. making security testing more difficult. . the business. GWT. including data theft. APIs (microservices. The attacker reverse engineers the • OWASP REST Security Cheat Sheet app and discovers that the user account number is passed as • OWASP Web Service Security Cheat Sheet part of the authentication request to the server along with the username and password. Am I Vulnerable to Attack? How Do I Prevent This? Testing your APIs for vulnerabilities should be similar to The key to protecting APIs is to ensure that you fully testing the rest of your application for vulnerabilities. 1. knowing if your APIs are secure means carefully Be sure your security analysis and testing covers all your APIs choosing a strategy to test all defenses that matter. the vendor may not provide a web UI • State of API Security to use these services. The breadth function and data references. configuration. but another user’s account number. takeover. that make security testing difficult. so also so obscurity is no be automatically work well on APIs. and they can be application. RPC. The API parses out this “transactionid” value as a string and • The API Centric Future concatenates it into a SQL query. services. keys. As you can see the API is just as susceptible to SQL injection as any other type of application. 2. and your tools can discover and analyze them all effectively. REST. others difficult to analyze manually. and consider the impact defense for APIs. Does your APIs. so these complete host of denial of service only by experts. Client client code. without escaping or • The Growth of the API parameterizing it. attacks. A10 Underprotected APIs Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact Application / Application Specific AVERAGE COMMON DIFFICULT MODERATE Business Specific Consider anyone Attackers can Modern web applications and APIs are The full range of Consider the impact with the ability to reverse engineer increasingly composed of rich clients negative outcomes of an API attack on send requests to APIs by examining (browser. gaining full External access to the other user’s account. and other issues can exist in APIs the client and your APIs. desktop) that connect is possible. dynamic unauthorized access APIs are mission easily intercepted. corruption. such as Swagger (OpenAPI). JSON. the API access software is easily simply monitoring custom). because APIs are designed for use by programs (not your APIs. The API • Tracking the Growth of the API Economy accepts JSON messages that contain a “transactionid” field. like WebSockets. and tokens have humans) they frequently lack a UI and also use complex been secured. and complexity of APIs make it difficult to automate effective 5. as these attacks are security testing. The attacker sends legitimate credentials. and that all credentials. • Increasing Importance of APIs in Web Development Scenario #2: Imagine a public API offered by an Internet startup for automatically sending text messages. Ensure that you have secured communications between encryption. or to backend APIs (XML. including unauthorized own protocol and data formats. and critical data or reversed and communications. authentication. Ensure that whatever data format your requests use. Implement an access control scheme that protects APIs use custom formats.

and many OWASP documents can be ordered in hardcopy or as eBooks. There are numerous additional OWASP resources available for your use. To stay Education current. Application OWASP recommends you use the OWASP Application Security Verification Standard (ASVS). +D What’s Next for Developers Establish & Use Repeatable Security Processes and Standard Security Controls Whether you are new to web application security or are already very familiar with these risks. Most OWASP resources are available on our wiki. the task of producing a secure web application or fixing an existing one can be difficult. this task can be daunting.0.1 being released mid 2016. OWASP NodeJS Goat. To improve the process your organization follows when building applications and APIs. A significant update to Open SAMM was released in 2017. The Cheat Sheets have been updated and expanded significantly since the 2013 Top 10 was released. come to an OWASP AppSec Conference. etc. If you have to manage a large application portfolio. ESAPI provides a reference implementation in Java. The OWASP Education Project provides training materials to help educate developers on web Application application security. with version 3. OWASP has produced numerous free and open resources that you can use to address application security in your organization. Please visit the OWASP Projects page. To help organizations and developers reduce their application security risks in a cost effective manner.NET. CSRF. Security WebGoat. and Incubator projects in the OWASP project inventory. you must define what secure means for that application. OWASP Conference Training. OWASP recommends the Security OWASP Enterprise Security API (ESAPI) project as a model for the security APIs needed to produce Controls secure web applications and APIs. OWASP Secure recommends the OWASP Software Assurance Maturity Model (SAMM). or local OWASP Chapter meetings. consider the OWASP Secure Software Contract Annex. Rather than retrofitting security into your applications and APIs. On the next page. OWASP recommends the OWASP Prevention Cheat Sheets Security and the OWASP Developer’s Guide as good starting points for guidance on how to design security Architecture in from the beginning. which lists all the Flagship. This model helps Development organizations formulate and implement a strategy for software security that is tailored to the Lifecycle specific risks facing their organization. try OWASP WebGoat. If you’re outsourcing. validation. Building strong and usable security controls is difficult. ASVS has been updated Requirements significantly in the past few years. it is far more cost effective to Application design the security in from the start. . or the OWASP Broken Web Applications Project. To produce a secure web application. we present additional OWASP resources that can assist organizations in verifying the security of their applications and APIs. Many popular frameworks come with standard security controls for authorization. Using a set of standard security controls Standard radically simplifies the development of secure applications and APIs. The following are some of the many resources OWASP has produced to help organizations produce secure web applications and APIs. For hands-on learning about vulnerabilities. as a Security guide for setting the security requirements for your application(s). Labs.

so if you don’t have one. Look to enhance existing development pipelines with security automation that doesn’t slow development. Be sure to consider the Strategies human resources required to deal with false positives as well as the serious dangers of false negatives. So we strongly encourage you to put some thought into how you are going to focus on what’s important across your entire application portfolio. That means expanding the set of security defenses and risks that Coverage and are being automatically verified. No matter how good you are at testing. Whatever approach you choose. Describe clearly Make Findings how it can be abused without “lingo” and include an attack scenario to make it real. deliver findings in the tools development teams are already using. The work is difficult and complex. the Threat Consider using OWASP ASVS and the OWASP Testing Guide as an input and don’t rely on tool Model vendors to decide what’s important for your business. and do it cost-effectively. and reviews are likely to cause friction. The goal is to get to where the essential security of all your applications and APIs is verified continuously. and modern high-speed development processes like Agile and DevOps have put extreme pressure on traditional approaches and tools. Build trust by showing you understand how the application works. triage. fastest. correctly implemented. retest. Attempts to force Your SDLC extra steps. . The goal of application security testing is to provide this evidence. remediate. Choose the simplest. it won’t make any difference unless you communicate it effectively. as well as expanding the set of applications and APIs being Accuracy covered. multiplied by the size of your application portfolio. Understand processes. get bypassed. most accurate technique to verify each requirement. Modern software development requires continuous application security testing across the entire software development lifecycle. Modern risks move quickly. Finally. The OWASP Benchmark Project. and redeploy a single application. You don’t have to start out testing everything. and struggle to scale. and tools you use in your software development lifecycle (SDLC). so the days of scanning or penetration testing an application for vulnerabilities once every year or so are long gone. be sure you understand what’s important to spend time on. Look for natural opportunities to gather security information and feed it back into your process. which helps measure the ability of security tools to detect many OWASP Top Testing 10 risks. and how bad that would be. consider the annual cost to test. Focus on what’s important and expand your Achieving verification program over time. gates. you need to create one before testing. Your approach to application security testing must be highly compatible with the people. not PDF files. But it’s critical to verify that the security you intended to build is actually present. and used everywhere it was supposed to be. Make a Awesome realistic estimation of how hard the vulnerability is to discover and exploit. Before you start testing. may be helpful in selecting the best tools for your specific needs. Priorities Understand come from the threat model. +T What’s Next for Security Testing Establish Continuous Application Security Testing Building code securely is important.

software development. Secure Design & Review. •Identify and prioritize your application portfolio from an inherent risk perspective. Penetration Testing. It also requires focus on the activities and outcomes that actually help improve enterprise security by reducing risk in the most cost effective manner. Metrics include adherence to security practices / activities. Secure Coding & Security into Code Review. •Conduct a capability gap analysis comparing your organization to your peers to define key Get Started improvement areas and an execution plan. Some of the key activities in effective application security programs include: •Establish an application security program and drive adoption. Activities include Threat Modeling. application coverage. Achieving application security requires many different parts of an organization to work together efficiently. organizations must establish an effective capability for securing their applications and APIs. •Establish a set of focused policies and standards that provide an application security baseline for all development teams to adhere to. Existing •Provide subject matter experts and support services for development and project teams to be Processes successful. including security and audit. so that all the different players can see and understand the organization’s application security posture. Between increasing attacks and regulatory pressures. many organizations are struggling to get a handle on the enormous volume of vulnerabilities. •Define and integrate secure implementation and verification activities into existing development and Integrate operational processes. Visibility •Analyze data from the implementation and verification activities to look for root cause and vulnerability patterns to drive strategic and systemic improvements across the enterprise. Approach •Establish a common risk rating model with a consistent set of likelihood and impact factors reflective of your organization's tolerance for risk. It requires security to be visible. •Gain management approval and establish an application security awareness campaign for the entire IT organization. vulnerabilities introduced. •Manage with metrics. Enable with a •Define a common set of reusable security controls that complement these policies and standards and Strong provide design and development guidance on their use. Drive improvement and funding decisions based on the metrics and analysis Provide data captured. OWASP recommends that organizations establish an application security program to gain insight and improve security across their application portfolio. Foundation •Establish an application security training curriculum that is required and targeted to different development roles and topics. and business and executive management. etc. defect density by type and instance counts. and Remediation. Portfolio •Establish assurance guidelines to properly define coverage and level of rigor required. Given the staggering amount of code in the numerous applications and APIs already in production. Management vulnerabilities mitigated. . Risk Based •Create an application risk profiling model to measure and prioritize all your applications and APIs. +O What’s Next for Organizations Start Your Application Security Program Now Application security is no longer optional.

These factors get updated with each new Top 10 release as things change. technical impacts. All other risks ranged from widespread to uncommon (value 1 to 3). 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. weaknesses. attack vectors. we have been supplied prevalence statistics from a number of different organizations (as referenced in the Attribution section on page 4) and we have averaged their data together to come up with a Top 10 likelihood of existence list by prevalence. This rating also does not take into account the actual impact on your business. Any of these factors could significantly affect the overall likelihood of an attacker finding and exploiting a particular vulnerability. 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. However. You are best equipped to judge the importance of your applications and data. Consequently. as an example. The purpose of the OWASP Top 10 is not to do this risk analysis for you. +R Note About Risks It’s About Risks. and regulatory environment. 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 OWASP Risk Rating Methodology defines numerous factors to help calculate the risk of an identified vulnerability. For prevalence data. industry.” the OWASP Top 10 has always been organized around risks. The following illustrates our calculation of the risk for A3: Cross-Site Scripting. The prevalence of a weakness is a factor that you typically don’t have to calculate. and business impacts combine to produce risks. Your organization will have to decide how much security risk from applications and APIs the organization is willing to accept given your culture. Not Weaknesses Although the 2007 and earlier versions of the OWASP Top 10 focused on identifying the most prevalent “vulnerabilities. For each Top 10 item. detectability. This focus on risks has caused some understandable confusion on the part of people searching for an airtight weakness taxonomy. Nor does it account for any of the various technical details associated with your particular application. This version of the OWASP Top 10 continues to follow the same methodology. we can never be as precise as system owners can be when calculating risks for their application(s). and ease of exploit) and one impact factor (technical impact). XSS is so prevalent it warranted the only ‘VERY WIDESPREAD’ prevalence value of 0. Attack Security Technical Business Threat Vectors Weakness Impacts Impacts Agents Exploitability Prevalence Detectability Impact App / Business App Specific AVERAGE VERY WIDESPREAD EASY MODERATE Specific 2 0 1 2 1 * 2 2 . rather than specific vulnerabilities in real applications and APIs. We then rank ordered the Top 10 according to those weaknesses that typically introduce the most significant risk to an application. The OWASP Top 10 for 2010 clarified the risk-focus in the Top 10 by being very explicit about how threat agents. Our methodology includes three likelihood factors for each weakness (prevalence. the Top 10 must talk about generalities. what your threats are. The Risk Rating methodology for the Top 10 is based on the OWASP Risk Rating Methodology. and how your system has been built and is being operated. Note that this approach does not take the likelihood of the threat agent into account.

including new attack techniques that are being identified all the time. you must consider your own specific threat agents and business impacts. Data App Specific DIFFICULT UNCOMMON AVERAGE SEVERE App Specific A7-Attack Prot. but there are many other risks you should consider and evaluate in your organization. App Specific EASY COMMON AVERAGE MODERATE App Specific A8-CSRF App Specific AVERAGE UNCOMMON EASY MODERATE App Specific A9-Components App Specific AVERAGE COMMON AVERAGE MODERATE App Specific A10-API Prot. 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. Attack Security Business RISK Threat Vectors Weakness Technical Impacts Impacts Agents Exploitability Prevalence Detectability Impact A1-Injection App Specific EASY COMMON AVERAGE SEVERE App Specific A2-Authentication App Specific AVERAGE COMMON AVERAGE SEVERE App Specific A3-XSS App Specific AVERAGE VERY WIDESPREAD AVERAGE MODERATE App Specific A4-Access Ctrl App Specific EASY WIDESPREAD EASY MODERATE App Specific A5-Misconfig App Specific EASY COMMON EASY MODERATE App Specific A6-Sens. see: OWASP Deserialization Cheat Sheet • Expression Language Injection (CWE-917) • Information Leakage (CWE-209) and Improper Error Handling (CWE-388) (Was part of 2007 Top 10 – Entry 2007-A6) • Hotlinking Third Party Content (CWE-829) • Malicious File Execution (CWE-434) (Was 2007 Top 10 – Entry 2007-A3) • Mass Assignment (CWE-915) • Server-Side Request Forgery (SSRF) (CWE-918) • Unvalidated Redirects and Forwards (CWE-601) (Was 2013 Top 10 – Entry 2013-A10) • User Privacy (CWE-359) . Other important application security risks (in alphabetical order) that you should also consider include: • Clickjacking (CAPEC-103) • Denial of Service (CWE-400) (Was 2004 Top 10 – Entry 2004-A9) • Deserialization of Untrusted Data (CWE-502) For defenses. and others have not. Some of these have appeared in previous versions of the Top 10. +F Details About Risk Factors Top 10 Risk Factor Summary The following table presents a summary of the 2017 Top 10 Application Security Risks. To understand these risks for a particular application or organization. Even egregious 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. App Specific AVERAGE COMMON DIFFICULT MODERATE App Specific Additional Risks to Consider The Top 10 covers a lot of ground.