Access-Control-Allow-Methods

When a browser needs to confirm which HTTP methods a server permits for cross-origin access, the Access-Control-Allow-Methods response header provides the answer. Servers return this header as part of a CORS preflight response.

Table of Contents

Usage

Before sending a cross-origin request with a non-simple method, the browser issues a preflight OPTIONS request. The Access-Control-Request-Method header in the preflight indicates which method the client plans to use. The server replies with Access-Control-Allow-Methods to confirm which methods are accepted for the target resource.

Simple methods (GET, HEAD, and POST) are always permitted by the CORS protocol and do not strictly require listing here. Listing them explicitly is common practice and makes server policy visible at a glance.

Multiple methods appear as a comma-separated list.

Directives

Method name list

A comma-separated set of HTTP method names the server accepts for cross-origin access.

Access-Control-Allow-Methods: GET, POST, PUT, DELETE

* (wildcard)

The asterisk acts as a wildcard for requests without credentials, permitting any method.

Access-Control-Allow-Methods: *

Note

For credentialed requests the wildcard * is treated as a literal string, not as a wildcard. Each allowed method must be listed explicitly when credentials are present.

Example

A preflight request asks whether the PUT method is allowed. The server confirms several methods.

Request

OPTIONS /api/resource/42 HTTP/1.1
Origin: https://app.example.re
Access-Control-Request-Method: PUT

Response

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.re
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 7200

A more restrictive server permits only GET and POST.

Access-Control-Allow-Methods: GET, POST

Troubleshooting

Preflight failures related to HTTP methods block the actual cross-origin request before the server processes the intended operation.

  1. Console shows "Method PUT is not allowed by Access-Control-Allow-Methods in preflight response." The server did not include the requested method in the Access-Control-Allow-Methods value. Add the missing method to the preflight response. In nginx: add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, PATCH"; In Apache: Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, PATCH"

  2. Preflight response missing the header entirely. The OPTIONS handler exists but does not return Access-Control-Allow-Methods. Confirm that the preflight route sets this header alongside Access-Control-Allow-Origin and Access-Control-Allow-Headers. A missing method header causes the browser to reject any non-simple method.

  3. Wildcard * not working with credentialed requests. When Access-Control-Allow-Credentials is true, the wildcard is treated as the literal string * and matches no method. List each permitted method explicitly in credentialed configurations.

  4. Server returning 405 Method Not Allowed during preflight. The server has no route handling OPTIONS for the target URL, so the request hits a catch-all that rejects the method. Add an OPTIONS handler to the route. In Express: app.options('/api/resource', cors()). In Django, the django-cors-headers middleware handles OPTIONS automatically when installed. In nginx, add an if ($request_method = OPTIONS) block or use limit_except to permit OPTIONS on the location.

  5. Framework auto-handling OPTIONS but not including CORS headers. Some frameworks respond to OPTIONS with a 200 or 204 and a plain Allow header listing supported methods, but do not attach any CORS headers. The browser treats this as a failed preflight because Access-Control-Allow-Methods is absent. Configure CORS middleware to intercept OPTIONS requests before the framework's built-in handler. In Spring Boot, register a CorsFilter bean. In ASP.NET, call services.AddCors() with the correct policy before app.UseRouting().

See also

Last updated: April 4, 2026