“APIs are nothing new,” said Secure Code Warrior co-founder and CTO Matias Madou, but they have recently become more widely used.

And where they were once a local mechanism, they are increasingly used in a distributed manner, partly because of changes to application architectures. Another reason is that users are increasingly likely to access systems from outside the organization, whether they are customers, suppliers or employees working at home.

Potentially anyone and anything can access an API, so developers and architects should therefore assume that APIs are exposed, and treat requests accordingly.

This means addressing issues such as authentication and authorization, and generally ensuring that the only data exposed by the API is the data that’s supposed to be exposed.

So assume every API call is malicious, suggested Madou.

Start at the Beginning

Achieving API security starts with the design and architecture, so jumping in and writing code immediately is a mistake. Unfortunately, starting with a completely blank slate is unusual, and some code will likely already exist. In that case, it is especially important that the design makes provisions for possible weaknesses.

If you want secure APIs, then ensure that everyone working on the project – architects, developers, testers and so on – are “very security savvy,” said Madou.

The need to improve skills is often triggered when the company or one of its competitors experiences a problem.

So teams should work to identify any existing problems, realize they need to proactively avoid the underlying issues, and undergo appropriate training, he says.

The trouble is, “security and developers are not often the best of friends,” Madou said. So, developers tend to think that security is the responsibility of their security colleagues. But there should be a common goal: making reliable and secure software.

“Security needs to help developers,” he said. One way of achieving this is to appoint a ‘security champion’ to act as a bridge between the security and development teams. An embedded security person can help developers realize that security is an enabler, not a blocker.

Help When Help’s Needed

Embedding communication from the security team into developers’ workflows is another part of the process. Slack is one possible conduit. Security people need to be wherever developers discuss issues. Then, they can take advantage of opportunities to say things like, “it looks like you’re having problems with SQL injection. Here’s some training material that might help.”

Developers live in their IDE, so that’s where integration should occur. But design such systems to help developers, not to control them. “Developers are people, not robots controlled by machines,” Madou warned.

Another consideration is that it’s important to avoid unnecessarily interrupting developers. Such systems should therefore predict what a developer is about to do and deliver appropriate guidance.

For example, if someone codes a database connection, the system could offer the statements that securely retrieve information. Then, the developer can copy and paste them instead of starting from scratch each time. Using new code every time carries the risk of introducing vulnerabilities.

“It’s tricky to make these systems,” Madou admited, but he predicted they will become increasingly common in the coming years.