0

I am working on an enterprise web app. Our app would be deployed to production in https only. We are writing REST APIs that would be consumed by our html 5 client only (not for others)

My team has taken decision to use POST for all rest verbs, because GET, PUT, DELETE exposes id in the url.

What my team thinks is that, having any type of data exposed in the url is not a good idea, even if id is not directly the database id.

Everybody seems to be agreed to use POST http method for GET, PUT, DELETE and pass http_method as parameter and using the parameter decide what operation to do.

This is the only difference that we are planning to do for REST APIs. What do you think?

Anil
  • 375
  • 3
  • 13
  • 1
    Your API is going to be secure and authenticated in some way. Using the proper verbs is the right way to go. Passing an ID doesn't expose anything more than a number. Go for it. – Chase Florell Sep 04 '12 at 14:29
  • @ChaseFlorell Passing ID does expose some data. It's not good for security reaons right? – Anil Sep 04 '12 at 14:36
  • The only way you're going to expose some data is by exposing the data. IE: your service has to send the data. If it's secure with authentication and knows to only send data to authenticated clients, then you're not exposing data by passing an ID. – Chase Florell Sep 04 '12 at 14:42
  • @ChaseFlorell of course you can expose some data with Id. e.g. the algorithm of numbering, approximated amount of entities in your database, it also can make application vurnelable to some sort of session hijacking. you can think and eliminate all those vulnerabilities but hiding id is just simpler – piotrek Sep 04 '12 at 15:32
  • 1
    @piotrek Use GUIDs if you are worried about people inferring information from your ids. And REST APIs don't have sessions so they can't be hijacked. – Darrel Miller Sep 04 '12 at 17:20

3 Answers3

4

By avoiding the use of GET you loose the ability to use caching. Hiding the id of the resource in the body will most likely cause you to violate the "identification of resources" constraint. Which will make linking/hypermedia far more difficult.

I would assert that it will be almost impossible to get the benefits of a RESTful system if you limit yourself to POST. Having said that, considering you are only targeting HTML5 clients you probably don't need most of the REST benefits. Doing Json-RPC is probably more than adequate for your needs.

However, I still think throwing away GET for a false sense of security is a bad idea. The body of your posts are just as easy to access by some intermediary as an id in the URI.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • With https, the body of posts is not easy to access. But with gets the url has the ids and that is not secure. – Anil Sep 04 '12 at 14:41
  • 1
    As I said in my other comment, exposing the ID isn't exposing any data. As long as your service is smart enough to only pass data to authenticated clients. – Chase Florell Sep 04 '12 at 14:44
  • @Anil Using HTTPS the URL is encrypted also. http://stackoverflow.com/questions/499591/are-https-urls-encrypted?lq=1 – Darrel Miller Sep 04 '12 at 15:00
  • 1
    @Darrel It is available in browser history that's a security concern. – Anil Sep 04 '12 at 16:51
  • 2
    @Anil The web is founded on the notion of identification of resources via URLs. If you believe that exposing those identifiers is a security concern then I maybe the web is not the right place for your data. Certainly REST is not the appropriate style for your API. – Darrel Miller Sep 04 '12 at 17:17
1

You should use HTTP as it was intended so you can get the full benefits of the stack. The different verbs have different semantics for a reason.

You can feel like POST is more secure than GET all you want, but it's a false premise.

Who are you securing this data from? Man in the middle? That's what HTTPS solves.

Are you securing it from your end users? The ones who can download your entire application and study the source code at their leisure whenever they want? Or view the source of a page with a right click and see your payloads laid out in all their glory? Or simply turn the browser debugger on and watch all of your traffic? You're trying to secure it from those people?

POST doesn't hide anything from anybody.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203
0

You should probably have a look at this post as it pretty much explains what https does for you. So the question would be: who do you want to protect the URL from? It might be in the browser history or visible to someone standing behind the user, but not to anyone listening on the line.

Community
  • 1
  • 1
Dirk
  • 1,893
  • 1
  • 19
  • 26
  • It is available in browser history that's a security concern. – Anil Sep 04 '12 at 16:16
  • In this case, REST, which relies on identifying resources by URLs, is not the right paradigm for you. You might call it REST for whatever reason, but it certainly is not. – Dirk Sep 04 '12 at 17:47