I have an API Key to a paid service. This API is invoked from an unauthenticated page on my site. I am proxying the request to the paid service through my backend server. I have also added CORS on the API to make sure it is called from my site.

THe above protections work when a user is accessing it through the browser. However, the API can be accessed from postman and this could result in me having a huge bill for the paid service. What is the best way for me to ensure that the API is only called from my JS client?

  • 15
    How does the third party service prevent such abuse? What do they recommend customers to avoid such abuse? Mar 22, 2021 at 12:45
  • 28
    Also remember CORS does not prevent intended DoS calls, as it is enforced only by the browser. CORS has a different purpose: disallow others from embedding your API in their page Mar 22, 2021 at 12:46
  • 3
    With a lot of third party API's this is done not by the caller but by whitelisting the domains the third party service will respond to requests from (e.g. Google Maps). Mar 22, 2021 at 14:14
  • 2
    How does ensuring it's only called from your JS client solve your problem? What checking does the JS client do to make sure the calls aren't abusive? It is not possible to give a useful answer to your question without understanding precisely how your JS client prevents abuse -- because that's what has to be replicated. Mar 22, 2021 at 18:00
  • 4
    Let me get this straight... you are paying for a publicly available API... and the host that provides the API is charging per use... and has NO method to restrict or control access call to it? Zero? White listing IP addresses? token exchanges to login? 2FA authentication? NOTHING? I find that hard to believe..
    – WernerCD
    Mar 22, 2021 at 21:54

9 Answers 9


You can't. Even for things that aren't a website, like an embedded device, somebody could always open up the hardware and inspect the firmware or, in an extreme case, de-cap the chips and examine them with an electron microscope. For websites, it's utterly trivial. Anything and everything your client can do, so can any other client. That's inherent in the decentralized nature of the Internet and also in the way web pages work.

There are things you can do to limit abuse, like having your server make the request (rather than the user's browser) and limiting the rate at which it will do so on your users' behalves. Authentication might potentially let you limit requests per user and/or pass along the bill. Actually controlling the client used to talk to your server (or the third-party one) is impossible, though. At best, you can obfuscate your code and try to hide the access key, but in the end, you can't hide it perfectly.

  • 1
    If the service is intended to be used solely from a particular web page, it may be possible to frequently change some aspects of the API, along with the web page that accesses them. Someone who doesn't know in advance how the web page will change would have no way of designing code beforehand that would accommodate the change to the API without disruption.
    – supercat
    Mar 22, 2021 at 17:28
  • @CBHacking - the exact scenario is that our sign up form uses an address validation service when customers put in their address. This is a paid service. So abuse could be the API being flooded with requests to use up our credit, but what im more worried about is cbhacking.com using the service for their customers sign up page too. It wouldnt be a DoS or an attack that rate limiting would pick up. Mar 23, 2021 at 2:44
  • 8
    For something like that, your best bet by far is to call the service from your server (not from the user's browser). Somebody who wants to abuse your access can still do so, basically using your server as a proxy to the service, but it's more effort for them, you can occasionally change things to break such abuse, and you can do stuff like monitor the IP addresses that requests come from and block abusers. Anything else requires putting your access key in the web content somewhere, where anybody who wants to can grab it and use it.
    – CBHacking
    Mar 23, 2021 at 5:00
  • 1
    The statement in OP "I am proxying the request to the paid service through my backend server" suggests that they are calling it from their server and not directly from the user's browser. Mar 23, 2021 at 18:59
  • 2
    @JohnnyDonalistic Why on the sign-up form? Why not in the profile..then you could send confirmation email?
    – paulj
    Mar 23, 2021 at 20:03

Implement authentication and allow the proxying of the requests for authenticated users only.

Otherwise your service will become known with the time and other people or even companies can use it, and you will not be able to prevent it.

  • Thanks for this. The service can not be restricted to authenticated users only. It is a functionality that is needed when people sign up to our products. So we cant have it retricted to authenticated users only. Mar 22, 2021 at 6:50
  • 1
    @Infra Someone else can use the service whilst we pay for it. If there was a way to ensure that the API call is only made by our client, then the problem would be solved. Mar 22, 2021 at 9:03
  • 24
    "It is a functionality that is needed when people sign up to our products." - So they are not your clients yet. Why do you want to restrict it to one part of not-clients and allow for another part of not-clients?
    – mentallurg
    Mar 22, 2021 at 9:53
  • 11
    What about CAPTCHA? Mar 22, 2021 at 12:48
  • 3
    Have people create an account as part of signing up for your products, then you could use authentication. Something similar to how you might need to provide information to get a quote or show the correct price based on where someone is located.. but make them create an account on your site before allowing them to get whatever info is needed from this API call
    – John-M
    Mar 22, 2021 at 16:23

As others have pointed out, you cannot completely prevent someone from calling your API if it's exposed to the internet unless you enable authentication.

If you want to restrict usage and make it inconvenient for abusers to call your API, you can issue a token on page load (CSRF token) and require that token to be present in the request to the API - that way the API will be callable from a browser that initiated a page load.

The API will not be directly callable without the token issued by your backend, but of course there are ways to automate web browsers via headless implementations to go around this.

You can implement server side quotas based on IP address - again there are ways to go around this.

A sufficiently motivated attacker will always find a way around it if there is significant value in your API.

However is it possible that you are overestimating the value? Maybe you can take an iterative approach: implement basic rate limiting, see how much abuse you get, improve your safeguards or disable when it generates costs that are beyond what you would be willing to accept.


What is the best way for me to ensure that the API is only called from my JS client?

You don't.

Any sort of DRM that you put into your JS code -- like a secret API key that the JS client uses to prove to the server that it is an authentic client -- won't stay secret for long since javascript and the HTTP traffic that it generates is incredibly easy to inspect in a modern browser.

Instead, you need to authenticate and rate-limit the user. You've said that this API is called before users have accounts, but here are some ideas for rate-limiting:

  • reCAPTCHA so the user has to identify some bridges and stop signs each time they call this API,
  • make sure your front-end reverse proxy is setting the X-Forwarded-For or Forwarded header and then apply a rate-limit per client IP address. (though getting these headers right is surprisingly tricky, so I don't recommend an IP-based approach especially if your server is in a cloud environment)
  • If this is the kind of page where you have to fill out and submit a form, then you could even do something like give them a session cookie when they land at your site and only do the 3rd party API call if their session cookie is >= 10 seconds old (and reset that counter after doing the 3rd party API call).

The last advice I can give is don't make it useful; if you are directly proxying the 3rd party API (ie client gets to set whatever request content and gets to see the full response) then yeah, you've built a service where people can use the 3rd party API on your credit card. Don't do that; have the content at least partially filled in by your backend, or use the response in your backend rather than sending it to the JS client, or something.


Why call the third party API from your JS code at all? If this API has the potential to cost you a lot of money, move all of the code that interacts with that service to run on the server side. Don't leave anything on the client side that gives a malicious user enough information to make those API calls directly. Your JS code can make a request to a small web service running on your server, and that service will encapsulate everything related to the third-party API. Malicious customers could still spam your wrapper service with requests, but since you're now the gatekeeper between the user and the third-party service you have more leeway to implement rate limiting, add delays to requests, cache results, block IP addresses doing questionable things, or whatever else your service needs to do to deter abuse (based on the nature of the third-party service and how you're using it).


First and foremost, remember that your goal is not to totally eliminate use of your API other than via your client software, but to discourage unwanted use and limit any financial losses caused.

To determine whether measures taken to limit unwanted use are effective, make sure you have good visibility into how many API requests are being handled, how much those requests are costing you, where the requests are coming from, and so on. Periodically check the usage and see if it seems reasonable given the rate of new sign-ups. Rate-limit both the total volume of requests and volume per source IP, etc. Throttle users who are making too many requests.

I don't know what business you are in, but if you know that all your legitimate customers are in a certain country or region, you could use geolocation to block requests coming from other regions.

Distribute your client software with an access key which is different for each download of the software. (Generate an access key and embed it in the client installer on each download.) Track the usage of each access key. Expire access keys after a reasonable period of time or number of uses. (In case a legitimate customer gets stuck with an expired access key, your client software could pop up a message asking them to phone your company to have the key reactivated.) Or, if the key is only needed when the customer is signing up for your service, as you said, you could expire it immediately after they successfully sign up.


Do it in 2 steps.

  1. Pre-register user without using your valuable service. Send user an Email to confirm the registration.

  2. When user opened your Email and launched confirmation process, you can use your valuable service (Captcha? Credit card validation? Address validation? Whatever.)

This has following advantages:

  • Bots will need to use real Emails. If you see too many registrations in a short time from the same domain, you can limit them or block the whole domain.
  • If some other company wants to use your service, their users will receive registration Emails from your company. The most companies will not want it and that's why they will not use your service.

Thus the number of non-clients who use your service will be very small. The most users will be your real clients.

I think this is the best you can get in your case.


There are the so called API management systems like 3scale, API Umbrella or whatever. You can setup throttling, authentication, firewall, etc.

This is more in line with @bta's answer as you are effectively doing it on your server side. Still this is an option to consider in case you do serious API integrations.


There's a header info in the Request called sec-fetch-site. If it contains same-site or same-origin, the call came from your site.

But since I believe this is so, maybe too, simple, I'm missing something?

  • I don't want to sound rude or mean, but if you're unsure yourself, why answer?.. Mar 31, 2023 at 17:35
  • Thats not an interesting comment. If the info in the first part was ok, why dont you spend time commenting that? Since the amount of un-upvoted answers are far greater than upvoted onces on theseforums, i didnt see a reason not to give a suggestion. Unlike many others i just told i was uncertain, maybe to get some smart feedback. But nah.
    – Abeabe
    Apr 1, 2023 at 10:40
  • 1. This is not a forum 2. There's already good answers to this question 3. Elaborate how using these headers would help at all. Because all they do is during fetch or loading the site "verify" whether the same TLD+1 origin is being used for example. And I think that goes in another direction that the OP wanted to hear from. Apr 2, 2023 at 10:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .