How to protect REST API calls?

Question

I am developing a calming web application using some popular web structures on the backend, say (rails, sinatra, flask, express.js). Ideally, I want to develop the client side with Backbone.js. How do I allow only javascript client side interactions with these API calls? I do not want these API calls to be publicly accessible and called using curl or simply by entering a link in a browser.

Answer 1

As a first principle, if your API is used by your JS client, you should assume that it is publicly available: a simple JS debugger puts the attacker in a position where he can send byte bytes the same request from the tool of his choice.

However, if I read your question correctly, this is not something you want to avoid: what you really don't want is that your API is consumed (on a regular basis) without your JS client participating. Here are some ideas on how not to apply, and then encourage the use of your client:

• I am sure your API has some kind of authentication field (e.g. Hash computed on the client). If not, see This SO Question . Make sure you use the salt (or even the API key) that is provided to your session- based JS client (aot hardcoded). Thus, the unauthorized consumer of your API is forced to work much more.

• When loading the JS client, remember some HTTP headers (the user agent comes to mind) and the IP address and ask for re-authentication if they change using blacklists for common suspects. This forces the attacker to do their homework more carefully.

• On the server side, remember the last few API calls, and before allowing another, check if the business logic allows a new one: now it denies the attacker's ability to concentrate many of his sessions on one session with your server: in combination with other measures, this will make an attacker easily detectable.

Perhaps I did not say this with the necessary clarity: I believe that it is impossible to make it completely impossible for an attacker to use your services, but you can do it so difficult, maybe it is not worth the hassle.

Answer 2

You must implement some authentication system. One good way to handle this is to define some expected header variables. For example, you might have an auth / login API call that returns a session token. Subsequent calls to your API expect the session token to be set in the HTTP header variable with a specific name, such as your-api-token.

Alternatively, many systems create access tokens or keys that are expected (e.g. YouTube, Facebook or Twitter) using some kind of api account system. In these cases, your client will need to somehow store them in the client.

Then it's just a matter of adding validation for the session to your REST structure and throwing an exception. If at all possible, the status code (to be calm) would be error 401.

Answer 3

There is an open standard, which is now called "JSON Web Token",

see https://jwt.io/ and https://en.wikipedia.org/wiki/JSON_Web_Token

JSON Web Token (JWT) is an open JSON standard (RFC 7519) for creating tokens that claim a certain number of claims. For example, a server can generate a token that claims to be “registered as an administrator” and provide it to the client. The client can then use this token to prove that they are logged in as admin. Signs are signed by the server, so the server can verify that the token is legal. The same tokens are designed for compactness, reliability of URLs and use especially in the context of single sign-on to a web browser (SSO). JWT applications can usually be used to transfer the identity of authenticated users between an identity provider and a service provider or any other type of claim in accordance with the requirements of business processes. [1] [2] Tokens can also be authenticated and encrypted. [3] [4]

Answer 4

Excuse me @MarkAmery and Eugene, but this is not true.

Your js + html (client) application running in the browser can be configured to exclude unauthorized direct API calls, as shown below:

• First step: configure the API for authentication. The client must first authenticate through the server (or some other security server), for example, ask the person to provide the correct password.

Prior to authentication, API calls 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 who have a password can access the API, although if they program debugging the application, they can access it directly for testing purposes.

2. Second step: Now configure an additional security API, which should be called within a short period of time after the js + html client application was originally requested from the server. This “callback” tells the server that the client was loaded successfully. Restrict REST API calls to work only if the client has been requested recently and successfully.

Now, in order to use your API, they must first download the client and actually run it in the browser. Only after successfully receiving the callback and then entering the user for a short period of time, the API will receive calls.

This way, you don’t have to worry about being an unauthorized user without credentials.

(Question title: “How can I protect REST API calls,” and from most of what you say, this is your main problem, not the literal question of how you call your API, but rather WH WHOM, right?)