Security Question - Limit call to method only from my app / limit time interval call

help
1

Hello,

I have a question linked to security or to better understand how Meteor works.

Let’s say I have a public method, that can be called on click for every users even non connected ones, e.g.: on click get the latets five comments of my website (or any API call).

How can I (or is it inbuilt):

  • prevent an external server to call and simulate this method call and get the data: so control only my frontend is calling this method? I don’t want someone to be able to simulate he is calling this public endpoint and have access to the data in any other way than clicking the button on my website.
  • limit the number of calls per interval of time per users, who are not connected users ? It is a public endpoint, anyway to limit the number of calls per user clicking on it ?

Thanks in advance for any hints to solve this.

Have a great end of year holidays.

2
  • prevent an external server to call and simulate this method call and get the data: so control only my frontend is calling this method? I don’t want someone to be able to simulate he is calling this public endpoint and have access to the data in any other way than clicking the button on my website.

In some sense, it’s natural/ok for your methods to be called be entities other than your front-end or your application and as long as you implement proper security measures like ensuring authenticated users can only call it if it mutates users data.

  • limit the number of calls per interval of time per users, who are not connected users ? It is a public endpoint, anyway to limit the number of calls per user clicking on it ?
3

Thanks for your input.

For point 1 our problem is the following. We have a paid API that people will access with api keys, and so on… so full protected, safe… But at the same time we want on our front page to have a “preview” of this API, a little form with the params to put in and see the results and obvisouly we’d like to limit this preview in usage so that people wouldn’t abuse the preview instead of going for the real paid API :smiley: I don’t have issues in securing the app, just this particular problematic is giving me some headaches.

For point 2: thanks I’ll have a look at this package, it may solve the problem altogether.

4

Allow users to generate a rate limited API key that can be used for the example e.g. max 10 calls per ip address

Or a time limited API key e.g. 10 minutes

5

You can use kind of captcha verification or rate limited API key as @rjdavid solution.

6

We want the front use to be for non developper users, not testing our API, but using it. Anyway it gives me some leads. thanks a lot.

7

That is easy. Click a button and automatically generate a rate limited api key in the background.

8

Yeah but anybody could use the trick multiple time not to have limitation. I think there is anyway a “loophole” whatever solution I find. If I make it public without restriction through a form there’ll always be a way to abuse it for someone wants too. I’ll work on putting safeguard on the server side to prevent abuse (rate limitation, check the connection is made from the frontend, etc…) and it should do the trick.

9

A nonce could help you determine the request came from a legitimate user on your frontend.

Say a real-user lands on your site.

  • You create the nonce, store it in their browser, as well as somewhere server-side.
  • When user tests the frontend API demo, the browser-stored nonce is sent with the request.
  • Compare nonce from browser to nonce server-side.

Another approach to protect people “gaming” your demo API could be to use a magic link. This would remove some of the anonymity of a user but could help safeguard how much your API is impacted.

  • User requests the ability to test the API.
  • Only way they can test the API is through a link that you can verify server-side.
  • So they enter their email and you store it, create a special token and append it to the API-demo url.
  • User’s email must be valid so that they can check their inbox and click the link. No real inbox (i.e. fake email), no access.
  • When the user clicks the link and arrives on your page, you can do your server-side checks: i.e. is link valid, have they used up all their API attempts, etc.?

One thing to guard against would be people re-using, say, an address using the “+” method. We see this used with Gmail accounts a lot. Some platforms will treat example@gmail.com as different from example+1@gmail.com or example+2@gmail.com, but in reality either of those emails will hit the same inbox.

1 Like