How to avoid misuse of a REST API?


I'm developing an application that is made up of three parts:

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

Most client requests to the API must be authenticated through a token that is obtained through the OAuth V2 protocol, but some requests will be opened, ie, they will not require authentication.

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

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

asked by anonymous 06.01.2015 / 12:05

1 answer


In your question does not reference whether your API is in RESTful or SOAP but how did you put a "REST" TAG calculation that is then RESTful. However what I'm going to mention makes sense to both.

OAUTH is actually for authorization as soon as it is delivered a TOKEN is supposed to access within the policy defined for the API. But you are authorized to use it. Therefore requests are only open to whom your system will deliver a TOKEN.

Regarding ENDPOINT's and taking into account that you will create a usage documentation for your API, it is exposed and there are several reasons ... but essentially because it is pure HTTP protocol and already now because it is the basis of the whole concept of an API.

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

The creation of 'user / user (in my language)' specific to unauthorized requests contributed nothing to the security of your API.

Once again finding out about ENDPOINT is the least of your problems. You have already thought about those requests that will access a database and that by using or several attacks can block your service ... I think there is really a lot to think about.

In conclusion, a API is public and period. OAuth is clearly the way to authorize its use. For me, OAuth is pure delegation ... being authentication and access to resources another situation. In the latter case OAuth has a solution so I advise you to analyze what in OAuth is called by SCOPES or permissions that can help to solve some points of your implementation. See also openID , it might work for you.

06.01.2015 / 13:40