• Page 13 - A6 - Sensitive Data Exposure - Example Attack Scenarios - says "Scenario #2: A site simply doesn’t use TLS for all authenticated pages." which, in my opinion, should be written as "Scenario #2: A site simply doesn’t use TLS 1.1/1.2 for all authenticated pages." – No change. The point is that they aren’t using TLS (or SSL) at all. Not specific versions of TLS.

13. Graeme Wicksted

Dear repository owner,

this repository seems either empty or abandoned on GitHub. In order to clean up the https://github.com/owasp organization, please acknowledge or veto the deletion of this repository.

No response will be interpreted as evidence for the obsolescence of this repository and it will be deleted at some point in time.

Thank you for helping to clean up the OWASP GitHub org!

Cheers,
Björn (@bkimminich)

With having all cloud services and lots of solutions to host different resources on different servers, we see more SSRF attacks these days with which attackers can target another server or another internal port and so on. I thought we should see SSRF now in OWASP top 10 but you have all the stats so it might be good too.

Soroush Dalili

A7 - Insufficient Attack Protection

• WAF and other blocking detection mechanism will never fully protect against unknown vulnerability. The thing is that they either break your application through aggressive blocking or have bypass when they aren't aggressive. Those products have always been crutches for applications that had poor security or couldn't be updated. Saying that you are vulnerable because you don't have one in place is really misguided.
• Incident response is operational concerns. It's not an application security concern. Unless the OWASP Top 10 guide wants to enlarge its scope to more than just application security, this is simply not at the right place. The ASVS guide is probably a better place to introduce this.
• Patching software is already covered by A5 and A9. The point #1 of "Am I vulnerable to Attack?" of A5 is exactly about that : "Is any of your software out of date?". Perhaps this point should be expanded in A5 or A9 instead.
• The OWASP Top 10 is a general document for application security. It should be about things that apply to almost every web application. I wouldn't recommend that every web application should to lock account automatically. This kind of security measure is a trade-off between usability, security and introducing other security issues (denial of service for example). OWASP Top 10 may recommend evaluating this choice, but I don't think it should pick a side especially since it can have security impact like denial of service (ex.: locking all user account).
• This category addition really feels like it's been lobbied by the WAF industry as a way to sell more of their product. One of the core values of the OWASP organization is that it shouldn't be a platform for vendors to sell their products. Adding categories that favourably affects some vendor should be weighted more carefully.

8. Olivier Arteau

Hi folks. Imagine this 2 scenarios:

• you find an API vulnerable, let say do SQL injection. Is it a A1, A7 or A10 risk category?
• you find an API vulnerable to remote code execution. Which is the one to use A7 or A10?

4. "A10 - Underprotected APIs" is obviously covered by the other 9 items, but it's not a bad idea to raise awareness on them. I still see lots of developers who think that HTML forms are the only attack surface of a web application. So like XSS and CSRF are injection attacks, it's not a bad idea to focus on them for a while. Maybe we should change A10 to SSRF in 2020? Keeping the last one for awareness isn't a bad idea...
   Overall, I'm quite pleased with the new Top 10 as I feel they better reflect what I've been seeing in my assessments. 2017 is definitively better than the 2013 version, so good job!! ;)

11. David Caissy

I've heard a lot of criticism about the proposed OWASP top ten from the pentesting community:
The biggest is that A7 sounds like a thinly-veiled ploy to promote IPS/WAF products. Other people's paraphrased words, not mine, but I do tend to agree. I seem to recall similar concerns were raised about A9 last time around, since there were commercial products that tackle this problem being sold by some involved in the project. Do we want the pentesting community to see the top 10 as being hijacked by commercial interests?
Timothy D. Morgan

Other things I take issue with. Some syntax, some semantics, some about priorities:
The description for A1 reads: "Injection flaws, such as SQL, OS, XXE, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization."
Two problems with this:

• What is OS injection? Is that where you take a VM and insert it into a host OS? Or maybe it has something to do with containers? I think what you mean to say is "shell command injection".
• XXE isn't an injection flaw. I happen to be an SME on this. It's not an injection, really. XML injection is an injection, but that's a different kind of bug. XXE is also extremely common in modern applications and deserves to have a much higher profile than being lumped in with a bunch of things that are very different.

6. Timothy D. Morgan

Hi,

I've read all the Top 10-2017 RC and gave a comment if I suggest to change some content. I did not
focus solely on A7 and A10, but they are obviously included in my suggestions. As I was part of the
team that translated the Top 10 -2013 in German, so I've also recapped my remarks I've made when we
were translating that Top 10.

I've compiled all my comments now into the pptx file to see if the changed parts could fit. All
changes are highlighted by using green font and comments (sometimes containing background
information why I'd suggest a change).
I'm sorry, I am not a native speaker, so I hope you can always understand what I mean.

OWASP Top 10 - 2017 RC1-English_Comments_from_Torsten_20170609.pptx

There might fit also

• a table of contents at the beginning (see comment on 'O', we've already added one at
  https://www.owasp.org/images/4/42/OWASP_Top_10_2013_DE_Version_1_0.pdf)
• a new page '+A(M) What's Next for Application Managers' describing the lifecycle processes to
  tender a software, to implace the application and its components, to maintain them, to change
  it, to retire it while keeping data for post production and finally to delete all data, software
  and components (no comments added about this in the pptx).

I hope it helps for the discussions at the OWASP Summit and compiling the RC2/final document.

Cheers
Torsten (Gigler)
Peposted from Mailing List as requested (http://lists.owasp.org/pipermail/owasp-topten/2017-June/001510.html)

Emailing you directly just because i'm too lazy to sign up for a mailing list I know I probably won't read. These aren't private comments, I'm happy for them to be made public or forwarded to the mailing list or whatever.
The content of the Top 10 2017 RC look great. I completely agree with the changes, with the one exception...
... the title of A7 "Insufficient Attack Protection", doesn't really match the content:
Detection, Response and Remediation aren't protective or preventative measures, they're responsive measures
"Insufficient Attack Protection" on naive reading (without reading the risk content), sounds like it could mean "you haven't bought enough vendor shit to protect your website". This is misleading, and could be misused
In it's place, I'd like to see something like "Insufficient Attack Response" or something similar.
Actually this is a way better suggestion than mine https://twitter.com/mik235/status/852055872234770432

9. Liam Oshan

For A9, how do I prevent, step 4:

Decide whether to upgrade component (and rewrite application to match if needed) or deploy a virtual patch that analyzes HTTP traffic, data flow, or code execution and prevents vulnerabilities from being exploited.

why not something on if can put mitigations in calling code to do that either instead of or after WAF if that option exists.

12. Mike Boberski:

What should the Top 10 list be based on:

1. Stay as it is - Initial call for data and then the Top 10 produced based on the data plus the judgement of the project leaders/authors.
2. Entirely data based - Top 10 based purely on the data gathered together with some normalisation or weightings?
3. Data based with consensus - Top 10 initially based on normalised/weighted data but also modified based on community discussion/consensus.

My personal preference would be option 3.

Osama Elnaggar

pg. 9 - A2 Broken Authentication & Session Management
In the "How Do I Prevent This?", I would probably add the recommendation to use well known and tested frameworks that tackle these issues (Apache Shiro, Spring Security, etc.) instead of recommending providing an interface similar to ESAPI Authenticator and User APIs. Almost all frameworks come with mature authentication and authorization frameworks that can be leveraged. Trying to roll out your own as most development teams would probably develop in-consistent and in-secure interfaces

From @danielmiessler

TABLE 1. — THE CURRENT PROPOSED 2017 LIST (APRIL 2017).

This brings me to the reason I moved away from “Top 10” for the OWASP IoT Security Project. With that project, the Mobile Security Project, and virtually every other list-based effort that I’ve encountered, I’ve seen the project team run into the same wall.

They’re mixing different types of security issues into a single list.

What we’ve done with these different OWASP projects is collect different forms of “bad things”, which can include any of the following:

Vulnerabilities
Threats
Risks
Miscellaneous Bad Hombres
Etc.
The differences between these are quite important, and blending them all together into a single list can be problematic. But the biggest problem is when people on the project team don’t agree on the definitions, their differences, or whether or not it’s ok to mix them in a single list.

So let me just ask you, dear reader: What is the OWASP Top 10 a list of?

Is it a list of vulnerabilities? Not really. Injection isn’t a vulnerability; it’s a category of vulnerability. Same with Auth and Session Management, Access Control, Security Misconfiguration, etc. Then you have XSS and CSRF that are individual vulns.

So we have a list of 10 somethings—and on that list we have a mix of parents and children, containers and contents, buckets and water. That kills me. Always has. Especially since people don’t usually realize it’s happening during the discussion, and even when they do we can’t agree on terms.

So then we have Underprotected APIs. That’s not even a category. And it’s definitely not a vulnerability. It’s like a…thing. And I love it actually. I think it’s a good item to be on the list. But what is it? And does it belong on this list?

Hard to say.

MY THOUGHTS ON OWASP LISTS

So here are some of the ideas I’ve had regarding this composite listing problem.

I think we need more discreet and granular lists that clearly indicate what they are and who they’re for. In the IoT Security project we’re doing this by having more sub-projects within the project. We’re trying to break vulnerabilities into vulnerabilities, attack surfaces into attack surfaces, risks into risks, etc. I don’t want to cross the streams. I’ve not solved the problem, but that’s what we’re working towards.

I think the OWASP Top 10 could benefit greatly be calling itself what it is—a list of things to consider and avoid when building web applications. That’s not pretty. It’s not catchy. It doesn’t sound as cool as “Top 10 Vulnerabilities”. But it’s more honest. If it’s functional to make it a composite list, then lets do it. But let’s not lie to ourselves about it.

Perhaps it could be the Top 10 Risks—if we were to argue that each item includes probability and impact not just within each vulnerability but in relation to each other. In other words, the project team says something like:

We the OWASP Top 10 Team have studied x amount of data and have ranked not only the prevalence but the impact of all these issues as they relate to overall web application risk. The list is a composite of vulnerabilities, categories of vulnerabilities, and considerations, and we’ve determined that this is the order in which you should work to prevent these types of issues within your own web applications.

I don’t know that they are saying that, or that they can based on the data they have considered, or that they would even want to. Is the number actually a rank of priority, or is it just a designation so you can keep track? Not everyone knows the answer to that, and it should be more clear.

SUMMARY

This is a hard problem, and I applaud the work that has been done.

The TL;DR here for me is that I think this is a great list of things for developers to avoid doing in their own applications, but I’m not happy with the seemingly confused way we get there. Not just in this project, but in all similar projects. We’re just throwing things in these lists with no regard for taxonomy, hierarchy, or any other structure. That would be ok with me if we were explicit about that, but I don’t think we are.

I think more clarity on said structure could help significantly.

Hopefully my comments are taken with the love that produced them, and can lead to some additional conversation and/or clarity around the structure of not just this list, but other OWASP projects going forward.

Happy to be part of that conversation if anyone wants to engage.

Would it make sense to publish the proposed Top 10 list without writing the full document so as to gather feedback on the suggested Top 10 before embarking on the full document creation?

Would it make sense to have an open/rolling call for data?

In this model, companies can submit data in a pre-agreed, specific format when they are able to without waiting for a particular "call for data" window.

A cut-off would need to be defined for each version of the Top 10.

The submission format would need to include a more exact date range for the data to make comparison easier.

Osama Elnaggar

pg. 12 - A6 Sensitive Data Exposure
In the "How Do I Prevent This?", I would add not to use the default crypto keys used by some frameworks and to generate your own. Many frameworks allow a single secret key to generate "recover my account" URLs, encrypt data stored on the client side, etc. These aren’t “weak” keys, but they are known keys that can be abused by an attacker

• This category can be summarized to "Check the OWASP Top 10 for API endpoints too". This isn't a category of vulnerability. This should be integrated through all the other vulnerabilities by specifically mentioning checking API endpoint too. It might also be better to add a section in the document titled "What to test ? Where to look for vulnerability ?".

8. Olivier Arteau

A7 - Insufficient Attack Protection seems overly general. It seems to be a catch all to cover many topics such as:
• Bad input validation
• Poor application update/modification support
• Insufficient logging or reporting
• lack of rate-limiting
The topic seems to be driven by WAF as a solution rather than by the underlying problems.
My suggestion would be to either break this topic up into a few different issues or rename the topic to Integrate a WAF into your application.

7. Joseph Salowey

It is good to include this as a risk especially with all automated tools against all the applications but at the moment someone may argue that this is not a problem that developers can solve (to pass the ball)! As its definition is vague, it can be considered an issue for network teams to firewall an application. Also, is IP/attacker blocking the main part of this issue? Or is it more about detecting the attacks by raising some alarms. Shall we for example report an issue like this if it does not block attackers for a period of time but stop some certain requests? Shall we count technologies such as .net request validation an insufficient attack protection technique considering it is only useful for a portion of XSS issue? Does blocking an attacker for 5 minutes after sending 20 malicious requests consider as an insufficient technique?
I just wanted to say that perhaps we need more clarification on this to be able to measure it when a solution is there but is not sufficient.

Soroush Dalili

• One of the common errors that I see in CSRF implementation is that tokens are generated, but they are not validated server-side. As stupid as this may seem, it's surprisingly common. I would propose that the "Am I Vulnerable to CSRF?" mentions checking if invalid CSRF tokens are rejected on top of checking if the CSRF tokens are present in the forms.

8. Olivier Arteau

Osama Elnaggar

pg. 8 - A1 Injection
I think dropping the mention of OWASP ESAPI would be better as even its authors are no longer recommending its use (https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Should_I_use_ESAPI_3F) in addition to the following: "Given that I'm the ESAPI project co-lead, you might think I'd be more inclined to recommend ESAPI, but I don't except in rare cases" - http://lists.owasp.org/pipermail/esapi-dev/2017-February/002656.html
I think that mention of ESAPI should be removed across the standard.

In A8 in the section How Do I Prevent CSRF you wrote:

[...] such as Spring, Play, Django, and AngularJS.

You're linking to the Docs of the new Angular version which is just called Angular. AngularJS is version 1.x.

Possible options:

1. Stay as it is - top 10 list of application security risks based with some aggregation of categories?
2. Change to a "league table" of specific CWEs purely based on data gathered?
3. Evolve to consider wider issues in application security - this seems to have been the rationale behind "2017 RC1 A7 - Insufficient Attack Protection"?
4. Something else...?

My personal preference is option 2 with greater focus given to the OWASP Top 10 Proactive Controls or failing that, option 1.

Finally, what exactly is A10? Um... it's almost like an answer to a different question. The top 10 has traditionally been an answer to "what kinds of flaws might affect my application". This is an answer to the question "where in my application might there be flaws". It seems like filler. why not call out deserialization bugs here instead? People get badly owned by those. They actually matter.

6. Timothy D. Morgan

pg. 7 - T10 OWASP Top 10 Application Security Risks - 2017

In A4, I would remove the word "authenticated" in "Restrictions on what authenticated users are allowed" as unauthenticated users can also exploit IDORs and function level access controls (although it is more common for this to be an issue with authenticated users).

These CORS risks seem to be very prevalent and will probably become the new XSS for AJAX.
Re: http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html
Include?
Brad Barkett

Hi Dave,
So, I took a crack at some modified wording for the main section (Am I vulnerable to attack) designed to try and emphasize the point around the application defending itself. Other suggestions, along the lines of things I've seen elsewhere, might be to look at changing the title, perhaps something like "Insufficient Active Application Defences", also the 3rd point in "How do I prevent this" around virtual patching seems to not quite fit with what the rest of the section is about, and could introduce a bit of confusion about what's being suggested...
Am I Vulnerable to Attack?
Detecting, responding to, and blocking attacks makes applications dramatically harder to exploit yet almost no applications or APIs have in-built protection against such attacks.
Whilst most applications will provide some active attack protection with defences like account lockout, deployment of an active defence strategy is generally very limited.
It should be very obvious if attack detection and response isn’t in place. Simply try manual attacks or run a scanner against the application. The application or API should identify the attacks, take action to block the attack and restrict the attacker's ability to continue to attempt to compromise the system, and provide details on the attacker and characteristics of the attack.
Be sure to understand what types of attacks are covered by attack protection. Is it only XSS and SQL Injection? Ideally an application should be able to detect and respond to a wide variety of issues.
Whilst ideally applications would have attack protection capabilities built into the codebase, for example using the OWASP AppSensor framework, where that is not possible external technologies such as WAFs can be used to provide a level of active attack protection.

14. Rory McCune

... my suggestion would be to add the qualifier in addition to the examples. "Certainly of course this does not mean hacking back" etc. There is no way at some point someone doesn't get hung up on that..

For Risk, the reference to Microsoft Threat Modeling Tool seems out of place since that's not the approach the T10 diagrams take. The FAIR stuff is little left field. Is a little jarring/top of mind since rolling out Microsoft TMT at VA is all. Limited tool choices of course and spotty OWASP info on the topic. Maybe consider a standalone threat modeling page with 1 cohesive suggestion/view. T10 is getting pretty big though at this point especially as it pivots to devops etc.

12. Mike Boberski:

https://github.com/OWASP/OWASP-Top-10

pg. 14 - Insufficient Attack Protection
"Attackers, known users or anonymous, send in attacks". The "send in attacks" kind of sounds strange. This is the first time I have ever heard the phrase, so I even googled it and found only 9 hits.

• I think the Top 10 should split the "Sensitive Data Exposure" into two categories : "Sensitive Data Exposure" and "Incorrect Cryptography Usage". The problem with cryptography is not just with whether you are using the right or wrong algorithm (primitive), it's also about how you assemble the whole thing. "Sensitive Data Exposure" focuses only on whether the primitive you are using are good (ex.: don't use RC4, MD5, etc.). From experience a lot of the issues with cryptography that I see come from the misassembling of the cryptography primitive. They pick "AES" ... but with the default mode ECB. They pick "AES/CBC" ... but they forget to use HMAC too (that almost always leads to padding oracle). They use "AES/CBC + HMAC" ... but they MAC before they encrypt. They pick "AES/GCM" or "AES/CBC + HMAC" ... but they individually encrypt different parameters (this leads to parameters swapping attack). They pick "SHA256" ... for password storage. Cryptography is a very hard field that has many caveats and every subtle mistake can potentially break the whole thing. This is, in my opinion, a lot more deserving than A7 and A10.

8. Olivier Arteau

Static Analysis providers are able to count every instance of a vulnerability they see in an application as opposed to dynamic analysis/security testers where it is more likely that they will only track whether a vulnerability appeared in an application or not.

This could skew the data considerably. Does the current data analysis take this into account?

How should this be done going forward?

Jeremiah's tweet regarding A0 (https://twitter.com/jeremiahg/status/851562562634137600) isn't actionable by developers and is more in the domain of operations or governance whereas A7 is. A7 just needs to be re-worded and I think split up into:

• as a developer, how are you going to detect attacks?
• as a developer, how are you going to protect against detected attacks?
• as a developer, how are you going to enable quick patching when either your application is vulnerable or the 3rd party libraries you use are?
  For the first, a developer could take the initiative to log all sensitive actions in the application + things that violate the security policy defined when they tackled the other OWASP Top 10 areas. They can then decide to output this in JSON so they can be easily consumed by logging solutions within the environment and to feed their SOC teams with the necessarily visibility.
  Tackling protection is more difficult for a developer but there are libraries that developers can use to help protect against brute forcing. These won't protect against all attacks but can at least protect against things such as password brute-force attacks quite easily. At the very least, the developer can ensure that these will be detected and that they are providing their security operations teams with the necessary logs to detect these attacks.
  The last one is probably the most difficult for a developer to tackle as this is border-line outside the scope of the developer. But then again, the "Security Misconfiguration" and "Using Components with Known Vulnerabilities" are also borderline outside the scope of the developer. A developer may launch their application with components that are up-to-date and don't have know vulnerabilities but this isn't going to last for long. Slide 13 from Jeremiah's talk about Cyber Insurance (https://www.blackhat.com/docs/us-16/materials/us-16-Grossman-An-Insiders-Guide-To-Cyber-Insurance-And-Security-Guarantees.pdf) covers the average time to fix in days for Known web vulnerabilities found with the average around 130 days. So this last point is basically saying: bugs will be found on your site. How quickly will you patch them (either permanently in the code if the vulnerability is in your code and not a 3rd party component or virtually using a WAF, RASP, etc. until it can be fixed and a new deployment rolled out)? Having this issue on the table and addressed by developers, project managers, operations, etc is great. Security vulnerabilities can be given greater weight and teams can try to streamline the process for developing, testing, and rolling out patches. WAFs and RASP can add an additional layer of security until these issues are patched in the code. Not having something like this is the reason that we see 100+ days of exposures for known web applications as highlighted in the presentation above.

Does the ratio between time allocated to gathering data and time allocated to analysing the data make sense?

For the 2017 list there was roughly 3 months for gathering data (~June - Aug) compared to roughly 7 months to analyse the data.

The full 2017 process was:

• 20 May 2016 - Initial call for data
• 31 July 2016 - Official deadline for submitting data (after an extension from 20 July).
  (based on the data released, the last large submission was 31 August 2016).
• 17 December 2016 - Full data received released
• 10 April 2017 - Full RC1 released.
• 30 June 2017 - Proposed end to comment period
• July 2017 - Proposed final released

From @danielmiessler

https://danielmiessler.com/blog/comments-owasp-top-10-2017-draft

[ Apr 13, 2017 — Two points that I didn’t catch in my first reading of the draft: 1) The blatant promotion of specific companies and products in the document diminishes its authority, and I think they should be removed.

Another concern I have is that there's very little emphasis placed on cryptographic flaws in web applications. Maybe 1/3 of all web applications I look at have some kind of broken crypto in URL tokens and other tokens exposed to users. Broken "Bearer" tokens in OAuth, POA vulnerabilities in password reset tokens, etc. It is disappointing that the top 10 still mention these anywhere, because awareness is needed. To be clear, I'm not talking about TLS ciphers and password hashing. I'm talking about application crypto vulnerabilities that are much more serious and practically exploitable.

6. Timothy D. Morgan

Public site still https://wiki.mobilehealth.va.gov/display/OISSWA/OIS+Software+Assurance, see now e.g. MS TMT tech notes, design review SOP, etc.
Maybe just a sub-bullet on the organizational page: Start your appsec program. If you're managing vendors implement a VAST program. Maybe a callout then with a definition about VAST.
Mike Boberski

The OWASP top 10 is currently only distributed in binary formats which are specifically known to have various code execution capabilities and are unsafe to view when provided by random 3rd parties.

Please correct by adding plaintext documentation to this repo.

2. At the end of the document the project leaders actually make it fairly clear that the Top 10 is a list of risks and not vulnerabilities, and they even give a link to the specific methodology that is used to determine those risks. I’m glad they make that clarification, although I think it should be done at the very top of the document rather than at the end. ]

In new modern days of testing web applications, APIs are part of web applications and should not be considered as separate pieces. For example we see a lot of websites these days that can be a simple HTML pages using extensive APIs.
IMHO practically it is wrong to say unprotected API as a separate subject. API on its own can be vulnerable to any of the OWASP top 10 for example. So if we find one issue on an API, shall we say it was an unprotected API? Or this is only related to access control issues (A4) but for the APIs?
Additionally, who will decide what is an API and what is a web application? Shall we consider anything that doesn’t include HTML in their responses APIs? Or shall we work this out using the requests or perhaps if we have a restful application only? These days many of the APIs can be like a normal web page and response differently depends on the request.
Soroush Dalili

Osama Elnaggar

pg. 5 - "Release Notes"
It mentions how the threat landscape has changed due to new technologies, automation, etc. and then "and advances made by attackers". This a little ambiguous (are you referring to new methodologies, tools, automation, etc. or just the expanded attack surface)? Also, the line after it says: "These factors frequently make applications and APIs more difficult to analyze" so it seems disconnected with advances made by attackers.

3. About the new "A7 - Insufficient Attack Protection", I tend to disagree with most comments made on this mailing list for several reasons:
   a) First, in most cases (but there are exceptions!!), attacking a web app which is not protected by either a WAF, RASP, AppSensor, etc. is almost a joke. Sending tons of obvious attacks at a web app should never be allowed... Even when the application is already very secure, I think this kind of defense is a must. If you can scan a web site without raising alarms, you rely heavily on the application and the security maturity of the development team.
   b) Not all WAFs are commercial products, so I don't feel it's a push for vendors...
   c) We all know that WAFs are only good against some classes of attacks and personally, I've never seen them as band aids (but I agree that maybe people do...). I also often bypass them, but that doesn't mean that they are not important. To me, it's the same as a regular firewall: they protect against the easy stuff and for that reason, they are important. But they are only a component in the big picture, not the solution to all security problems!
   d) To an extent, I don't think developers should worry much about DDoS attacks. Other tools are there for that.
   e) In almost all my pen tests, I find that there's a huge lack of detection and response. So maybe there should be more emphasis on logs in A7?

11. David Caissy

I think that this section addresses an issue that has been missing for a long time. I would probably rename this section to Detection and Prevention and expand on logging of all sensitive function access, failed requests due to malicious input, etc. and not just rely on a WAF or RASP (although doing so is the recommended approach for virtual patching). Prevention is ideal, but detection is a must. Also, some issues related to attack prevention such as IDOR abuse (if the attacker rate limits themselves) won't easily be detected by WAFs, etc. because the input itself is not malicious.

2. Soroush Dalili
   Hi Dave, My comments are as follows. Hopefully you will find them useful:
   A1: Perhaps adding template injection at least as a reference
   Although template injections are similar to expression language injections, they are different and should be treated differently. We see them more these days because of all the new frameworks and the good job PortSwigger team did on researching them.

Based on @vanderaj 's summary:

"The basis for the OWASP Top 10 is 'risks'. I (@vanderaj) have suggested we adopt the ISO 31000:2015 standard definition for risk."

The short definition from ISO 31000:

"Risk is defined as the 'effect of uncertainty on objectives'"

My personal opinion is that is very broad and I slightly prefer a more condensed version that someone put forward in the first session (sorry I'm not sure who) which was:

"Risk is defined as 'things we want to avoid'"

Whilst less pure, I think that version is easier to articulate .

pg. 19 "+T: What's Next for Security Testing"
Unfortunately, most people won't read the standard to the end although this section and other sections after the Top 10 provide valuable direction. Perhaps adding a mention of it in the Foreword would give it the necessary visibility.

Some quick thoughts about RC1. I’m happy to see the “Insufficient Attack Protection” category however I think the “Underprotected APIs” category could be rolled into that and called out and logging be moved to its own category. I would suggest adding something like “A10 – Insufficient Monitoring/Logging”. I’ve been deploying and managing Web Application Firewalls (WAF) for the past 6 years and discovered early on that all events from WAFs should be logged, indefinitely. When something like XSS is discovered the client and management will always ask, “Was this ever exploited?”. The ability to search past events and answer the hard questions is invaluable. I would recommend, log all requests, headers and parameters if possible as well as application logs. Logging and monitoring is already called out in many standards; the lack of adequate monitoring and logging is a serious issue and widespread especially where regulations might not apply.

John Bauer

Osama Elnaggar

pg. 10 - A4 Broken Access Control
Again, "authorized users" is used. I think removing the authorized is better to indicate that this is a more generic problem
Again, my recommendation would be to steer away from ESAPI for the reasons mentioned earlier on and to instead leverage known frameworks that address these issues

In A6, I think you should replace browser with the client as the client may be other applications, not just browsers (unless this is intentional because you are isolating API-related issues to A10)