Hey. My project uses requests to the external API, from which I receive data. The request to the API is initiated by sending an AJAX request to PHP. In order to avoid API abuses (for example, someone will just send spam to the PHP file with requests, and my server will send spam to the API, for which I may quite rightly be disconnected from the API) I took the following measures:

1) At the beginning of each PHP file I use Response Header Access-Control-Allow-Origin :

header('Access-Control-Allow-Origin: https://search.' . $origin); // где $origin - example.com

2) After the data sent from the client exists (check isset($_POST['data']) && !empty($_POST['data]) ), I check whether the request is an AJAX request:

 function isAjax() { return !empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest'; } if(isAjax()) { //do smth }

Are these measures enough or is there some simpler way to protect against extraneous requests?

  • one
    Why do you think that what has been done protects you from something? Headers are set by the client. You just make sure that a respectable browser fulfills the request to you via ajax. But usually DDoS is done by specialized programs that fake any headers. - Mike
  • one
    As a result, you can not trust any information received from the client, including any headers. All that you can do is to keep statistics of calls from each ip-address and take measures for anomalies - Mike
  • @Mike hmm, the only way to bypass my protection that I see now is to query an IP address with a forged Host header (where instead of an IP address there will be a domain). Access to the site by IP-address is now closed (access is possible only by domain). And the site itself, in fact, is not vulnerable to L7 DDoS attacks. I haven't seen the HTTPS flood for a long time. There are too few proxy servers that fully support HTTPS, 301 redirects and JavaScript. - JamesJGoodwin
  • By the way, this is why many people choose the free CloudFlare plan, where you can turn on I'm Under Attack , which includes checking your browser for cookies and JavaScript. To carry out such an attack - big expenses are needed - JamesJGoodwin
  • one
    So the only way is: 1. make sure that the client is legitimate, it has all the expected session cookies. 2. look at the number of requests from the client within this session. If it appeals too often, something is wrong here, it is necessary to take action. 3. Make sure that the session just does not set, without authorizing the user, for example. 4. Transfer item 2 to all sessions of an authorized user - Mike

1 answer 1

These measures will not help in any way if someone decides to send a couple of extra requests to your API. Access-Control-Allow-Origin will help only if someone on another site places a form or script to send requests through client browsers that access this other site.

A good way to avoid unnecessary requests to a third-party API is to cache responses and use them for a while, with which Memcached will help. For example, if it is an API with a currency exchange rate and one method without parameters, you can make a request for an API, save the response for several hours and use it instead of the API, and after these several hours, make another request, and so save.

If the user can transfer some data, because of which requests to the API can change - for example, the VKontakte API to search for music, where the user can enter any phrase - it will be difficult or even impossible to cache the requests, in this case you can try different options (depending on how the API is used and what features it has):

  • If the API allows, you can download a larger amount of data from the API with a smaller number of requests and save it on your server, when you receive requests from customers, first search for the saved data and then contact the API if there is no need in the saved data
  • If the API allows you to transfer several keywords (for example, the VK API allows you to transfer hundreds of user page IDs to search pages in order to avoid heaps of unnecessary requests for each ID), you can create a queue mechanism on your server - save all requests from users to a certain stack and send it every half second / second / how much you need on the API, then clear
  • Check the client's IP address and limit the number of requests for it. This will not protect against attacks from different IP addresses, but at least someone will have to spend more than a couple of minutes on a bad deal, and it will not be possible to abuz the server by simply updating the browser page. As a protection layer, you can use free Cloudflare with enhanced client validation modes, it will be harder to harm your server (most importantly, remember to block requests that are not going through Cloudflare)
  • If your API is rarely accessed, you can simply make a global limit on the number of requests for a certain period of time. If there is an abnormal volume of requests, simply reject them with a request to try later. But it is worth considering that with a constant flow of requests, your service will be essentially inoperative, although it does not harm your friendship with that third-party API, so it is worthwhile at the same time gradually blocking sources of abnormal traffic.

But this is my amateur opinion, I think it is worth reading the professionals in this field.