I would say implementing the HTTP OPTIONS method, in itself, is not a significant security risk. Yes, it nicely enumerates which other methods are implemented by a server, but it is in the handling of those other methods that the potential for danger lies, not in the reporting that they are handled.
For example, the TRACE method can be a vector of attack. If you implement OPTIONS, and it includes TRACE in its response, a potential attacker can use OPTIONS to discover that TRACE is supported then decide to try and launch an attack on TRACE. However, if OPTIONS is not implemented, or it lies and says TRACE is not implemented, the attacker could still decide to try and mount an attack using TRACE. In fact, they are probably just as likely to not use the OPTIONS command at all and simply see if an attack on TRACE will work.
You should focus on making sure that potentially unsafe methods (such as TRACE) are disabled or suitably protected, ahead of worrying whether OPTIONS tells an attacker they exist.
The OSWAP GitHub page on Test HTTP Methods starts by listing the eight HTTP methods defined by RFC 2616 (HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT) but only mentions four that should be disabled (or sufficiently protected):
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.
DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
CONNECT: This method could allow a client to use the web server as a proxy.
TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page).
If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.
And while it highlights how the OPTIONS command can be used by a tester to determine potential vulnerabilities:
How to Test
Discover the Supported Methods
To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.
Execution of a test-script only highlights the TRACE method as risky:The same test can also be executed using nmap and the http-methods NSE script:C:Tools
map-6.40>nmap -p 443 --script http-methods localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-04 11:52 Romance Standard Time
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0094s latency).
PORT STATE SERVICE
443/tcp open https
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
Nmap done: 1 IP address (1 host up) scanned in 20.48 seconds
The rest of the OSWAP page discusses potential security problems (e.g. the potential of using TRACE to exfiltrate cookies tagged httpOnly into JavaScript), but does not talk of OPTIONS being a security concern.
