6

I need for my app to consume a rest api service and since I will call it from javascript/jquery i need to expose it to the end user.

In this case I would also need to expose credentials to the end user, which is something I would like to avoid. As an alternative I am thinking of using a token that would replace sensitive credentials, but what concerns me is how to prevent an end user to reuse or recall rest api service misuse that same token with different params?

Bottom line, how to successfully protect application so only application can consume rest api and not the end user himself?

EDIT

This question raised a couple of doubts so I would like to make myself clear. For example: Javascript from my app contains an ajax call that calls a third party api. For example http://domain.com/api/insert-item?user=username&password=password&userid=1000&itemid=55555&itemvalue=10

What stops any user to change query string to userid=2000&itemid=55555&itemvalue=100

What stops any user to get our credentials for third party api and consumes it without permission?

  • 1
    "In this case I would also need to expose credentials to the end user, which is something I would like to avoid." Use tokens "recall rest api service misuse that same token with different params?" Checkout jwt. If your user is allowed to do something on your page, where is the problem if he uses your api? He has to use his own token. So he can only do things you allow him. If you have problems with spam requests then look at rate limits. – Michael Malura Jul 14 '15 at 13:39
  • @John: Your question is unclear, please rephrase. – Matthias Jul 14 '15 at 13:43
  • Take a look at oauth.net/2 – JF Dion Jul 14 '15 at 14:14
  • I have updated my question. – John Jul 17 '15 at 12:52
  • To your update: If you trust the user to pass in that information, nothing prevents them from modifying it. – user40980 Jul 17 '15 at 14:56
12

You can't.


Let me rephrase: Impossible


You could/should make it harder to use a token. Implementing a max-usage per token, a max life-time, ... It is however impossible to know if it is the scriptkiddie or your 'application' contacting your api.

A lot of people tend to forget that it is never the aplpication calling the api, it's the application, telling the client what api to call. Everything else is based on trust. And on the internet, trust is deprecated

  • Would you recommend any other techniques to limit the usage of token, maybe user IP? – John Jul 14 '15 at 11:50
  • 1
    Nah, just don't. When your application is allowed to do calls, but the user isn't. then the application should never be sent to the user in the first place. This sounds more like a problem where a user is allowed to do more then he should with a token. Maybe look into oAuth. An api should allow a User to do stuff. It shouldn't care about how (your application or something else) it is being called. – Pinoniq Jul 14 '15 at 12:00
  • 1
    @Pinoniq, Well almost all the mobile application does CRUD operations via REST API. So they all can be violated? I don't believe so. So how are they protecting their API's? All of them doesn't have their API open for public usage. – Krishnandu Sarkar Jul 14 '15 at 12:05
  • I think the whole question is completely unclear, so why discuss? – Matthias Jul 14 '15 at 13:44
  • All their API have proper ACL who determine if a certain user has access to certain operations on certain data. A token should login a user, and then the application should only allow operations that the loggedin user has access to. words to google are: ACL, oAuth. Maybe lookinto how the symfony ACL works – Pinoniq Jul 14 '15 at 14:14
4

I need for my app to consume a rest api service and since I will call it from javascript/jquery i need to expose it to the end user

That's your first mistake. As Pinoniq pointed out in his answer, it's not possible to secure client side code.

However, you can add your own server to the mix. Have your client side code use JavaScript / jQuery to make a call to your server, then have your server make the call to the 3rd party API.

It's not that hard1 to make your server secure. You can protect the credentials to the 3rd party API and servers are cheap these days - GoDaddy, Amazon, etc. will happily rent you what you need.


I see you edited your question. The answer remains the same - you cannot prevent the user from seeing or manipulating any data you send to the browser.

The fix is to change your JavaScript to something like

http://myserver.com/insert-item?parameters

Then, have your server make the necessary call to the 3rd party API.


1 "not that hard"... of course depends on how secure you need to be. For most people, it's not a big deal.

  • I have updated my question. – John Jul 17 '15 at 12:51
2

What stops any user to change query string to userid=2000&itemid=55555&itemvalue=100

Nothing.

As such you should not make this secure call to the 3rd party from the client app.

It should instead be made via your server, as that is the only place you can secure the sensitive authentication information for the 3rd party app.

So the client app calls a URL on your server, and your server makes a HTTP request to the 3rd party app, including your sensitive authentication information. When your server gets a response it returns this data to the client app.

The client app never needs the 3rd party app authentication information because it never talks directly to the 3rd party app.

0

I think you should not directly access the Third Party API from your JavaScript application. Instead, you should implement your own basic web services which is like a wrapper around the Third Party API.

You can then implement your own authentication method inside your own small web service or do not implement it in case it is not needed.

However, you could hide these calls behind some hard coded pages like:

Example.php would be your own service /example.php calls Third.Party/API/Example?Some=Complex&Strings=NoOne&Should=See

  • I do not want to protect my API. I want to be able for my app (authorized and unauthorized sections) to restrict fabricated calls to third party API. – John Jul 14 '15 at 12:17
  • 1
    In that case you should just implement an application where the user has to type in the hard credentials and then you send it to the server (over SSL) and get back a token which then can be used from now on. You will never be able to distinguish if the application call comes from the application itself or is just "faked" by a user who tracks what the application does and then does it by himself. We currently plan to do the same here in our application, since Basic Authentication is just not modern. – Matthias Jul 14 '15 at 13:40
  • Anyway you said you do not want to protect your API, but that is exactly what you have been asking for: "Bottom line, how to successfully protect application so only application can consume rest api and not the end user himself?" (I was so free to replace the first application with API or it makes just no sense, since an application cannot be protected in that sense) – Matthias Jul 14 '15 at 13:41
  • I have updated my question. – John Jul 17 '15 at 12:51
0

If your credentials are going out with your JavaScript, they can't be kept secret.

However, if your credentials are stored on the server, you can keep them secret, by having a server side function use them.

In this way, you can examine the incoming request from JS using your server side function, and determine if it's legitimate. If it is legit, you can pass it through to the rest API using your credentials, and if your, send back an error message.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.