loading...

Client and Server API Protection

imthedeveloper profile image ImTheDeveloper ・2 min read

I'm setting about implementing a very basic API which takes a POST request from a web form and crunches some calculations server side before responding with the output of the calculation in the API response which is then rendered by the client.

The form appears on a statically generated website, with heavy traffic and therefore there is no server side rendering to hide credentials behind. I'd love an open discussion and any reference to good resources which would help to increase my knowledge on what level of API security should be in place when dealing with static websites requesting against server APIs. I've come from a typical MVC world where the server would take the request, render the template and ultimately provide the whole page back to the user.

General Questions:

  • 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?

  • 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?

  • What measures of protection should live on the client side? Right now I believe that whilst I know my implementation is a web form, I should really ignore the TYPE of client since anyone can spoof a browser to make a request. Is this valid and therefore I should focus on the security at the API gateway instead of the client?

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

Posted on by:

imthedeveloper profile

ImTheDeveloper

@imthedeveloper

Developer 😎 Business Analyst 🌍 Solution Architect Still a developer at ❀ and spend a lot of my time building personal and client projects from home.

Discussion

markdown guide
 

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 developer.mozilla.org/en-US/docs/W... on your endpoint 2) someone starts using it in a desktop app or on a server. To prevent this, you can consider using en.wikipedia.org/wiki/ReCAPTCHA 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.

 

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.