137

All over the internet, I see the following advice:

A GET should never change data on the server- use a POST request for that

What is the basis for this idea?

If I make a php service which inserts data in the database, and pass it parameters in the GET query string, why is that wrong? (I am using prepared statements, to take care of SQL Injection). Is a POST request in some way more secure?

Or is there some historic reason for this? If so how valid is this advice today?

7

6 Answers 6

212

This is not advice.

A GET is defined in this way in the HTTP protocol. It is supposed to be idempotent and safe.

As for why - a GET can be cached and in a browser, refreshed. Over and over and over.

This means that if you make the same GET again, you will insert into your database again.

Consider what this may mean if the GET becomes a link and it gets crawled by a search engine. You will have your database full of duplicate data.

I also suggest reading URIs, Addressability, and the use of HTTP GET and POST.


There is also a problem with link prefetching in some browsers - they will make a call to pre-fetch links, even if not indicated so by the page author.

If, say, your log out is behind a "GET", linked from every page on your site, people can get logged out just due to this behaviour.

11
  • 37
    Many, many, many tools, utilities, web crawlers and other thingamajiggies assume that GET will never be a destructive action (rightly so, since it's specified this way). If you now break your application by breaking that specification, you'll get to keep both parts of your application. Mar 1, 2013 at 12:21
  • 8
    @NimChimpsky: it does get changed by a GET. That advice is simply wrong. Safe means that the user cannot be held accountable for side-effects, not that there can't be side-effects. Otherwise you couldn't have log files for your server, which would be absurd! This is spelled out quite clearly in section 9.1.1 of RFC2616. Mar 1, 2013 at 14:35
  • 8
    @JörgWMittag: I wouldn't say "simply wrong", I'd say "phrased inperfectly". A GET should not have a change as it's goal. Of course you're allowed to count, log and observe a GET request. But it should not modify your actual business data. Mar 1, 2013 at 14:54
  • 25
    @NimChimpsky A GET shouldn't change the resource requested by the GET, but that doesn't mean 'nothing on the server should change'. Of course things like logs, counters, and other server state may change during any request.
    – Eric King
    Mar 1, 2013 at 14:55
  • 10
    Quite some years ago, Google released a browser add-on (iirc) that would pre-fetch pages via links. This also happened on some control panels that were designed poorly - the URLs would cause a record or something to be written or even deleted on the server (think post?action=delete). This caused actions to be executed without the user knowing it. Google discontinued that addon for that reason, iirc, even if it was the webapp manufacturer's fault for using GETs to change state.
    – cthulhu
    Mar 1, 2013 at 15:41
27

Each HTTP verb has it's own responsibility. For example GET, as defined by RFC

means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

POST, on the other hand, means insert or more formally

The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line

Reasons for keeping it this way:

  • It's very simple and works on the global Internet scale since 1991
  • Stick to the single responsibility principle
  • Other parties use GET to act as means of information retrieval and data mining
  • GET is assumed to be a safe operation that never modifies the state of the resource
  • Security considerations, GET is effectively a read, whereas POST is effectively a write
  • GET is cached by browsers, nodes in the network, Internet Service Providers
  • Unless the content changes, GET to the same URL must return same results to all the users or else you you won't have any trust what so ever in the returned result

For completeness and just to enforce correct usage (source):

  • GET parameters are passed as part of the URL, which is of small and limited length of 256 chars by default, with some servers supporting 4000+ chars. If you want to insert a long record, there is no legitimate way to pass this data in
  • W̶h̶e̶n̶ ̶u̶s̶i̶n̶g̶ ̶s̶e̶c̶u̶r̶e̶ ̶c̶o̶n̶n̶e̶c̶t̶i̶o̶n̶,̶ ̶s̶u̶c̶h̶ ̶a̶s̶ ̶T̶L̶S̶,̶ ̶U̶R̶L̶ ̶i̶s̶ ̶n̶o̶t̶ ̶g̶e̶t̶t̶i̶n̶g̶ ̶e̶n̶c̶r̶y̶p̶t̶e̶d̶,̶ ̶h̶e̶n̶c̶e̶ ̶a̶l̶l̶ ̶t̶h̶e̶ ̶p̶a̶r̶a̶m̶e̶t̶e̶r̶s̶ ̶o̶f̶ ̶̶G̶E̶T̶̶ ̶a̶r̶e̶ ̶t̶r̶a̶n̶s̶f̶e̶r̶r̶e̶d̶ ̶p̶l̶a̶i̶n̶ ̶t̶e̶x̶t̶. URL is actuall encrypted with TLS, so TLS is fine.
  • Inserting binary data or non-ASCII characters using GET is impractical
  • GET is re-executed if a user presses a Back button in a browser
  • Some older crawlers may not index URLs with a ? sign inside
3
  • 1
    Are you sure that the URL is unencrypted over TLS? I was under the impression that the SSL/TLS handshakes occur prior to the HTTP headers being transferred. This is the reason why virtual hosting HTTPS sites over a single IP address is difficult. Am I mistaken?
    – Brandon
    Mar 2, 2013 at 17:17
  • That's right, I fixed it
    – oleksii
    Mar 2, 2013 at 20:14
  • 2
    @Brandon Modern browsers send the host domain in the clear as part of the TLS handshake (known as server name indication), to allow hosting more than one domain per IP address. The path/query part of the url is protected by TLS. There is no difference between GET and other HTTP verbs in that regard. Mar 2, 2013 at 21:41
10

EDIT: Before, I said POST helps protect you against CSRF but this is wrong. I did not think this through correctly. You must require a session-scope unique hidden token in all your requests to change data to protect against CSRF.

In the early days of the internet there were browser accelerators. These programs would start clicking links on a page to cache the content. Google Web Accelerator was one of these programs. This could wreak havoc on an application that makes changes when a link is clicked. I would make the assumption that there are still people using accelerator software.

Proxy servers and browsers will cache GET requests so when the user accesses the page again it may not send the request to your application so the user thinks they took an action, but they really didn't.

1
  • 1
    CSRF is equally possible with GET and POST. For example the attacker can include an auto-submitting form on their site to trigger a POST request. The standard approach to preventing CSRF is explicitly including a value unknown to the attacker in the request (unlike the implicitly includes cookie headers). Dec 28, 2015 at 17:53
9

If I make a php service which inserts data in the database, and pass it parameters in the GET query string, why is that wrong?

The simplest answer is "because that's not what GET means."

Using GET to pass data for an update is like writing a love letter and sending it in an envelope marked "SPECIAL OFFER - ACT NOW!" In both cases, you should not be surprised the recipient and/or intermediaries mishandle your message.

1
  • It is answers like this that make this site more valuable/entertaining from the rest.
    – killjoy
    Apr 29, 2020 at 5:22
5

For your CRUD operations in a database-centric application use the following schema:

Use HTTP GET for Read Operations (SQL SELECT)

Use HTTP PUT for Update Operations (SQL UPDATE)

Use HTTP POST for Create Operations (SQL INSERT)

Use HTTP DELETE for Delete Operations (SQL DELETE)

3
  • 4
    Put vs post is not as you state. Put is for when the client is modifying the resource at the exact given location. For a post the server ultimately decides the exact Uri to the resource.
    – Andy
    Mar 20, 2014 at 0:54
  • Isn't HTTP PUT more like a SQL DELETE and INSERT rather than UPDATE? Also SQL UPDATE can update many records at once, but HTTP PUT will update only one thing. Aug 31, 2018 at 1:39
  • PATCH is for UPDATE Jan 6, 2020 at 19:35
1

A GET should never change data on the server- use a POST request for that

That advice, and all of the answers here are wrong. Obviously I'm being overly dramatic, the other answers are excellent, but I believe the exact advice should be given as:

A GET should rarely change data on the server- use a POST request for that

To say "never" is too extreme, and although the other answers here accurately explain why you should "rarely" do it, there are some scenarios where it is perfectly reasonable to change data with a GET. An example is a one-time use email verification link. Typically these links contain a GUID that when accessed will have to change data. If correctly implemented subsequent identical GET requests will be ignored.

This is obviously an edge case, but certainly worth noting.

4
  • 3
    What if your mailclient decides to fetch the link without you clicking on it? For example because it wants to scan it for malware. The proper approach for unsubscribe links is to lead to a page where the user can click a button to unsubscribe (where the button click triggers a POST request). Dec 28, 2015 at 17:55
  • @CodesInChaos - excellent point! I agree with you. I have removed the unsubscribe example and have left the email verification as the sole example. There may be others besides email verification where a GET makes sense, but I can't think of any at the moment.
    – TTT
    Dec 28, 2015 at 18:31
  • The problem with GET having side effects applies equally to email confirmation. Now the client following the link would confirm an account somebody else created using your email, allowing them to impersonate you. Dec 28, 2015 at 18:35
  • @CodesInChaos - that one's a stretch. The impersonation you speak of would come from the same username or public personal name, not the same email address, and that can happen regardless of what email address they use (typically only the server knows the account holder's email address anyway). Besides, it would be pointless to create an account with someone else's email address. How could that help them? They could not control their own account.
    – TTT
    Dec 28, 2015 at 19:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.