Why you should worry about API security, but not panic

API developers offer some very striking responses to the question of how secure they believe their APIs are.

human weak link cybersecurity primary
Credit: Thinkstock

API security has gathered significant attention recently.

For example, The Economist featured an ominous cover story: “Why computers will never be safe.” It’s a common worry. Since APIs by definition govern access to important data, any concerns about data security lead inevitably to questions about API security. This focus will continue to become increasingly top of mind as more APIs are created, published and used in the growing API-first world.

A recent survey from Postman--the API toolchain provider for more than 3 million  API developers -- provides insight into this conundrum. One of the simplest questions -- ”How secure do you think your APIs are?” -- had the most striking set of responses.

The results were heartening: developers believe that their APIs had better-than-average security. On a scale of 1 (not at all secure) through 5 (very secure), the average rating was 3.4. While this number should be higher, an above-average rating bodes well for the burgeoning API ecosystem.

Even more interesting, it turns out that the more you work with APIs, the more confident you are in their security. Of developers working with APIs fewer than 10 hours a week, just 26 percent rated their APIs as “quite” or “very” secure (a 4 or 5 rating). However, developers working with APIs more than 20 hours a week were more optimistic—40 percent of these users gave their APIs a 4 or 5 security rating.

In concrete terms, what does this mean?

API security is an important and complex issue that encompasses a number of specific challenges. A secure API needs to effectively control six separate risks: data, operations, infrastructure, people, network and incident response. That’s in addition to the core work of designing, testing and documenting the API itself.

Sharing the right data at the right time

The most common job of an API is to expose data for use by other applications, which sets up the first—and perhaps most important—security concern. Control over data is critical, as is making sure that the right level of access is available based on appropriate authorization. An overly restrictive control structure will guarantee security but discourage or prevent use of the API, undermining its entire purpose. Even simple mistakes can have huge repercussions. For example, a recent vulnerability in HackerOne’s API resulted in the dumping of entire database rows into shared API responses, without sanitizing.

Operations: Security in changing and updating data

More advanced APIs allow users not only to read data but to perform operations on it, including updates and deletions. Used with evil intent, changes to the data can be worse than simply unauthorized viewing. For example, a recent Twitter security breach allowed an attacker to delete credit cards from any Twitter account. Extensive testing for correct authorization is critical. Moreover, while any change via API needs to be secured, large-scale updates or deletes are the most harmful. In this case, simple rate limits built into the API, particularly on bulk updates, can help.

Infrastructure: You have to trust your technology stack

The modern software stack is complicated. Bugs can exist in the applications, frameworks, language, memory or operating systems. Abhinav Asthana, Postman’s CEO and co-founder, believes infrastructure patching is critical. He explained, “Creating your own authentication system from scratch, while tempting, is a disaster more often than not. A key tenet of API security is regular patching at all levels within our stack.”

Don’t forget the network

With the recent wave of support for HTTPS and availability of certification providers like HTTPS, network-level security has received a huge boost. Like HTTPS, developers should invest time in secure options for other API protocols, like secure web sockets. Developers should be aware that obfuscation does not mean security. Only well-identified and peer-reviewed encryption algorithms should be used, and it is critical that keys used in encryption are not exposed—ever. In addition, it is very important to keep up-to-date with the latest announcements, like Mozilla’s on phasing out SHA-1.

People systems matter, too

Often overlooked in technical organizations, the people aspect of security is often the easiest to exploit. This is particularly critical with key repeating operations within an engineering team, like the process of deleting unneeded records from a database or ensuring accurate backups. Sometimes just making sure people understand their tasks can be simpler and more effective than a sophisticated technical solution. Even established organizations face these challenges; Gitlab’s recent deletion of a production database is an example. 

Incidence response: When things go wrong

Sometimes, things go wrong. Often, developing an ability to detect errors—and an ability to respond to them—is as important as debugging itself. Every technical organization must create a system to independently monitor infrastructure and to ensure clear internal and external communications. Preventing errors is, of course, best. But assuming things will go wrong is pragmatic.

API security will continue to be an important topic with the ongoing growth in micro-services and use of internal, private and public APIs. However, there is reason for optimism. With a thoughtful planning approach, with follow-through and detailed execution, companies can have a successful API security policy.

This article is published as part of the IDG Contributor Network. Want to Join?

NEW! Download the State of the CIO 2017 report