Balance depleted 3 times in a day (without any increase in traffic)

Our prepaid balance got depleted yesterday 3 times and we had to disable automatic payments because we’re not getting any more traffic than normal and what balance was left from yesterday is now depleted again, so some pages of our website are not working.

We have done this:

  • a DEV key whilelisted only for LOCALHOST, that one will never be on the public website
  • a PROD key whilelisted only for our domain
  • changed the account password (just in case) and deleted the keys that were created before changing the password

It seems as if someone is using our public key (no way to hide the one in the javascript code in our website) to hammer TomTom services using our key.

Has anyone got attacked like this as well? We’re just hemorrhaging money. With the number of visitors we get that should have been enough for one year of traffic.

Thanks.

Some developers suggest to move APi requests from browser to the backend: How to protect an API Key when using JavaScript? - Stack Overflow

In my opinion that also doesn’t solve the issue in 100% because you still need to query backend somehow with a code that is also public.
But maybe if you add some custom security mechanisms + code obfuscation, then this could be sufficient to discourage this person.

Thank you for the suggestions.
Yes, I’ve been thinking of some obfuscation.
Having to do requests to TomTom services in the back-end would add lot more latency to the application (too many round trips) and also complexity would be significantly more. It would almost defeat the purpose of using an API to simplify things. Besides, I’m not sure I could do all calls from the back end.

Also, the rate these requests are being submitted (because the balance is just evaporating) and from all the diff. locations they could have being submitted sure should look a lot like a DDOS attack on the account. I was hoping a company the size of TomTom would have some sort of protection against such attacks.
Thanks again.

But the problem is how to determine which request is coming from a valid client and which one is coming from someone that stolen the key.