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
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Becoming a Self-Taught Cybersecurity Pro
Jessica Davis, Senior Editor, Enterprise Apps,  6/9/2021
Ancestry's DevOps Strategy to Control Its CI/CD Pipeline
Joao-Pierre S. Ruth, Senior Writer,  6/4/2021
IT Leadership: 10 Ways to Unleash Enterprise Innovation
Lisa Morgan, Freelance Writer,  6/8/2021
White Papers
Register for InformationWeek Newsletters
2021 State of ITOps and SecOps Report
2021 State of ITOps and SecOps Report
This new report from InformationWeek explores what we've learned over the past year, critical trends around ITOps and SecOps, and where leaders are focusing their time and efforts to support a growing digital economy. Download it today!
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll