How to avoid misuse of a REST API?

Asked

Viewed 1,467 times

4

I am developing an application that is composed of three parts:

  • Backend (BD + API), developed with Symfony 2 + Doctrine 2
  • IOS client
  • Android client

Most client requests for the API must be authenticated via a token obtained through the Oauth V2 protocol, but some requests will be opened, meaning they will not need authentication.

My fear is that it will be discovered not only the endpoint of the application, but also the paths that do not require authentication. What are the best practices to prevent misuse of my API?

One solution I thought was to create a specific user for unauthenticated requests whose only role is the one of ROLE_API, but would like to know other solutions.

1 answer

3


In your question you do not refer to whether your API is in Restful or SOAP but how you put a "REST" TAG I calculate that it is then Restful. However, what I am going to say makes sense to both.

OAUTH is actually for authorization, so it is delivered a TOKEN is supposed to access within the policy set for the API. But you are authorized to use. Therefore requests are only opened to those who your system delivers a TOKEN.

As to the ENDPOINT’s and taking into account that it will create a usage documentation for your API, this is exposed and several are the reasons... but essentially because it is pure HTTP Protocol and by the way it is the basis of the whole concept of an API.

When writing these lines comes to the idea limitations that can put as for example in the firewall of your server accept requets only for a certain IP. Or even use SSL to exclude those who do not present signed certificates... the universe of options is vast.

Creating specific 'user/user(in my language)' for unauthorized requests does nothing to contribute to the security of your API.

Once again the discovery of a ENDPOINT is the least of your problems. Have you thought about those requests that will access a database and that by use or multiple attacks can block your service... I think you really have a lot to think about.

In conclusion, a API is published and point. The OAuth is clearly the way to take to authorize its use. For me the OAuth is pure delegation... authentication and access to resources is another situation. In the last case the OAuth has solution so I advise the analysis of what in OAuth is termed by SCOPES or permissions that can help resolve some points of your implementation. See also openID, may be of use to your case.

  • Actually the API is REST. The protected resource part I actually use the Oauth protocol. The calls I refer to are the open ones (for example, for user creation), in which I do not yet have a user and password?

  • As I said... authorization already has...now only missing authentication. As for the authorization that uses this depends on the desired implementation. How is the information going? If it is without ssl you have to take into account some things. At this moment I also find myself developing for an API and in the interface where it is possible to define the access by OAUTH also define the resources that this application can access or not. concluding... yes is an excellent solution. ever thought also how builds your ID’s and keys? is also important.

  • I edited my reply to remind you of the SCOPES in Oauth because in my initial reply I forgot to mention and that in your case it will all make sense.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.