Are There API Terms of Use With Specific Language for Privacy and Security?

This is fifth part of ProgrammableWeb’s series on Understanding the Realities of API Security. It is based on the testimony offered by ProgrammableWeb’s editor-in-chief David Berlind to the ONC’s API Security and Privacy Task Force.  In the previous part -- Part 4 -- Berlind answers the following question posed by the ONC: Must Developers Be Certified For Privacy or Security Standards By Your Organization?

Such terms of use are very common and are written to address specific patterns as well as non-specific patterns.

In addition to the aforementioned Paypal example, another example on the specific-pattern front, Twitter’s Developer Terms of Use say the following:

“You will not attempt to exceed or circumvent limitations on access, calls and use of the Twitter API (“Rate Limits”), or otherwise use the Twitter API in a manner that exceeds reasonable request volume, constitutes excessive or abusive usage, or otherwise fails to comply or is inconsistent with any part of this Agreement.”

Terms such as these that address Rate Limiting are not uncommon.

You may ask “What does rate limiting have to do with security and privacy?” First of all, a well-managed API should automatically refuse service once the rate limit for the developer’s tier of service has been met. An increasingly less restrictive rate limit is one of the privileges that changes (for the better) as the developer’s contracted tier of service improves. But on the security and privacy front, rate limiting (something many consumers encounter when they they get locked out of a service after trying the wrong password too many times) is a common defense against brute force attacks. An example of a brute force attack is when a hacker tries as many user ID/password combinations as it takes to break into a digital account. A good rate limiting policy will limit the allowed number of failed attempts such that the hacker cannot cycle through enough guesses to compromise an account.

In 2015, compromising, thought-to-be-private, photos of several celebrities including Jennifer Lawrence were shared on the Internet after hackers allegedly penetrated the API for Apple’s Find My iPhone service; an API that allegedly had no rate limiting applied to it. Apple never came forward with the low-level details of the incident. But the hackers published the source code -- dubbed iBrute -- that they used to conduct their brute force attack on the API.

Such provisos to protect the API do not just appear in the API’s terms of service. Sometimes, they appear in the consuming application’s Terms of Service as well. For example, the National Hockey League’s branded mobile applications rely on APIs that the NHL does not make available on an LSUD basis. When a user launches the NHL mobile application, the user is immediately confronted with the following splash screens (Terms of Service):

national hockey league app

As can be seen from these terms, in an effort to protect its API and ultimately the security and privacy of its users, the NHL is confronting the user with terms that address some very specific scenarios and behaviors as well as some non-specific ones.

It should be noted that an API’s Terms of Service do not present a technical barrier to the compromise of the API. Hackers routinely ignore such terms. But they do set the stage for remedy if not legal recourse. For example, one of Twitter’s terms says the following:

“Take all reasonable efforts to do the following, provided that when requested by Twitter, you must promptly take such actions...Delete Content that Twitter reports as deleted or expired;”

In 2015, in a highly publicized API economy “incident,” Twitter sanctioned the Politwoops service for failing to remove its record of politicians’ tweets after those tweets had been deleted. Twitter deemed Politwoops in violation of its developer policy and, as a remedy, discontinued the service’s access to the Twitter API (a decision that Twitter has since reversed).  While I am not a lawyer, it is clear that terms of services for APIs are not only clearly articulated to support such remedies and legal recourse, but are also evolving to take into account new real-world behaviors that the authors of such terms of services did not originally anticipate.

In the next part -- Part 6 -- of ProgrammableWeb’s series on Understanding the Realities of API Security, ProgrammableWeb editor in chief David Berlind answers the following question posed by the ONC:  How Many Production Deployments Exist of APIs and Third Party Apps? 

Be sure to read the next Security article: Must API Developers Be Certified for Privacy or Security Standards by Your Organization?