I’m developing a RESTful web application that uses some popular web frameworks on the backend, say (rails, sinatra, flask, express.js). Ideally, I would like to develop client side with Backbone.js. How do I allow only my javascript client side to interact with those API calls? I don’t want those API calls to be public and called with curl or just by entering a link in the browser.
As a first principle, if your API is consumed by your JS client, you should assume, that it is public: A simple JS debugger puts the attacker into a position, where he can send byte-for-byte identical requests from his tool of choice.
That said, if I’m reading your question correctly, this isn’t what you want to avoid: What you really don’t want to happen is, that your API is consumed (regularly) without involving your JS client. Here are some ideas on how to if not enforce, then at least encourage your client’s use:
I believe, your API has some kind of authentication field (eg hash calculated on the client). If not, see this SO question. Make sure you use the salt (or even the API key) passed to your JS client on a session basis (aot hardcoded). This way, unauthorized consumers of your API are forced to work more.
When loading a JS client, remember some HTTP headers (which the user agent thinks about) and IP addresses, then request re-authentication if they change, using blacklists for the usual suspects. This forces the attacker to do his homework even more thoroughly.
On the server side, remember the last few API calls, and before allowing any other API calls, check if the business logic allows for new ones now: This denies the attacker’s ability to centralize his many sessions into a single session with your server: In combination with other actions, this will make the perpetrators of violence easily detected.
I may not say it with the necessary clarity: I consider it impossible to make it impossible for a principal to use your service, but you can make it so difficult, it may not be worth the hassle.
This is useful info, but what if i want to create multiple auth from my backend api to other api application like separate server, to simplify my question i want back-end aka node.js to send fetch request to back-end-server which I have, for some reason this is needed, but I want to secure api calls, because they can access sensitive data, and I can’t use sessions or jwt because I can’t actually store them in the browser.
You have to implement some kind of authentication system. One good way to handle this is to define some expected header variables. For example, you can have an auth/login API call that returns a session token. Subsequent calls to your API will expect the session token to be set in an HTTP header variable with a specific name such as ‘your-api-token’.
Alternatively, many systems generate expected access tokens or keys (like youtube, facebook or twitter) using some kind of api account system. In such cases, your client must store it in some way on the client.
Then it’s just a matter of adding checks for sessions into your REST framework and throwing exceptions. If possible, the status code (be quiet) will be error 401.
Your js + html application (client) running in the browser CAN be set up to exclude unauthorized direct calls to the API as follows:
Step one: Set up an API to request authentication. The client must first authenticate itself via a server (or some other security server) eg asking a human user to provide the correct password.
Prior to authentication, calls to the API are not accepted.
During authentication, a “token” is returned.
After authentication, only API calls with “token” authentication will be accepted.
Of course at this stage only authorized users with the password can access the API, although if they are programmers debugging the app they can access it directly for testing purposes.
Second step: Now set up the additional security API, which will be called in no time after the js+html client application is initially requested from the server. This “callback” will notify the server that the client downloaded successfully. Limit your REST API calls to work only if the client was requested recently and was successful.
Now to use your API they have to download the client first and actually run it in the browser. Only after successfully receiving the callback, and then the user entry in a short time, the API will receive the call.
So you don’t have to worry that this might be an unauthorized user without credentials.
(The title of the question, ‘How do I secure a REST API call’, and from most of what you’ve said, that’s your primary concern, and not a literal question of HOW your API is called, but BY WHOM, correct?)