[Closed] Excessive Google Maps Geocoding API Usage

[Author]

Posts

[dominicV]

We have become aware of an issue on a client site where the Google Maps Geocoding API is being called excessively from this site, also the Places API, but the Geocoding API more so.

This is a property site, which does have a property importer, however, disabling the importer completely has no effect on the usage of the API.

I have also tried disabling front end use of all Google Maps related functionality, which causes usage of the Places API to cease, but Geocoding continues.

Additionally, I can see from GCP that the API key that is entered into the Toolset settings for the server-side requests, so there is something going on in the background causing this. NB. this key is already restricted to our server IP address, so it's definitely coming from the site.

I've checked the option to view missing cache entries in the Toolset settings, but none are returned.

How else can I find the source of these calls?

[Minesh]

Hello. Thank you for contacting the Toolset support.

Can you please send me full page screenshot of Maps settings page from:
=> Toolset => Settings => Maps tab.

Could you please send me debug information that will help us to investigate your issue.
=> https://toolset.com/faq/provide-debug-information-faster-support/

Also, can you please make sure that only Toolset maps is using that API key and not any other plugins or theme or anything else.

[dominicV]

Hello,

Debug info attached and settings screenshot uploaded.

I can confirm there is nothing else using these API keys, I have done a lot of testing, including, for example, deactivating the maps plugin for a couple of hours and observing in the GCP console that requests to the APIs fall to 0, so I am confident the requests are coming from here.

[Minesh]

Do you have distance custom search publicly accessible? If yes, can you make sure that it should be accessible for login users and not available publicly.

Do you have any form that uses address field? If yes, is that publicly accessible?

You can also try to investigate what field is used address the requests to map are increase with what domain and what page?

Please check the following doc that might be the alternative way that help you to cut the cost:
- https://toolset.com/2022/10/how-toolset-and-the-maps-static-api-can-help-you-cut-costs/

Please check the following related ticket that might help you:
- https://toolset.com/forums/topic/high-geocoding-usage-costs-from-google/#post-2360535
- https://toolset.com/forums/topic/spike-in-google-geocoding-api-requests/

[dominicV]

Yes we do have distance custom search and an address field that are publicly available. It doesn't make sense for our use case to ask users to register for the site in order to use these functions.

That said, I had disabled the search page all together for a couple of hours yesterday to test, during that time I saw that usage of the Places API had reduced to 0, which there was near no change to the usage on the Geocoding API, leading me to believe that this was a backend function that was driving the usage.

[Minesh]

Yes we do have distance custom search and an address field that are publicly available. It doesn't make sense for our use case to ask users to register for the site in order to use these functions.
===>
I agree on that.

That said, I had disabled the search page all together for a couple of hours yesterday to test, during that time I saw that usage of the Places API had reduced to 0, which there was near no change to the usage on the Geocoding API, leading me to believe that this was a backend function that was driving the usage.
===>
There could the spam/bot attack on your site so please check for that and block such requests.

As suggested with reference ticket I shared:

1) Recreate the Google Map API key, and add domain restrictions to it.
- https://toolset.com/course-lesson/creating-a-maps-api-key/

Please register both public and server API - "For added protection of your API keys, you may want to set up a 2nd key for server-side requests:".

2) Follow Google document to add daily cap on usage to your protect
- hidden link

[dominicV]

OK, I've created new restricted keys for the site so I'll monitor their usage. We also already added quotas for the maps APIs to protect us from the cost. Interestingly, even though we are now over the quotas we have set, I can't actually find any functionality on the site that doesn't work, other than the "Check API" option in the Toolset settings, which shows "OVER_QUERY_LIMIT", as you might expect.

Is there any way you can suggest that would enable me to log all of the backend requests being made to these APIs? i.e. can you tell me which files in the toolset-maps plugin makes the calls? It might give me some clues about what processes are triggering the requests.

[Minesh]

Well - there are API calls in almost every script located in plugins/toolset-maps/resources/js/. and almost all of them are loaded in the backend.

Regarding PHP API calls, they only happen in plugins/toolset-maps/includes/toolset-common-functions.php over the method get_coordinates_google. Look for the wp_remote_get call.

You may get better idea when you make a request and check what JS files are used and using what file the call is made .

[dominicV]

I found that code in the toolset-common-functions.php file and I've set it to log to the php error_log every time it makes a call, and I started with logging the address.

This file is the one that is making the calls, and the address each time is either just "2024" or "2025".

No idea where that could be coming from...

[Minesh]

Well - I'm not sure - you may check with Google Maps API support if they have any feature to log the request from where its coming from and what source.

[dominicV]

No, sorry, I don't understand why that would be your advice. I'm currently logging from the toolset-maps plugin. It is this plugin making these calls, repeatedly, using addresses that are not even addresses. If those odd addresses are coming from our site data, fine, but the Toolset plugin is making the excessive requests, there's no doubt about it.

[Minesh]

Can you please confirm that you see the address log for the address "2024" or "2025" even only Toolset plugins active? If yes:

Can you please send me admin access details as well as all details how can I see the issue and where can I see the logs.

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I have set the next reply to private which means only you and I have access to it.

[dominicV]

I actually may have found some information about where these are coming from. The searches, which gave these values as addresses:

- 2023
- 2024
- 2025

I added some logging and found that when these occurred, $_GET['toolset_maps_distance_center'] was populated with the corresponding "address" above.

I thought this was strange, since it appears to be coming from the front end, so I disabled the front end search page again, but these searches were still being logged, which tells me that the requests are likely coming from somewhere other than the front end.

I have added some code to the functons.php file for this site like this:

```add_filter( 'init' , function() {

if( ! isset( $_GET )) {
return;
}

if( ! isset( $_GET['toolset_maps_distance_center'])) {
return;
}

$value = $_GET['toolset_maps_distance_center'];

if( strlen( $value ) !== strlen( intval( $value ))) {
return;
}

error_log( 'invalid search blocked' );
die( 'not-allowed' );

});```

Since then, I have validated that the searches appear to be getting blocked and logged. The requests seem to have been reduced in the GCP console, but I will continue to monitor the situation.

[Minesh]

ok - fine. Feel free to share your findings.

[dominicV]

Yes, I can confirm that these requests have been the source of the overuse of the Geocoding API. There is still a suspiciously high volume of requests calling the Places API, but nowhere near as many.

I assume from this that Toolset Maps does not do any validation on requests coming for location searches that prevent abuse of this type. When I was testing this, I wasn't, for example, sending any sort of nonce value into the server, and so it seems that bad actors are able to send these requests directly to the server from anywhere...

I think this type of check should be done as a minimum, with a potential option of checking that an address actually looks like it's an address... Is there a case for doing a location search based on a purely numerical value? Perhaps elsewhere, but I don't think there would be in the UK...