Appsec person here with a potentially unpopular opinion.

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.

Since median industry practice lags behind latest research by decades, OWASP guidance is far ahead of the demonstrated maturity level of the vast majority of companies and is a good target for them.

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.

Which "industry" are you referring to? If you mean "line of business Java applications at huge insurance companies", you're right. If you mean "startups where software development is a profit center", I think you're pretty wrong: OWASP might be years behind the state of the art of modern software development.

I mean the whole software development industry, and arguably developers working worldwide on "line of business Java applications at huge insurance companies" and the like far outnumber the developers in "startups where software development is a profit center".

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.

I agree that line-of-business developers probably outnumber profit-center developers in the industry, but they don't on HN.

Sorry, I just reviewed ASVS 4.0.2 and it's as OWASP as ever. It's super high-level. There are whole sections where it's clear the authors don't have subject matter expertise (cryptography, which has its own section with several bullets, has essentially no bullets on how to actually evaluate cryptography). Super-important attack patterns, like SSRF and deserialization, are condensed down to single bullets that amount to "don't have SSRF". There are idiosyncratic attacks, presumably the pet projects of OWASP authors, for which Google searches bring up ASVS as the only real cite. There are idiosyncratic defenses; some busybody has managed to get OWASP to demand secret-salt password hashes. Everything is indexed to CWE, further evidence of consulting infection. There's some good stuff on 2FA, but nothing meaningful at all about SAML (which has been ripping holes in major platforms for the past 5 years) or OAuth, which has been rolling new protocol variants to combat flaws for basically its whole existence.

I stand by what I said before. OWASP can be useful in consulting settings as a communication tool. It's not a good reference.

What you are saying is partly true. At the same time, when it comes to discovering brand new things that are AppSec related, without knowing anything about it, OWASP is a good starting point, while it might lag it still gives a good starting point, which is somewhat checked

I agree it’s better than nothing. I guess the problem lies with OWASP (as far as I’m aware) being volunteer created content and there are no economic incentives for those individuals to keep it up to date after initial publishing.

OWASP has been a major authority on web security for a long time. Their best known material is well regarded in both academia and industry (I wasn't aware of the half-hearted contributions until now).

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).

[1]: https://owasp.org/www-project-top-ten/

I think it is mostly not true that OWASP is especially highly regarded, and truer to say that it's application security project with the most momentum and highest public profile, and so it's generally the easiest thing to cite.

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.

Shameless plug: this is exactly why we built Kontra to educate developers without having to go through dull write ups like these ..

[1] https://application.security/free/owasp-top-10 [2] https://application.security/free/owasp-to-10-API

I recommend your site to my junior AppSec folks, and I used your Capital One walkthrough two years ago to explain the hack to our business. Well done, really love the site.

I just went through the Capital One SSRF and it's super smooth. Well done!

Appreciate the kind words dude :)

+1. I wish they did something to highlight that the detail they’re providing is uncontextualised. Protecting against XSS* is vastly different in a server rendered PHP app than React.

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.

I also have a low opinion of the quality of the OWASP guidelines. Their web-related ones are largely unmaintained; the XSS one, for example, had a couple of fairly crazy pieces in it (e.g. saying that / should be encoded) for more than ten years (fixed a few months ago, begrudgingly), and still has various content that is not factually correct, referring incompletely to obsolete specs, &c. Also it’s not a cheat sheet in any way; far too long for that.

Mozilla Observatory provides excellent web security header guidance and if have found this to be more helpful than OWASP for those new to app sec.

Which research exactly? NIST? White paper sales puffpieces?

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.

I'm glad to see someone else on HN saying this and strongly agree; OWASP can be useful but is usually not the best resource. I generally find it more valuable as a communication tool than as a reference.

For me as a developer, OWASP guidance format is much faster to digest and get some idea about what should I avoid or do then set of hacking exercises. Hacking exercises are fundamentally different thing. Securing your application and being pentester are also two very different things.

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 get that too. I’ve been an appsec person, developer and product owner at different times.

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.

I've heard pentesterlab brought up pretty often. Is it really much better compared to other resources out there e.g. Tryhackme, hackthebox? How so? Or is it just cause it's the popular one now?

Be that as it may, we also see time and time again that even major sites still screw up the very basics covered by OWASP.

Did we not just yesterday or today discuss a bank that sent credentials in clear text?

I appreciate the feedback. Are there any other resources you would recommend for novices looking into the field? Thank you.

Portswiggers web security course is good, instead of releasing a 3rd version of the Web Application Hackers handbook (which was the standard goto appsec book) they developed this free course with practical exercises.

https://portswigger.net/web-security

The cheat sheet series is the best project at OWASP. I use them almost weekly when I reference vulnerabilities for developers. It's one of the main reasons I have a membership. If you feel the guidance is starting to get stale, take a few minutes to make an update and submit a pull request. I'm sure it will be appreciated.

This is gold. Thanks for sharing.