I find OWASP guidance generally lags behind latest research by at least a couple of years.
All too commonly the projects seem like CV padding pieces that get abandoned and not updated (I re-iterate, not all OWASP projects, just a lot of them).
If you are developer who wants to learn more about appsec, I’d recommend checking out pentesterlab.com and working through the exercises there.
You are not the target audience, it is the huge number of companies with near-disastrous neglect of basic security measures that are kind of well known but not universally applied, as illustrated by all the statistics on actual attacks and vulnerabilities which are dominated by old, "solved" problems that don't need any latest research.
And even in greenfield development in new companies you still routinely see things like simple SQL injections or hardware with hardcoded trivial credentials. The future is already here, but it's not evenly distributed, and lots of new things are still made with very not-modern development practices - it's not only about legacy code, there's lots of new sloppy insecure stuff being written every day.
Most people haven’t read either front to back and for the most part make assumptions as to their purposes. Devs are the first to nitpick it and security practitioners for the most part are always a negative bunch :D
BUT....
If you are in a regulated industry like finance, insurance or healthcare, it doesn’t matter whether you’re at a startup or a stodgy Fortune 500 company.
At the point at which your organization starts caring about security which is usually “client contract language” or “audits,” the flagship OWASP programs are killer tools with which you’ll use to craft a secure software development lifecycle that touches everything from sprint planning to feature reviews and penetration testing.
I stand by what I said before. OWASP can be useful in consulting settings as a communication tool. It's not a good reference.
In fact, OWASP ASVS has stated emphatically for years in its introductory pages that it is not an exhaustive reference.
As you have rightly said it is a communication tool utilized to communicate security concerns and mitigate risk.
Again, I get it. Most people aren’t going to read the first 5 pages of the OWASP ASVS or WSTG let alone read the entire documents.
OWASP's best asset, in my opinion, is their seemingly conservative approach, always there to teach me yet another tough lesson (again) about the ten original deadly sins[1] of web development. And other things.
While state-of-the-art content can be lacking, so could it also be assumed that those same kind of threats will be lacking in the wild. The greatest share of threats we face are mostly of the dull, low-hanging fruit kind of thing, that's been around since forever (because the same vulnerabilities are provided again and again).
> Give a man an 0day and he'll have access for a day, teach a man to phish and he'll have access for life. - @thegrugq
I'd like to mention to anyone less familiar with the subject, that OWASP is a resource on defensive security. If seeking content on offensive security, other sources are usually more rewarding (a pentesting site was mentioned).
Lots of good people have contributed to OWASP over the years and I wouldn't want to diminish their work (which is another problem with the project, it's blinded to a lot of critique by the deference it gets). But the idea that someone would take flaws in OWASP, try to reconcile them with the axiom "OWASP is good", and conclude that it's the the bugs fault, not OWASPs; that's pretty alarming.
[1] https://application.security/free/owasp-top-10 [2] https://application.security/free/owasp-to-10-API
I also feel like ‘always escape input’ can cause double encode / double decode bugs (which can be used for XSS) - a better option would be ‘design an XSS mitigation strategy at the start of a project and conform to it’.
XSS is used as an example, but this is pretty relevant to all injection, techniques.
From a training perspective, theres nothing worse than e-learning and interactive exercises for developers.
- If you are a dev who wants to learn more about appsec, then attend the local OWASP meetup and sit in on some actual CTFs and learn the tools/process.
- If you are like most devs who just want to become better developers, then ask your company to be more transparent with their pentest readouts and let developers attend the meetings, reviw the findings and more importantly interact with the testers themselves.
The biggest problem in appsec is the lack of transparency and poor communication between security professionals and developers.
OWASP is just fine.
Not that OWASP is super great or something. But I have looked multiple times and there is very little that was written about security specifically for application developers.
I understand your frustration. Ideally I feel security should be baked in from the beginning with a SDLC process, i.e a friendly security person you can ping/involve from conception through development of a feature. Rather than the all too often 1 week pentest scheduled 1 week before product go live with no time for remediation and no communication with the tester apart from a 20 page report at the end.
Online resource wise, dev security material can be sparse, you either have Troy Hunt or someone else warning you about SSL/TLS configurations (I die on this hill, attackers don’t care if you have a C or A+ SSL labs score because usually that’s nothing to do with how you’re going to get hacked) or XSS (hopefully your framework handles this now) but then nothing really breaking down what request smuggling is and how you can protect against it.
If you can get a 2 day slot to get a training course in as a dev team with a (decent) security person, that can be really valuable. Gives you enough of a high level overview to get that tingly feeling when maybe something might be a security issue.
Did we not just yesterday or today discuss a bank that sent credentials in clear text?