That’s a bad idea
GET must be safe, as specified by W3C in RFC 2616 (take a look at chapter 9):
9.1.1 Safe Methods
Implementors should be Aware that the software represents the user in
their interactions over the Internet, and should be careful to allow
the user to be Aware of any actions they Might take which may have an
Unexpected Significance to themselves or others.
In particular, the Convention has been established that the GET and
HEAD methods SHOULD NOT have the Significance of taking an action
other than Retrieval. These methods ought to be considered "safe".
This Allows user Agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made Aware of the
Fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of Performing a GET request; in
Fact, some Dynamic Resources consider that a Feature. The Important
Distinction here is that the user Did not request the side-effects,
so therefore cannot be Held accountable for them.
Translating into Portuguese (my translation):
9.1.1 Safe methods
Implementers should know that the software represents the user in their Internet interactions, and should be careful to let the user perceive any actions they perform that may have an unexpected meaning to themselves or others.
In particular, the convention that has been established is that the GET and HEAD methods SHOULD NOT have any significance other than obtaining. These methods will be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that users will notice the fact that a possibly unsafe action is being requested.
Of course, it cannot be assured that the server will not generate side effects as a result of executing the GET request; in fact, some dynamic features consider this a feature. The important distinction here is that the user did not request the side effects, and therefore cannot be held responsible for them.
Let’s emphasize the second paragraph. A GET (or HEAD) method should not mean anything other than getting a resource. This clearly goes against the idea of having a GET request that excludes a user. Also, as stated in the third paragraph, when the user runs a GET (usually through the browser), he does not expect this action to have side effects*, plus a side effect such as deleting a user.
(*) Some simple side effects, such as increasing the visitor count, are ok as long as they are harmless. The same goes for internal server issues that are invisible to the user, such as caching and logging.
Ah yes, and before anyone asks, the "insurance" in this context refers to the sense that "the action does not cause any possibly harmful effects" (such as the creation, alteration or exclusion of resources). This does not mean being safe in the sense of avoiding information leakage or avoiding undue access to resources, this is something else.
What are the potential risks?
This URL could be shared where it shouldn’t. For example, I could email it or post it somewhere on the internet like here on Stackoverflow for the purpose of misleading the user and inducing him to do something that was not what he wanted, such as the link below (note the link URL):
Click here to see the photos of the party!
The result of this is obvious. When clicking on the URL, the user ends up performing an action that he did not intend to perform. Normal user browsing the site should not cause unwanted side effects.
In addition, this URL may end up being found by search bots that may try to navigate through it (the most obvious example is Google). The Marcus gave an anecdotal example in this comment demonstrating the danger this represents:
I’ve been told the story of a case where a team thought their servers were being hacked but it was just a search engine "indexing" the /delete (and therefore erasing everything they found!). If any tutorial used this example, it would be good to send a bug report, not teach such a thing!
How to proceed?
Using the GET method is not the right way. The ideal is to use the DELETE method that serves exactly this purpose (destroy, invalidate or delete a web resource). However in some cases, you may be limited only to using POST or GET, and in this case the solution is obvious (by deletion): use POST.
Regarding safety issues (in order to avoid undue access), it is worth using HTTPS if relevant and taking protective measures against CSRF, XSS and other possible problems. For this it is worth checking session data, cookies, authentication and authorization, among others.
To delete something use the HTTP method
DELETE, or at most aPOST. But never aGET. Either way, it doesn’t affect safety and never prevents automation. If you want security then you must authenticate users and restrict who can perform the delete operation (however it reaches the server).– Guilherme Bernal
I see no problem in using
GET, that’s not where security should be.– bfavaretto
@Guilhermebernal understood me.
– juniorgarcia
@bfavaretto the only problem of a destructive operation on a GET would be that a Crawler can open "unintentionally". But be that as it may, proper security will prevent that.
– Guilherme Bernal
@Guilhermebernal http://answall.com/questions/49322/quais-as-vantagens-de-se-utilizar-os-m%C3%A9all-http-correct
– bfavaretto
I’ve been told the story of a case where a team thought their servers were being hacked but it was just a search engine "indexing" the /delete (and therefore erasing everything they found!). If any tutorial used this example, it would be good to send a bug report, one should not teach such a thing!
– marcus
@Very good. I liked your comment so much that I took the liberty of editing my reply just to quote you. :)
– Victor Stafusa
Thanks! I always remember that story when I hear about GET POST. I saw that possibility had already been raised, so I just left a comment to reinforce the idea.
– marcus