0

I have currently developed a backend app that has some important functionalities. I want to consume my backend endpoints from my frontend but I want to be sure that only my fronted calls the backend endpoint and no other. Currently anyone that access my web-app can take advantage of the functionalities (I do not require any user registration or authentication).

How can I be safe that my backend is not being called form other possible malicious attackers that may try to steal the functionalities of my backend?

I have read some other posts regarding solutions how to secure a backend app that do not require user authentication but none has a precise and secure way for that. Some say enabling CORS but during my experience I can say that CORS can be manipulated easily with the help of a simple browser plugin. (not speaking about mobile apps that do not consider it at all)

I would really appreciate if I would have some opinions in case of a web-frontend-app, mobile app and other backend systems that would try to call my API and how can I stop them.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
john bowlee
  • 125
  • 1
  • 11
  • Does this answer your question? [Is there a way to secure a public endpoint?](https://stackoverflow.com/questions/59328748/is-there-a-way-to-secure-a-public-endpoint) – root Dec 10 '22 at 23:13

1 Answers1

0

Typical front-end authentication would be best (OpenID, ...).

If you want something different, you could check on your backend whether a specific header with a specific token is sent in the query. If it is not then you send back a 401 HTTP code.

This requires that your customers somehow get that token (through some registration process, probably) and then keep it long-term (it can be stored in LocalStorage but can be lost when cleaning up the browser)

OWASP Authentication is a good source of information.

WoJ
  • 27,165
  • 48
  • 180
  • 345
  • Thank you very much for your response but issuing a token to that client and saving it to LocalStorage is not safe and it can be extracted by anyone since front-end code is exposed to the user and they can use the same token to call from another client – john bowlee Dec 10 '22 at 18:57
  • @johnbowlee I am not sure I understand. The token stored in `LocalStorage` is not available outside of the browser of the user who accesses your API. It cannot be "extracted". The front end code is obviously exposed to everyone (it is there to be ran in a browser) but that does not make the content of `LocalStorage` of a specific user available. – WoJ Dec 10 '22 at 18:59
  • yes is not but you as a user can see what is the token saved in your local-storage and you can use it to call from another consumer that you have created. – john bowlee Dec 10 '22 at 19:01
  • @johnbowlee ah, yes, certainly. But in that case you cannot rely on anything that belongs to the user because it can always be falsified. You would need to use something outside their control, an IP range for instance. It is not possible to have a frontend authentication that cannot be replayed if that authentication is known to the user. – WoJ Dec 10 '22 at 19:02
  • ok we can use IP to make some controls but what action can we take in case of a mobile app. Do they have any IP attached? – john bowlee Dec 10 '22 at 19:31
  • @johnbowlee: yes they do - every call you will get on your API will carry the source IP of the caller. IP filtering is one of the worst solutions, it can be used as a last resort because it is not salable, IPs change, you may get an exit IP behind which there are plenty of users, etc. You can try some tricks about not allowing concurrent access from several IPs but frankly, this is not the way to go. Authentication is a solved problem and your case is known to be hopeless. As a rule, everything that comes out of a device you do not control is subject to manipulation/extraction. – WoJ Dec 10 '22 at 19:35