Recently, we published a blog article discussing the growth of the “API Economy”: a term coined to describe the proliferation of API-based tools being incorporated into many software products and applications. In this article, we discuss one of the side effects of this growth: the need for more data security as a result of the growth of API use.

Application programming interfaces, or APIs for short, have transformed the way we create and use software by linking your application to other people’s code and data. Our APIs, for example, can be integrated into your code, CRM or e-commerce platforms to do things like validate your contact data against most of the world’s addresses, provide sales tax data down to specific address levels, verify and correct lead information, to name a few – right in your app.

APIs have truly opened up the world for applications such as retail, sales and marketing automation and much more. However, APIs have the potential to introduce security risks, particularly if they represent a pipeline to your data assets. A recent example of an API breach involved Australia’s largest property valuation firm exposing the loan details for over 100,000 customers.

The security risks of APIs are generally well understood by the developer community and our internal team pays close attention to changes and developments in this space. Below are some of the main thoughts on API security and risk management.

Security and APIs – What the experts say:

In 2016 David Berlind, the editor-in-chief of ProgrammableWeb, a portal site and directory for API developers, gave testimony to a government healthcare IT task force on current issues in API security. Here are some of the key points he raised:

Security starts with access to APIs. One of the largest concerns with APIs nowadays involves who gets the keys to the candy store – particularly if an API facilitates access to sensitive data. Berlind describes this in terms of APIs targeted at “LSUDs” (large sets of unknown developers) versus “SSKDs” (small sets of known developers). Increasingly, many firms are restricting access to their APIs and documentation to known and verified partners.

Security standards are still a work in progress. While specific API providers maintain their own security standards – for example, PayPal requires API users who store credit card data to follow PCI compliance rules – Berlind also notes that even major players such as Google, Apple and Facebook have all fallen prey to API breaches, and security standards are continually evolving.

Contractual protections matter. While this won’t stop bad actors, putting language in an API’s terms of service (TOS) can be an important tool for enforcing the proper use of APIs among customers.

Third party certification is needed. Given that API security continues to evolve, in what Berlind calls a “cat and mouse” game between hackers and developers, he feels that there will ultimately need to be an industry-wide API security standard that is continually informed by what we learn from the latest security incidents.

Since this testimony, dialogue continues around the evolution API security, including this list of best practices such as front-end authorization and authentication, checking results data, and investing in proactive security testing. Much more remains to be done in this area, but at least this topic is at the forefront of the API developer community.

Our perspective on API security

Of course, we are API developers ourselves, so we are extremely sensitive to the issues of API security. Part of this springs from self-interest: for vendors like us, who handle sensitive personal data for what are often mission-critical applications, our business depends on it. But we are also observing the growth of the entire API ecosystem with interest, and this is a topic we all need to be talking about.

Our API products carry less risk because we do not store customer data. Instead, each record a customer submits to us is processed through a secure and encrypted connection, generally by validating it against one or more databases, and validation results are returned through a secure and encrypted connection. We neither store customer input nor resulting output, so there is little to “steal” by calling our APIs.

Personally, we feel that part of the solution is for API developers to adopt accepted best practices in data security, and document these procedures publicly – ours are here, for example. To create more customer confidence as APIs proliferate, our industry will increasingly need to take people inside the “black box” of API infrastructure and discuss what steps are being taken to protect their data. We are glad to be part of this dialogue, and will continue to be part of it in the future.