0

I made own app via Laravel/Vue. It uses REST Api. My user after register has to enter own website address. Then he receives API Key and tracking code to paste on own site.

That tracking code sends Http Post request to my site in a certain situation. Simple Javascript. With that request he sends that API Key as one of params.

Server compares API Key with referer. If API Key is correct with key's owner website, api script works. If not it responses Forbidden.

Sad thing is that. I can get API Key from user's site(RMB -> Show source). Then I can run f.e. Postman, set token, other params, fake Origin and Referer and it will work!

  1. How can I protect my REST Api from fake calls? I would like to not use server-side.

  2. If it's inevitable I would also like to know why almost always people use two keys(key and secret)?

  3. Also would I be forced to write server-side script for few backend languages or it won't be problematic to run that one php script on RoR or Python server?(kind of stupid question but really important for me)?

Fifciuux
  • 581
  • 4
  • 5
  • Possible duplicate of [Best Practices for securing a REST API / web service](https://stackoverflow.com/questions/7551/best-practices-for-securing-a-rest-api-web-service) – Obsidian Age Mar 07 '18 at 20:29
  • 2
    you cant protect from fake calls when fake calls have same info as real ones. If your key is being used in client code, anyone can see it and access it. Your users should be using keys on server side code to prevent that. One possible solution is having the user enter the ip of his server, so that you only allow calls from that ip – juvian Mar 07 '18 at 20:29
  • Possible duplicate of [REST API Token-based Authentication](https://stackoverflow.com/questions/9773664/rest-api-token-based-authentication) –  Mar 07 '18 at 20:29

1 Answers1

0

If you are planning to encourage running a script that talks to your API on the client side (JS), then you really don't have lot of choices.

  1. as said, server-side is probably the safest choice
  2. consider it a username / password pair, though a lot of services use single tokens as well (so just one credential). I would recommend giving the client a key pair which can be used to authenticate and generate a token, which will need to be sent across all other API calls
  3. the question is a bit confusing, sorry :)
odino
  • 1,039
  • 8
  • 26