Many security scanners like nikto, nessus, nmap, and w3af sometimes show that certain HTTP Methods like HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, etc are vulnerable to attack.

What do these methods do and how can they be exploited?

I'm looking something more creative than common exploits like POST or GET injections (e.g., changed fields). It would help me to understand if your answer showed me a brief example of the normal usage of the header as compared to an exploit technique of a header.

  • Also, the question came up because on one of my servers. I got a warning that my TRACE method was vulnerable. Problem is, I don't know what trace does or how to exploit it. Oct 10, 2012 at 20:31
  • 1
    You seem to have some basic confusion about HTTP in general. HTTP methods are not headers. Perhaps reading the relevant part of the RFC is in order? Oct 10, 2012 at 20:33
  • The O'Reilly book on HTTP would be a good place to start. Mar 21, 2013 at 15:53
  • Only GET and POST can be called by most web browsers, whereas the others can be called by any other HTTP client. Technically, could not do an XSS attack against a PUT method in the browser, because browsers don't PUT. Nov 19, 2013 at 19:36

3 Answers 3


Some of these methods are typically dangerous to expose, and some are just extraneous in a production environment, which could be considered extra attack surface. Still, worth shutting those off too, since you probably wont need them:

  • HEAD, GET, POST, CONNECT - these are completely safe, at least as far as the HTTP Method itself. Of course, the request itself may have malicious parameters, but that is seperate from the Method... these are typically (note exception below) the only ones that should be enabled.
  • PUT, DELETE - as mentioned by @Justin, these methods were originally intended as file management operations.
    Some web servers still support these in their original format. That is, you can change or delete files from the server's file system, arbitrarily. Obviously, if these are enabled, it opens you to some dangerous attacks.
    File access permissions should be very strictly limited, if you absolutely MUST have these methods enabled. But you shouldn't, anyway - nowadays, there are simple scripts you can use (if this is a static website - if it's an actual application, just code it yourself) to support this feature if you need it.
    NOTE: One valid scenario to enable these methods (PUT and DELETE) is if you are developing a strictly RESTful API or service; however, in this case the method would be handled by your application code, and not the web server.

  • OPTIONS - this is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole.
    Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled.
    NOTE: Despite the above, OPTIONS method IS used for several legitimate purposes nowadays, for example some REST APIs require an OPTIONS request, CORS requires pre-flight requests, and so on. So there definitely are scenarios wherein OPTIONS should be enabled, but the default should still be "disabled unless required".

  • TRACE - this is the surprising one... Again, a diagnostic method (as @Jeff mentioned), that returns in the response body, the entire HTTP Request. This includes the request body, but also the request headers, including e.g. cookies, authorization headers, and more.
    Not too surprising, this can be substantially misused, such as the classic Cross-Site Tracing (XST) attack, wherein an XSS vector can be utilized to retrieve HttpOnly cookies, authorization headers, and such. This should definitely be disabled.

  • One other set of Methods bears mentioning: ALL OTHERS. For some webservers, in order to enable/disable/restrict certain HTTP Methods, you explicitly set them one way or another in the configuration file. However, if no default is set, it can be possible to "inject" additional methods, bypassing certain access controls that the web server may have implemented (poorly). See for example some more info on OWASP.

  • 11
    OPTIONS is heavily used nowadays for REST APIs Nov 19, 2013 at 19:34
  • 10
    OPTIONS is heavily used in new HTML5 security model Apr 1, 2014 at 8:31
  • @AviD You added a note after the options section, but you left this bit in " In reality, this is rarely used nowadays for legitimate purposes." This conflicts with the note you added
    – Kyeotic
    Oct 3, 2016 at 21:24
  • 1
    @AviD the CONNECT method can be used to exploit the Webserver as a proxy, so i wouln't call that completely safe, since that can be a serious misuse with consequences for the hoster.
    – Gewure
    Aug 2, 2017 at 11:04
  • 2
    @Gewure can you explain? Of course there can be additional vulnerabilities exploitable via a specific method, but that doesn't make the availability of the method an issue...?
    – AviD
    Aug 2, 2017 at 12:50

The primary warning about TRACE is that it is designed to pick apart the routing of an HTTP request similar to how traceroute is meant to pick apart the routing of a packet. The key difference is that the TRACE command involves operations on the backend and disclosure of what has been received. This could be an issue if your front-end provides API keys or the something similar to your backend.

Check out RFC 2616 for more info on TRACE as well as explanations about other headers.


Using the PUT method, you can upload any file on the server. This can be used to perform Cross Site Scripting (XSS). Today, I have performed this attack, so replying here with my experience. How you do this is explained below.

PUT /XSS.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.myblog.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
(Input your XSS script here) 

The server responds back with a 201 status code which says “file was created successfully”.

HTTP/1.1 201 Created
Date: Mon, 05 May 2014 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

Now we can try to access this uploaded XSS.html file in browser. As soon as you access this page, you get an XSS pop-up.

Likewise, this can be further exploited to perform Command Injection as well, though I haven't tried this yet. If application uses XML, then XML External Entity attack can also be performed. Havent done this too yet. Directory Traversal attack may be possible, too.

  • Is this answer valid for RESTful services as well?
    – Mubin
    Jan 22, 2019 at 17:53
  • 6
    "Using the PUT method" on a poorly configured server. That' s not a problem with http method, that's a problem with the guy who (mis)configured the server to accept file uploads from anyone. I won't ask if that server accepts to execute scripts uploaded from unauthenticated users (horror face) Jul 5, 2019 at 16:14
  • 1
    This talk drives me nuts. If you have unsecured endpoints running then it's not the verb that's at fault.
    – bmiller
    Feb 14, 2021 at 14:02
  • Used burp to put file. I got "HTTP/1.1 405 Method Not Allowed". Would have been great if it had worked, but upvoted anyway.
    – DimiDak
    May 1, 2021 at 0:31

You must log in to answer this question.

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