If I really need to use these methods, how do i make sure they are secure?

Edit: Is there a link or source where I can see how to make sure that 'PUT' and 'DELETE' methods are not able to delete or update resource, but services and servlets are still able to use PUT and DELETE.

Following services are using PUT and DELETE HTTP methods








So, clearly there has to be a way of making sure that PUT and DELETE can be used without putting resource files to harm like HTML, CSS, JS, or images.

  • 2
    I have already edited the question to explain why this is an original question, so why is this still marked as 'Duplicate'? Commented Jul 10, 2013 at 8:28

4 Answers 4


PUT and DELETE are not intrinsically insecure, they are used without problems at many REST services for example.

In my practice the main problem related to these HTTP verbs (apart from the common authentication and authorization problems) was that the server operators weren't aware of their existence introducing the possibility of HTTP Verb Tampering. In summary this means that access control was implemented based on a HTTP verb blacklist but some lesser known verbs were missing from this list allowing access control bypass.

I'd like to note that many web servers implement their own custom (sometimes undocumented) HTTP verbs, so this kind of "Verb-Based Access Control" doesn't seem like a very good idea anyway.

A Note on XSS (Edit 2023.11.17.)

In many cases applications use a particular interface by sending POST requests to it. If the interface is vulnerable to reflected XSS and it also accepts parameters in GET requests exploitation may become easier: if the interface only accepted POST, an attacker would need to direct the victim to a site controlled by him, so a crafted POST request to the real target can be triggered. On the other hand when GET is processed the same way as POST, the attacker only has to convince the victim to follow a link pointing to the (trusted) domain of the vulnerable target application.

Many current frameworks require you to explicitly specify what verb(s) a particular server-side method accepts (with annotations like @GET or @POST). It seems like a good idea to keep the set of accepted verbs minimal.


HTTP methods have little to do with security in and of themselves. A method like DELETE /users/1 could easily also be implemented as POST /users/1/delete or even GET /users/1/delete (GETs should never have side effects, but that doesn't stop some developers from doing so anyway).

You should therefore treat them similarly to any other HTTP method. GETs should not change server state, so typically you would only need to verify that the client has read access to the requested resource. PUTs should be used to update a resource wholly in-place (although they are often also used similarly to the PATCH verb), and so you should ensure that the client has the privileges to do this. Likewise, DELETE should be sent in order to request that a resource be deleted. So you would want to ensure a user has permission to do so.

In short: treat the verbs as descriptors of the type of action the user wishes to perform. Authenticate and authorize them to perform these actions as is required by the security parameters of your particular application.

  • 1
    "or even GET /users/1/delete." be careful with GET which is supposed to not have side effects.
    – curiousguy
    Commented Jul 9, 2013 at 6:23
  • @Stephen thanks for your comment. Do you have a link where someone has used PUT and DELETE for their services or servlets but still protected the resources Commented Jul 9, 2013 at 6:39
  • @curiousguy I'll clarify that. Commented Jul 9, 2013 at 14:54
  • @curiousguy That's not correct. It can have side effects. It must be idemopotent, which is not the same thing. If you configure your web server to accept a GET request to delete something that's fine as long as that delete can be called many times without doing anything the first request didn't do.
    – Jazzepi
    Commented Nov 15, 2017 at 20:48
  • @Jazzepi What kinds of side effects are allowed for GET?
    – curiousguy
    Commented Nov 17, 2017 at 2:16

From the OWASP testing guide:

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

  • PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files
    (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository

That said there are actually two things you need to take care of.

  • If you want to allow these users to make new content make sure that you only allow it for authenticated users you trust. These users should be trusted to the extent that you would allow them to have an FTP account.
  • If you would allow them to alter existing content, make sure you restrict it in such a way that they indeed can only overwrite certain existing resources and nothing else.

Also make sure that you are using SSL/TLS.

  • better still, an SFTP account. Commented Jul 9, 2013 at 6:03
  • 1
    FTP is the protocol, the S is just the encapsulation Commented Jul 9, 2013 at 6:10
  • 3
    @LucasKauffman -1; SFTP is a part of SSHv2.
    – curiousguy
    Commented Jul 9, 2013 at 6:25
  • 2
    @curiousguy - yup. FTPS is FTP over SSL. SFTP is not FTP over SSH (which is another protocol), but a new file transfer protocol that's part of SSH. To quote wikipedia "SFTP [SSH File Transfer Protocol also Secure File Transfer Protocol] is not FTP run over SSH, but rather a new protocol designed from the ground up by the IETF SECSH working group."
    – dr jimbob
    Commented Jul 9, 2013 at 6:38
  • 2
    Let's all agree that we need to a security layer. I did not intend to promote plain FTP or HTTP. Please don't kill me :( Commented Jul 9, 2013 at 7:20

for the records: RFC 2616 Hypertext Transfer Protocol HTTP/1.1 / Method-Section

a REQUEST is a request from a client to the server and dont say much about what the server will be doing with that request; possible methods dont have to be implemented on server-level.

so if you go to myserver.com and ask for "DELETE /blah" myserver.com might simply say: "thanx, sir, and have a nice day".

9.6 PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI.


The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully

Not the answer you're looking for? Browse other questions tagged .