HTTP Methods Auditor to Check Enabled Methods on a Server

A web server understands more request types than the GET and POST most visitors ever trigger, and each additional method it answers widens what an attacker, or a careless script, can do with your site. The HTTP Methods Auditor checks which HTTP methods are enabled on a server, so you can identify the ones that serve no purpose for your application yet carry security risk. It is a checking tool for site owners, administrators, and testers carrying out a routine review of a server they are responsible for.

The Methods and What Each One Implies

HTTP methods describe the action a request asks for. GET retrieves a resource and POST submits data, and between them they power ordinary browsing and forms. PUT and DELETE, by contrast, ask the server to create, replace, or remove a resource. On a typical brochure site or blog, nothing legitimate needs them through the public web server, so a response to those methods can mean uploads or deletions are possible in ways the owner never intended. PATCH applies partial changes and raises similar questions when nothing in the application uses it.

Other methods appear in audits for different reasons. TRACE echoes a request back and has a long history in cross site tracing discussions, which is why many hardening guides recommend disabling it. OPTIONS reports which methods the server claims to allow, making it useful during an audit even though it is generally less dangerous in itself. CONNECT relates to proxy behaviour and should not be casually available on an ordinary web server. The MDN reference on HTTP methods describes each verb formally if you want the precise definitions.

Features of the HTTP Methods Auditor

• Method by method probing: the target is tested with the standard request methods so you can see which ones the server answers.
• Risk focused results: change oriented methods such as PUT, DELETE, and PATCH stand out clearly from everyday GET and POST traffic.
• Path level checking: run the audit against the homepage or a specific application path, since behaviour can differ by location.
• Repeatable baseline: the same check can be rerun after configuration changes to document the new state of the server.
• Part of a wider review: findings pair naturally with header and port checks for a complete outside view of a server.

How to Use the HTTP Methods Auditor

1. Enter the address of the server or site you own, or are explicitly authorised to test.
2. Click Start Audit and wait while the tool probes the target with different request methods.
3. Review the methods the server responded to, noting any beyond the ones your site actually needs.
4. Repeat the check for important application paths if relevant, since behaviour can differ by location.
5. Discuss disabling unnecessary methods with your host or in your server configuration, then retest to confirm the change.
6. Keep a dated note of the results as part of your security records.

What an Audit Can and Cannot Prove

A response to a method is a signal, not a verdict. Some servers answer a request politely while an application layer still refuses the action, and some frameworks route methods differently depending on the path, the sign in state, or the content type. Treat an unexpected PUT or DELETE response as a reason to investigate with your configuration and, where appropriate, a controlled test on a staging copy, rather than as proof that files can actually be removed.

Scope matters as well. Audit only systems you own or have explicit permission to test, since probing other people's servers can breach their policies or the law regardless of your intentions. Pair the findings with a look at response headers through our HTTP headers parser and a broader review using the security headers auditor, because methods are one part of a server's posture, not the whole of it. Checking which network ports answer with the open port checker completes the outside view.

Consider the owner of a small brochure website, a handful of pages with a contact form, who runs this audit during a routine review. GET and HEAD answer as expected, POST responds because the form needs it, and OPTIONS politely lists the server's capabilities. The surprise is that PUT and DELETE also receive responses rather than refusals. Nothing on the site uploads or removes files through those methods, so the finding does not prove the site is open to modification; it means the server was left with defaults the owner never chose, which is exactly what an audit exists to surface. The productive follow up is methodical: raise the report with the hosting provider, test on a staging copy whether refusing those methods changes anything for visitors or the form, restrict them only after that check, and run the audit again to document the new state.

Auditing Tips, Limits and Mistakes to Avoid

The guiding principle is least functionality: a public server should answer only the methods the application genuinely uses. For many sites that means GET, POST, and HEAD, with everything else rejected at the web server or framework level. Where an API legitimately uses PUT, PATCH, or DELETE, those methods belong behind authentication and authorisation checks inside the application, ideally limited to the specific routes that need them.

Make changes carefully. Disabling a method your checkout, editor, or integration silently relies on will break real work, so test on staging first and involve anyone who maintains the site's integrations. After a change, repeat the audit and exercise the site's forms, uploads, and sign in as a normal visitor would. When you report findings, record the address tested, the date, and the exact response for each method rather than summarising a server as simply safe or unsafe; careful wording distinguishes an open door from a door that merely rattles when pushed, and it protects both the site owner and your own credibility.

Frequently Asked Questions About HTTP Methods

Which HTTP methods are usually considered risky?

PUT, DELETE, and PATCH deserve scrutiny on servers that do not deliberately use them, because they request changes to resources. TRACE is also commonly disabled following longstanding hardening advice. The real question is always whether your own application needs a method, not the method in isolation.

Does an enabled method mean my site has been compromised?

No. It means the server responds to that type of request, which may be a harmless default or a fully protected application route. It is a prompt to verify how the method behaves on your system, not evidence that anyone has abused it.

How often should I audit HTTP methods?

Repeat the check after server migrations, framework upgrades, hosting changes, or major application releases, since defaults can return during those events. Adding it to a periodic security review, alongside header and port checks, keeps the picture current.

Should GET and POST ever be disabled?

Almost never on a public website. GET serves pages and POST submits forms, logins, and uploads, so disabling either breaks ordinary use. The audit's value lies in the methods beyond those two, which many sites answer purely by default.

Why does OPTIONS respond even on careful servers?

Because OPTIONS is how clients ask a server what it allows, and many frameworks answer it automatically. Its response is useful information during an audit, and on its own it is not considered a serious risk.

Can I audit a site I do not own?

Only with the owner's explicit permission. Probing a server's methods is an active test, and running it against systems you do not control can violate their policies or the law where you live. Keep audits to your own infrastructure and authorised engagements.

Answer Only What You Use

The HTTP Methods Auditor turns a quiet server default into visible, dated evidence you can act on. Run it as part of a regular review, investigate anything your application does not need, and restrict methods carefully on staging before production. A server that answers only what it uses is a smaller target, and a calmer thing to own.