[Owasp-topten] Released: OWASP Top 10 – 2017 Release Candidate
oelnaggar04 at gmail.com
Tue Apr 11 02:58:14 UTC 2017
I just went through the OWASP Top 10 2017 RC1. I really like the addition
of A7 and A10 as well as the addition of section "+T: What's Next for
Security Testing". However, I had a few comments:
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).
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)
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 (
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" -
I think that mention of ESAPI should be removed across the standard.
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 wiht 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
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
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
pg. 14 - Insufficient Attack Protection
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.
pg. 18 What's Next for Developers
I would remove the mention of a reference model of ESAPI as mentioned
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
On April 11, 2017 at 12:43:54 AM, Dave Wichers (dave.wichers at owasp.org)
The Release Candidate for the OWASP Top 10 – 2017 is now available!
*It’s also available for Download here
Please forward to all the developers and development teams you know!! I’d
love to get feedback from them too, and to start immediately raising
awareness about what’s changed in this update to the OWASP Top 10. The
primary change is the addition of two new categories:
*2017-A7: Insufficient Attack Protection*
*2017-A10: Underprotected APIs*
We plan to release the final version of the OWASP Top 10 - 2017 in July or
Aug. 2017 after a public comment period ending June 30, 2017.
Constructive comments on this OWASP Top 10 - 2017 Release Candidate should
be forwarded via email to OWASP-TopTen at lists.owasp.org. Private comments
may be sent to dave.wichers at 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 changes,
along with a rationale for any changes. All comments should indicate the
specific relevant page and section.
Your feedback is critical to the continued success of the OWASP Top 10 Project.
Thank you all for your dedication to improving the security of the world’s
software for everyone.
OWASP Top 10 Project Lead
Owasp-topten mailing list
Owasp-topten at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-topten