Guidelines for Using Public APIs - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

11:00 AM

Guidelines for Using Public APIs

Developers planning to use public APIs in their software need to consider factors such as what the API provider plans to do with collected data.

There are thousands of incredibly useful, publically available API’s that can be leveraged to enhance applications and systems. Many of these are free of charge to use. Developers at many companies are leveraging these to enhance visibility, add new functionality or integrate business processes.

However, there are risks to using these free services. This article outlines some of these risks. This is by no means meant to be a comprehensive list, but rather some things to consider before deciding to use any particular API.

Data usage

Many times when the API is made available free of charge, what that means is you as a user are not charged. However, the service costs money to operate, and the data that the API receives may be used to monetize the service. Twitter is an excellent example of that. While Twitter is free to use, they sell data about your usage, search patterns, location, etc. to pay for the service.

It is important therefore to consider what information can be gleaned from the requests being sent to an API. For example, an API that allows you to determine a Zip Code from an address is incredibly useful, if the data about your search is sold, and purchased by a competitor, it could alert them that you are moving into a new market or, worse, provide them a handy customer list.

When deciding to use an API, verify that the data is not used externally, or sold to third parties. Also, ensure that the use of the API is documented, and notices to changes to the terms of use are carefully reviewed. Many times what starts out as appearing to be fine can later be updated to allow the vendor to resell your data.

It may also be beneficial to somewhat obfuscate or hide the data, by sending multiple fake requests so that they real query is masked somewhat.


Many API’s will use authentication. This can be done using something simple (and less secure) like a long string in the URL, or a cookie. These oftentimes are easy to see and compromise. While the data being sent may not be important, some API’s will charge or rate limit an application to a certain number of transactions. If the secret key is discovered, a malicious or unwitting user may effectively perform a denial of service by using all your requests.

Authentication really needs to use secrets that are changed on a regular basis, just like most companies do with passwords. These secrets really need to be kept secret and should not be stored in plain text in a GitHub repository for example, or buried in a webpage that someone can see by “viewing source”.


Depending on the sensitivity of your data and the API, it may make sense to encrypt the data using HTTPS (or something similar). While this may not be offered or a requirement, think about what sort of  information you are sending and make a conscious decision about whether it should be encrypted or not.

Treat the response as an attack

Treat the API response as you would any other data input and verify that you are getting the response you expect and just the data you are expecting. Some API’s look good, but can be used to exploit systems using cross-site scripting, SQL injection or other input based attacks.

Even if the API is good today, it can still be compromised later. Be certain to verify the content as well as the amount of data coming back and discard it if it looks wrong. For example if you have an API that takes an address and returns the US Zip Code, ensure it is only numbers and 5 digits, or 5+4 with a “-“ as a separator. If you get back anything else, alert the user and log a security event. Of course then investigate and possibly discontinue using the service.

This is by no means an extensive list of concerns with using public API’s, but just some thoughts to consider as you embark on your use of them. API’s are, to some extent, SaaS-based open source projects and need to be thoroughly tested before being used. It is also important to understand who built them and why. That can help you better understand unique threats that you may be exposed to by using them.

Be careful out there…

Rich Casselberry is a Risk Technologist at Liberty Mutual. In this role he helps determine risk of current and emerging technology, such as blockchain, Internet of Things, chatbots, and machine learning. Prior to Liberty,Rich managed the IT operations for Extreme Networks, ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
How to Create a Successful AI Program
Jessica Davis, Senior Editor, Enterprise Apps,  10/14/2020
Think Like a Chief Innovation Officer and Get Work Done
Joao-Pierre S. Ruth, Senior Writer,  10/13/2020
10 Trends Accelerating Edge Computing
Cynthia Harvey, Freelance Journalist, InformationWeek,  10/8/2020
White Papers
Register for InformationWeek Newsletters
2020 State of DevOps Report
2020 State of DevOps Report
Download this report today to learn more about the key tools and technologies being utilized, and how organizations deal with the cultural and process changes that DevOps brings. The report also examines the barriers organizations face, as well as the rewards from DevOps including faster application delivery, higher quality products, and quicker recovery from errors in production.
Current Issue
[Special Report] Edge Computing: An IT Platform for the New Enterprise
Edge computing is poised to make a major splash within the next generation of corporate IT architectures. Here's what you need to know!
Flash Poll