At this point, OWASP Top 10 is considered one and the only bridge between security researchers and developers. There are some books and blog posts here and there but if you’re looking for “top threats & vulnerabilities” that’s what you will be offered by others including Google.
Unfortunately OWASP is out of touch with reality. First Top10 was released in 2003 and back then the web was a mess. CSRF? Everywhere. XSS? Give me a minute. SQL injection? Just try another parameter.
Now most misdesigned vectors are treated on framework level (and you should always use one - don’t build a house from scratch, reuse blocks that have proven track record). I will use Rails as an example but others are very similar.
Let’s take up-to-date list from here and comment every item.
A1. Injection - not going to happen with major frameworks. There are some corner cases such as barely used ORM methods which could be fixed by renaming “calculate” to “unsafe_calculate”. In fact every library developer should expose dangerous method with “unsafe_” prefix if you care about your users.
Injection is still a relevant threat but only because ORM developers made naming mistakes.
A2 Broken Authentication and Session Management - session management is long time solved problem since we all use auth libraries.
Seriously do not roll out your own auth library, use Devise or Omniauth. They pop first during the audits.
A3. XSS - (should be under A1 Injection) is generally solved problem. The output uses templates, client side frameworks use templates, corner cases like JSON-in-script-tag is also solved. Try to put '"><img src=x onerror=alert(0)> in every input you see on a website (some people do it for a living) - yields nothing these days.
There are still ways you can be hit by 3rd party libraries but there’s nothing you can do as a developer. Just don’t
html_safe on unsafe strings. Obvious.
A4 - Broken Access Control. Unfortunatelly business logic and access management isn’t a solved problem. The best approach is to always chain your code as current_user.comments.find(params[:comment_id]) and manually assign things like topic_id (instead of mass assign) so the access is checked on all read/write operations. CanCan is also a great solution.
A5 - Security Misconfiguration. This is good one and there’s nothing a framework can do for you. There are things like Redis that is exposed by default. There’s not much you can do about your coding style, just read manuals carefully and listen to others.
A6 - Sensitive Data Exposure. You must be using https by now. Just use LetsEncrypt. Not worth a dedicated item.
A7 - Insufficient Attack Protection. That’s the last straw that made me write this post. So now companies like Contrast Security can use OWASP to literally add “A7. Not enough of Contrast Security”.
A8 - CSRF. Solved problem. State-changing action must be non-GET and non-GET should require authenticity_token - simple as that.
A9 - Using Components with Known Vulnerabilities - patch your stuff when CVE is out. Far from a solved problem but regular “bundle update” is all you can do.
A10 - Underprotected APIs. Frankly, this one is written for complete noobs. If you don’t realize that the attacker can fake arbitrary requests looking like from JS or mobile app, you’re not ready to write production code.
We are left with A1, A4, A5 and A9 as somewhat relevant and a dozen of other attack vectors common app faces with no single mention.
From top of my head:
Race conditions - Look at BlockChain Graveyard (ironically the Graveyard is great OWASP replacement with sorting by damage). Only few mentions race condition (many reasons are undisclosed) but reality is harsh.
SSRF - Webhooks, download this URL, instant payment notifications etc
OAuth - There is a list of known OAuth design flaws and that doesn’t fit into a single item of Top10.
If you aren’t maintaining some PHP app written 10 years ago, Top 10 list is irrelevant to you. By reading Top 10 you gain no useful knowledge. It’s now just a marketing term and rather good indicator the company using it is a snake-oil. No, it’s not even a “good start”.
Many years ago when websites had more vulnerabilities than features, it was a nice short list to get basic sense of what secure coding is. Now it is not enough.
It’s also true there’s no alternative. There’s no one big bible about all known platform-specific bugs. Creating one would be a very hard task and honestly not in best interest of us, security researchers.