Security is done elsewhere

2025-04-30

Security being implemented elsewhere is a common attitude amongst developers, at least in my experience. I've certainly fallen victim to this attitude myself, especially when working in a large corporate environment.

I get where it's coming from. As teams grow, they're inevitably split into specialties; companies hire Dev(Sec)Ops people, they hire people that "do Kubernetes stuff", they hire product managers, and then they hire developers. More and more tasks are moved away from developers and shifted to other people, which is both good and bad.

The upside is certainly that each area can be optimised independently. Someone that works day in and day out with AWS is much better at optimising and advising a company on AWS usage and costs than a developer that only does it part time.

The downside is that a feeling of "not my responsibility" starts creeping in.

In the case of security, this can prove fatal. Take the case of an internal API. If done properly, every endpoint will have both authentication as well as authorisation built in, even if ultimately deployed behind a VPN or similar setup. Why? Because if the VPN or other guarding mechanism fails, it still won't be possible to access every API endpoint outright. In the case of an internal API, these endpoints could give someone additional access to proprietary company data or allow someone to manipulate company records.

However, time and time again, I've seen developers opt for the easy approach: Since the API is behind a VPN or other guarding mechanism, security is done elsewhere, and so they don't need to bother with additional checks.

The numbers back this up. It's one of the biggest issues highlighted by the OWASP Top 10 API security report, as well as other data, such as Salt Lab's Q1 2025 State of API report.

Regardless of how the team is set up, it's important to not exclusively rely on perimeter defences - whether that's a VPN, reverse proxy or any other mechanism by which access to the API is limited. Developers need to always build in additional authorisation and authentication checks into every API, so that if the perimeter defence fails, the API remains secure.

Yours,
Søren

Want to get articles like these in your inbox every week?

Delivered straight to your inbox every Wednesday.