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.

Authentication

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”.

Encryption

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…