Protecting the COUNTER API

The internet is a dangerous place. Internet traffic is full of automated bots, scripts, and other malicious actors. Therefore it is legitimate to protect any resource that is exposed to the internet from potential attacks.

The COUNTER API (formerly sushi) is no exception and has some built-in protection mechanisms which are part of the Code of Practice.

• The COUNTER API must be provided over HTTPS. This ensures encryption of the traffic in transit.
• In addition to the traditional customer_id and requestor_id credentials, the COUNTER API also supports API keys for enhanced security.
• The API contains a throttling mechanism to prevent abuse by responding with several different Exceptions. These signal to the client that it needs to slow down or postpone its requests. For example, Exception 1010 means that the COUNTER API is too busy to execute a request, 1011 means the report has been queued for later processing, and 1020 means that the API client has made too many requests in too short a time.

So the COUNTER API does have protections. But there are some protection mechanisms which don’t make sense in the context of the COUNTER API. Report providers must not use these restrictions on the COUNTER API:

• IP address based authentication. This used to be permitted under the terms of Release 5, but it caused a lot of problems!
• JavaScript based Captcha. The COUNTER API was created explicitly as a machine-to-machine interface, so Captcha tools designed to make a user prove they are human makes no sense.

Please keep this in mind when you are developing your COUNTER API service. Using the right protection will make life easier for your library clients and harvesting tools without compromising security.

Thank you to Beda Kosata for this latest tech blog post