API security should be built into your product

I see many teams that have a laissez-faire attitude towards API security. They'll build their product, make sure all requested features are in, and one week before going live they'll check that their API is somewhat secure against the most basic attacks.

That means security is bolted on instead of built in, with even basic things such as rate limiting not accounted for. It's worse in teams where ops is separated, because it's easier to shift responsibility for "simple" things like rate limiting to the ops team. This causes a lot of teams to be unprepared for the volume of automated attacks happening against APIs every day. Most of these are similar to what web server owners have faced for more than two decades - just automated pings and attempting to grab low-hanging fruits.

But there's a range of disruption in these attacks that doesn't necessarily end with millions of customers losing their data. It could well be that due to the sheer volume of automated attacks, the API is taken offline, causing a service disruption for regular users - or an exorbitant cloud services bill to keep it online.

Teams should make an effort to implement security from day one. This is especially important if you're using GraphQL. In my experience, teams are less knowledgeable about the shortcomings of GraphQL and the possibilities for granular security. This leads to teams simply building one major query that returns everything, with no additional field-level security built in - a major accident waiting to happen.

As with web app security, which I highlighted last week, doing it early and doing it right saves your team time and your company money. This is because your team won't be busy firefighting every other week due to security issues, instead allowing them to concentrate on shipping valuable features for your customers.

Yours,
Søren