Access-Control-Allow-Methods: permitted methods on preflight
Access-Control-Allow-Methods lists the methods a cross-origin client may use on this URL. It is only meaningful on the response to a preflight OPTIONS request.
At a glance
- Direction
- Response, and only on the preflight. Sending it on the real response has no effect.
- Defined in
- The Fetch standard (WHATWG)
- When absent
- The preflight fails for any method that needed one, and the real request is never sent.
- Value
- A comma separated list of methods, or the wildcard * for non-credentialed requests
- Never needs a preflight
- GET and HEAD, and POST when its content type is already safelisted
- Cached with
- Access-Control-Max-Age, which stores the whole preflight result
- Case
- Method names are case sensitive here, so write them in upper case.
In detail
A preflight happens when the browser is about to make a request that is not simple: a method such as PUT, PATCH or DELETE, a content type outside the safelisted set, or a custom header. The browser sends OPTIONS first, describing what it wants to do, and this header is the server's answer about which methods are acceptable.
Because it belongs to the preflight, adding it to your normal GET responses achieves nothing except noise in the headers. Equally, an OPTIONS handler that returns the header but is never reached, because a framework answers OPTIONS with 405 before your code runs, produces a failure that looks like a CORS misconfiguration when the real problem is routing.
The list must include the method the browser named in Access-Control-Request-Method, and matching is case sensitive. A server that lowercases everything before comparing, or that answers with patch instead of PATCH, fails the check for a reason that is invisible unless you read the preflight response byte for byte.
The wildcard is available for requests that carry no credentials. As soon as cookies or an Authorization header are involved it stops counting as a match, and the list has to name the methods explicitly, in the same way the allow origin header has to name the origin.
Examples
OPTIONS /api/items/7 HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PATCH
Access-Control-Request-Headers: content-type
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PATCH, DELETE
Access-Control-Allow-Headers: content-type
Access-Control-Max-Age: 600Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, HEAD, OPTIONSThings that catch people out
- Listing methods on the actual response instead of the preflight response does nothing at all. The browser only reads this header from the OPTIONS reply.
- A framework or gateway that answers OPTIONS itself, before your handler runs, produces a preflight with no CORS headers and an error message that blames the wrong layer.
- Method names are compared exactly. Sending them lowercase fails the check even though the rest of the response looks correct.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Access-Control-Request-Method: the preflight question
What the browser sends on a preflight, which methods trigger one, why the server must answer with an exact match, and how to reproduce a preflight by hand.
Access-Control-Allow-Headers: permitted request headers
Which request headers trigger a preflight, how to answer with the right allow list, and the one header a wildcard never covers.
Access-Control-Max-Age: caching the preflight result
How long a browser may reuse a preflight result, the caps Chrome and Firefox apply, what minus one means, and why a doubled request count is normal.
Access-Control-Allow-Origin: who may read this response
How the allow origin header is matched, why a wildcard fails with credentials, why it takes only one origin, and why Vary: Origin is mandatory when you echo.
Access-Control-Allow-Credentials: cookies across origins
What credentials mode means, the three wildcards it disables, what the client must also do, and why this header needs an exact origin in the response.
Access-Control-Expose-Headers: reading response headers
Which response headers page code can read cross-origin by default, how to expose more, and why a pagination or request id header appears empty without it.
Tools for this
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL