Why achieving API best practice requires a security rethink

With the usage of application programming interfaces (APIs) increasing by the day, the challenge of achieving and maintaining effective security has never been greater.

This challenge is made even more acute because of the lack of a single standard for managing APIs which means teams cannot rely on tools alone to solve security issues. No single product can fix every problem for every language, framework, or context of an API environment.

For this reason, enterprises play mix-and-match. Modern organisations are fixated on tools to respond to challenging cyber threats — to the point of lapsing into tunnel vision that impedes progress. A 2022 report showed that large enterprise security teams oversaw an average of 76 security tools. That's far too many.

The focus on automation and tooling creates a false sense of security and a failure to address underlying causes, as most data breaches are caused by human error. Research has found that developers also heavily rely on pre-existing code, for example, with nearly one-half using libraries or frameworks with inherent flaws because they are not tested or evaluated on an ongoing basis. At the same time, developers assume that because the code exists in a library, it is secure. But this is not always the case.

Achieving best practices

It's time we hit the reset button. We need to stop constantly seeking the latest shiny object and start focusing more on our people. Yes, security tools have advanced impressively and serve a critical purpose.

However, software development teams still need to improve their security capabilities to effectively deploy these solutions. The resulting training and policy implementation should focus on the following best practices:

1. Assign ownership:

By their very nature, APIs are over-permissioned to allow unchecked communications between applications. Frankly, they "talk too much",— leading to a state of oversharing that triggers compromises. This is "TMI tech."

TMI tech persists because we rarely assign ownership of APIs (either to developers or to their app sec cohorts). Accordingly, there is rarely any meticulous monitoring of which API shares what.

To rectify this, managers should assign API ownership to development teams and help them recognise the risks of wide-open (and undocumented) API implementation. When such responsibilities are covered, and contextual behavioural baselines are established, it is far easier to shut down these troublesome "conversations".

2. Treat APIs like people:

To extend our first best practice, we can immediately improve access control by applying zero trust, least-privilege, and role-based authorisation to APIs, just as we do with people. If an API is required to perform a specific function, then we limit its permissions to that function only. Similarly, we should further restrict APIs' time spent accessing—and the volume accessed—as appropriate.

3. Incorporate a 'test-first' mindset:

Developers need to understand the pitfalls of assumption—but preferably not the hard way. As such, dev teams should regularly test APIs to verify that they are not exploitable (while still functioning as intended). Testing early and often can help reduce bugs, saving time and additional costs in the long run. Plus, security teams will appreciate it.

4. Conduct regular simulations:

Simulations better equip developer teams to react when different API situations play out. And they seem to be exactly what developers need to improve their secure-coding skills. Research conducted by Secure Code Warrior found that more than nine out of every 10 developers acknowledged needing training in security frameworks. Almost a third (30%) reported feeling they would benefit from practical security training sessions featuring work-relevant, real-life examples; nearly as many indicated that they would benefit from hands-on interactivity—such as practice sessions in which they attempt to write secure code.

5. Change Performance-Review Metrics:

Secure development cannot be rushed. Given the clear consequences, therefore, it is time to cease placing so much emphasis during team member evaluations on the raw speed of feature delivery. Otherwise, the performance review phase presents developers with a perverse incentive to sacrifice security if not quality). Instead, organisations should look to reward those who can create quality, secure code within a reasonable time frame.

The threats posed by cybercriminals will continue to evolve and intensify in the months and years ahead. By adopting a more people-centric approach to API security, organisations can ensure they are best placed to withstand these threats and continue to grow and prosper.