DEV Community

Discussion on: Client and Server API Protection

orkon profile image
Alex Rudenko

When this end point is simply serving as a back end calculator, what level of authentication should my front end and server be concerned with? I'm thinking along the lines of pinning against my domain for a start but what else?

Is the endpoint public? Do you users have to authenticate in order to use it? If not, then you might be concerned with someone using the endpoint in their own app/script. There are two possibilities: 1) someone starts using it on another website (client side). To prevent this you can configure on your endpoint 2) someone starts using it in a desktop app or on a server. To prevent this, you can consider using or something similar. Ultimately, if the calculations you do are expensive and valuable, it is better to ask users to create accounts and give everyone a separate API key(s).

Would the usage of API token have any relevance in this scenario? Since the information is purely public I don't have a use case that would require a look up of a user or similar, but do API tokens/keys have a usage here that I haven't thought about?

If someone starts to over-use your service, you can change the token hard-coded in your client app, thus, preventing unauthorized usage. But unauthorized users can copy the new token as soon as they discover that the old one is not valid.

What measure of server side protection should be in place? CORS? Rate limiting / Throttling?

CORS and rate limiting by IP might be helpful, in my opinion. Rate limiting would work the best if you know all of your clients and can have per API token limits.

imthedeveloper profile image
ImTheDeveloper Author

Excellent response Alex, thanks for putting the time in to this. To answer your questions:

  • Is the endpoint public? Yes in that it is viewable in the client side code as well as being able to see the request being made through network dev tools.

  • Do users need to authenticate? No, the calculator is in the public domain and information provided does not need to be tied to a particular user.