Question

I've been trying to follow good RESTful APIs practices when designing them. One of them which happens to be very simple and common keeps getting hard to follow:

  • Use GET http verb to retrieve resources

Why? Consider you have a URI to get account information like this:

Where AXY_883772 is an account id in a bank system. Security auditing will raise a warning stating that:

  1. Account ID will appear on HTTP ACCESS LOGS
  2. Account ID might get cached on browser's history (even though is unlikely to use a browser regularly to access a RESTful API)

And they end up by "recommending" that POST verb should be used instead.

So, my question is:

What can we do about it? Just follow security recommendations and avoid using GET most of the times? Use some kind of special APACHE/IIS/NGINX access log configuration to avoid logging access to certain URLs?

Was it helpful?

Solution

If you have sensitive information in your urls, and you are logging urls you are logging sensitive information.

So there's two obvious solutions:

  • Don't log the url
  • Use a different url that doesn't contain the sensitive information

The last one could be implemented by using some (different) id that your server maps back to the normal id.

If neither of those solutions are an option for you, then you cannot use GET and therefore it's not good RESTful design.

I realize all these things are probably already obvious to you; But it's the most accurate answer I could give.

It's worth nothing that this doesn't just apply to GET, it would actually also be the case for PUT, DELETE and often POST.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top