Access-Control-Allow-Methods

What Access-Control-Allow-Methods Does

Access-Control-Allow-Methods is the CORS response header that tells the browser which HTTP methods are permitted for a cross-origin request. It matters during preflight because the browser uses it to decide whether the actual request may proceed.

Because it is part of browser-enforced access control, the header is not a general server-side permission system. It is a declarative signal that must align with the application’s real method handling, otherwise the browser may allow an interaction the origin did not intend.

How It Works in the CORS Preflight Flow

When a browser sends a preflight OPTIONS request, it is asking whether a cross-origin request is safe to attempt with a specific method and set of headers. Access-Control-Allow-Methods answers the method part of that question, usually by listing verbs such as GET, POST, PUT or DELETE that the server is prepared to accept from that origin.

The browser compares the requested method with the allowed list before it sends the real request. If the method is absent, the request is blocked client side even if the endpoint exists and would otherwise accept it. That makes the header a gate on browser behaviour, not on all possible network clients.

Why Method Declarations Matter for Security

The header helps define the cross-origin attack surface of an API or web application. A permissive method list can expose state-changing operations to browsers that should not be able to reach them from another origin, especially when paired with other permissive CORS settings.

It also creates a common source of confusion: developers sometimes assume that listing a method in CORS is equivalent to authorising that method. It is not. Real enforcement still needs server-side access control, because a non-browser client can ignore CORS entirely and call the endpoint directly.

For a practical reference on method-level access control and related browser-side failure patterns, see the Broken Access Control Prevention Guide.

Common Misconfigurations and Operational Use

Teams often make the method list broader than necessary, copy it across environments without review, or assume that a successful preflight means the endpoint is safe. Those mistakes can hide authorization weaknesses and create a false sense of protection around destructive or privileged operations.

Good usage is narrow and explicit. The allowed methods should match the real cross-origin use case, be reviewed alongside the origin policy, and be kept in sync with the server’s actual route permissions so preflight does not advertise more capability than the application is meant to expose.

For a broader view of access control design, including role and policy choices that sit behind method-level checks, the Authorisation Models Guide is a useful companion.

Risk and Threat Considerations

Overly broad method allowances can widen the impact of CORS mistakes by making state-changing functions reachable from hostile origins in the browser context. The risk is greatest when the application also relies on cookies or other ambient credentials and the server does not re-check authorization on the target action.

Failure mechanism: A permissive preflight response can permit a browser to send a cross-origin request that the developer assumed would be stopped, while the real server-side control path remains under-enforced or inconsistent with the header.

Impact: Attackers may be able to trigger unintended writes, destructive actions, or privilege-sensitive operations through a victim’s browser, especially where other CORS settings, CSRF defenses, or access checks are weak.

Practitioner Guidance

Why practitioners should care: Treat this header as part of the browser trust boundary, not as the source of truth for authorization. The safest method list is the one that exactly matches the cross-origin flows you actually support.

What to watch for: Review any endpoint that advertises methods it does not genuinely need, especially where preflight allows unsafe verbs on routes that also perform sensitive business actions. Keep the header aligned with server-side method handling so tests and production behaviour do not drift apart.

Practitioner takeaway: If the browser can preflight it, the server must still independently decide whether the method is allowed, because CORS is a client-side policy check, not an access-control guarantee.

Related resources from NHI Mgmt Group

• What breaks when JSON-RPC methods are not tested for parameter abuse and access control failures?
• Which authentication methods are strongest when organisations need phishing-resistant access control?
• What happens when access control weaknesses allow attackers to move from login compromise to large-scale data theft?
• Why do traditional access control methods create risk in dynamic digital environments?