As more and more data is exposed via APIs either as API-first companies or for the explosion of single page apps/JAMStack, API security can no longer be an afterthought. The hard part about APIs is that it provides direct access to large amounts of data while bypassing browser precautions. Instead of worrying about SQL injection and XSS issues, you should be concerned about the bad actor who was able to paginate through all your customer records and their data.

Typical prevention mechanisms like Captchas and browser fingerprinting won’t work since APIs by design need to handle a very large number of API accesses even by a single customer. So where do you start? The first thing is to put yourself in the shoes of a hacker and then instrument your APIs to detect and block common attacks along with unknown unknowns for zero-day exploits. Some of these are on the OWASP Security API list, but not all.

1. Insecure pagination and resource limits

Most APIs provide access to resources that are lists of entities such as /users or /widgets. A client such as a browser would typically filter and paginate through this list to limit the number items returned to a client like so:

<code style="box-sizing: border-box; font-family: Monaco, Consolas, &quot;Lucida Console&quot;, monospace;"> skip  =  0
 while  True :
     response  =  requests . post ( 'https://api.acmeinc.com/widgets?take=10&amp;skip='  +  skip ),
                       headers = { 'Authorization' :  'Bearer'  +  ' '  +  sys . argv [ 1 ]})
     print ( "Fetched 10 items" )
     sleep ( randint ( 100 , 1000 ))
     skip  +=  10
</code>

However, if that entity has any PII or other information, then a hacker could scrape that endpoint to get a dump of all entities in your database. This could be most dangerous if those entities accidentally exposed PII or other sensitive information, but could also be dangerous in providing competitors or others with adoption and usage stats for your business or provide scammers with a way to get large email lists. See how Venmo data was scrapped

A naive protection mechanism would be to check the take count and throw an error if greater than 100 or 1000. The problem with this is two-fold:

For data APIs, legitimate customers may need to fetch and sync a large number of records such as via cron jobs. Artificially small pagination limits can force your API to be very chatty decreasing overall throughput. Max limits are to ensure memory and scalability requirements are met (and prevent certain DDoS attacks), not to guarantee security.This offers zero protection to a hacker that writes a simple script that sleeps a random delay between repeated accesses.

<code style="box-sizing: border-box; font-family: Monaco, Consolas, &quot;Lucida Console&quot;, monospace;"> skip  =  0
 while  True :
     response  =  requests . post ( 'https://api.acmeinc.com/widgets?take=10&amp;skip='  +  skip ),
                       headers = { 'Authorization' :  'Bearer'  +  ' '  +  sys . argv [ 1 ]})
     print ( "Fetched 10 items" )
     sleep ( randint ( 100 , 1000 ))
     skip  +=  10
</code>

How to secure against pagination attacks

To secure against pagination attacks, you should track how many items of a single resource are accessed within a certain time period for each user or API key rather than just at the request level. By tracking API resource access at the user level, you can block a user or API key once they hit a threshold such as “touched 1,000,000 items in a one hour period”. This is dependent on your API use case and can even be dependent on their subscription with you. Like a Captcha, this can slow down the speed that a hacker can exploit your API, like a Captcha if they have to create a new user account manually to create a new API key.

#api-security #api-integration #api-analytics #security-of-api-keys #ddos-mitigation #endpoint-security #restful-apis #hackernoon-top-story