New Study Demonstrates Lack of Focus on API Security

A new study by Ovum and Distil Networks released today shows that a third of all APIs are designed and implemented without any input from an enterprise’s security team. This can continue through to ongoing management of an API, where there is often disagreement internally over whether security aspects should be managed in an ongoing manner by the API design team, or by the wider IT security department.

The study, “API Security: A Disjointed Affair”, interviewed 100 companies across a range of industries in North America, Europe and the Asia-Pacific regions. Over 40% of those responding to the survey are managing more than 25 APIs, with 20% saying they have published and are managing more than 50. Many of these are reported to be open APIs, intended to foster an external developer ecosystem or as a key tool in enabling partner connectivity.

Most (87%) of those interviewed for the survey did have an API management system in place, although perhaps surprisingly, 63% had opted for an in-house solution rather than relying on one the industry’s API management service providers.

Announcing the survey, CEO and cofounder of Distil Networks, Rami Essaid said:

APIs impact business and the world around us more than most people realize. The fact that API security is flying under the radar and not being adequately addressed should be a red flag prompting organizations to examine their own practices.

Ovum API Security infographic

Perhaps because the companies interviewed are going it alone in terms of API management, many have not yet built or established basic security practices. The report found only 21.9% of surveyed companies had protection from API malicious usage, API developer errors, automated API scraping, and Web and mobile API hijacking.

Rate Limiting Not Universal

One of the most surprising findings of the survey regards rate limiting of APIs. For many focused on best practice, rate limiting is often considered a ‘tool of last resort’ for API design and developer engagement, but an important tool nonetheless. API providers should first help third party developers either focus their API requests sufficiently so they are not making needless calls, or create thresholds that act as alert mechanisms so that the provider can engage with heavy users and assist them to find a more appropriate plan, or way of making their calls, before rate limiting is triggered and their API access is turned off.

API developer-consumers see rate limits as one of the most challenging aspects of dealing with poorly designed APIs. Todd Sundsted, Technology Executive and Leader at API aggregator SumAll, says many APIs won’t tell consumers how many calls are remaining in their plan, “there is no way of knowing until you hit it”, he says. He recommends that API providers should put details of the remaining number of API calls in the headers or response bodies, so that consumers can better manage their usage, and hopes for a future where more API providers will use stream processing or functional reactive programming techniques to better manage the flow of data to users.

While best practice is seeking to avoid relying on the heavy hand of rate limiting as a control, many would agree that in the meantime, it is a basic security practice, which makes it disturbing that Ovum and Distil Networks found that less than half of their survey respondents had any rate limiting in place. Even worse, those that did use rate limiting as a way to manage their API usage were requiring considerable resources: 44% of those with rate limiting were spending over 50 hours a month managing this capability, with 34% tying up between 21 and 50 hours a month.

“Clearly there is a need for this process to be more automated, freeing up IT professionals to engage either in more advanced forms of security functionality, if that is their area, or in developing more APIs,” the report suggests.

To help companies better respond to the security shortcomings described in the survey findings, Distil Networks has launched Distil API Security. This series of tools includes token based user tracking, advanced rate limiting, and dynamic access control lists. The service is aimed at supporting those companies who have built their own in-house API management approach.

The survey can be downloaded at: http://resources.distilnetworks.com/h/i/233881696-ovum-survey-on-api-security/185088

Mark Boyd is a ProgrammableWeb writer covering breaking news, API business strategies and models, open data, and smart cities.

Comments

Comments(2)

mbuckeye21

This is great information. Thank you!

MarkBoyd

Thanks mbuckeye21. The report from Distil Networks is worth a close read - I encourage you to download the full report and asses your own API security against it. There is also an excellent look at API security by Kin Lane: http://pages.3scale.net/delivering-security-apis-wb.html Regarding the rate limiting side note, i am keen to explore best practices around that as a technique for managing API calls by end users, so hope to revisit that in the near future.