A few weeks ago I was on the Yet Another Infra Deep Dive podcast with Snyk advisor, Ian Livingstone, and General Partner at Essence VC, Tim Chen. We had a good discussion about how security is moving to the frontend, which is the hypothesis behind why we started with the JS SDK for Arcjet.
The traditional view is that developers don’t care about security. There has always been a separate mindset where developers build stuff and security people break stuff. This meant that developers would work on building their app and then once it was finished, someone else would buy the security tools needed to plug the gaps.
The problems with this approach are obvious. Security shouldn’t be something that developers do later, but it always ends up that way because of the focus on delivering features.
The result is throwing some kind of network security tool in front of the application once it’s deployed. These are useful for volumetric DDoS attack protection, but often end up breaking things because they change the environment in untestable ways. If you’ve ever turned on a new WAF in production then you probably know what I’m talking about!
That’s when developers start to care - when things break. Security teams then have to convince (or coerce) developers to fix things, scan things, update things, and go back to refactor code that has already been completed. All in the name of security.
Arcjet has a different philosophy. Our SDK allows developers to implement core security primitives without needing to think specifically about security. Adding rate limiting, bot detection, email validation, and our Shield WAF-like attack protection doesn’t take very long, and you can test it all locally.
But the real differentiator is the additional context being in the code brings. Developers can apply the security signals to their application logic and customize the response appropriately. Set different rules for different users. Flag a suspicious account for review during the signup process. Trigger re-authentication if the user is behind a proxy.
None of these are possible unless your security rules live alongside the code.
So if you’re interested in hearing me discuss the details behind this, give the episode a listen!
(I also discussed my “spicy hot take”: secrets shouldn’t be stored in environment variables!)
Top comments (0)