This is one in a series of deeper-dives into various Learnings from 5 years of tech startup code audits. In that article, I list several observations I had during the course of doing code audits fro 20-30 tech startups at or around the Series A / B mark.

Security seems to be on the up-and-up, despite all the bad news you hear in the media. What’s driven this improvement? Well, frameworks, cloud infrastructure, and the big cloud platforms have been hard at work creating the ”pit of success” — places where users just fall into being secure rather than having to fight to be secure — as a way to discourage the most severe security practices has by and large been an enormous success. This article is about our on-the-ground observations of these success stories.

We started doing code audits in 2014.

React had come out in March of the previous year, and AWS Lambda came out that November. We did a fair amount of serverless code audits and audits of React front-ends + API backends. We usually didn’t find much, and I think a large part of this had to do with major security features that were baked into React and it’s successors (aka escape by default, preventing XSS), and AWS Lambda (taking web server security configuration and OS configuration out of developer’s hands).

It’s possible that this was because the exploitation methods that got around React and other framework’s default-escaping approach took awhile to emerge, and are relatively difficult to exploit. But it’s also possible that the new wave of Javascript frameworks that built in these security properties actually made things more secure by default! This type of win-win, where security was introduced in a way that didn’t make developers lives harder should be considered a massive win for the security community, and my hat goes off to the framework developers for making the web a better place.1Some folks might point out that default-escaping was not invented by React. Rails for example has had this since Rails 3 (~2008). However, we found that there were a lot more instances of Rails code breaking convention and being vulnerable than you would suppose. My theory is that it’s because there is a lot of bad code floating around Rails forums, that makes it easier to copy/paste bad code into even new codebases.

Lambdas and serverless were also taking off at the time, and the same observations hold true there: a whole class of very serious security vulnerabilities (configuration-based web server and OS concerns) are just not a problem on serverless. Sure, the attack surface is by no means zero, and things like RCE and SSRF are still deadly, and new exploit types will be found, but the security properties of security represent a real, step-function increase in security across the board.