A Ktor endpoint returns responses without the CORS headers you configured. How do you diagnose it?

## Frame the failure correctly "CORS headers are missing" has exactly two causes: the CORS plugin did not run for this call, or it ran and decided the request did not qualify. Those need different fixes, so establish which one you are looking at before changing configuration. The fastest way to separate them is to bypass the browser. Issue the preflight yourself: ``` curl -i -X OPTIONS https://api.example.com/orders \ -H "Origin: https://app.example.com" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: content-type, x-request-id" ``` A response with no `Access-Control-Allow-Origin` at all tells you the server declined or never evaluated the policy. The browser console will only tell you the request was blocked, which conflates both cases. ## Cause 1 — the plugin never saw the call **Wrong scope.** If CORS was installed inside a `route` block, only that subtree is covered. Endpoints outside it get nothing. Application-wide policy belongs in the module function, installed on the `Application`. **The pipeline finished earlier.** An interceptor or plugin that responds and ends the pipeline before the CORS plugin's phase means later interceptors never run. Any early-rejection logic you added — a body-size guard, a custom auth filter — is a candidate. Check what else is installed and where it sits relative to CORS. **Errors take a different path.** A response produced by exception handling can be assembled outside the flow you expect, so verify with a *successful* request first. If the headers appear on 200s and vanish on 500s, you have narrowed it to the error path, and the fix is to make sure error responses still traverse the plugin. ## Cause 2 — the plugin ran and declined Ktor's CORS plugin is deny-by-default; every allowance is explicit. - **Host and scheme.** `allowHost("app.example.com", schemes = listOf("https"))` — passing a bare host without the scheme the browser actually uses is the single most common mistake. The value must match the browser's `Origin`, which includes scheme and port. A non-default port must be part of the host you allow. - **Headers.** Only a small set of request headers are "simple"; anything else — a custom correlation header, and `Content-Type` when it is `application/json` — must be permitted with `allowHeader`. The preflight's `Access-Control-Request-Headers` lists exactly what the browser wants; compare it line by line with your configuration. - **Methods.** `GET`, `HEAD` and `POST` are the defaults; `PUT`, `PATCH` and `DELETE` need `allowMethod`. - **Credentials.** If the browser sends cookies, the policy must allow credentials, and a wildcard origin is not usable together with credentials — that combination is rejected by browsers regardless of what the server sends. - **Exposed headers.** Response headers your JavaScript needs to *read* must be exposed explicitly; the browser hides everything else even on an allowed response. `anyHost()` exists and will make the error disappear, which is exactly why it is dangerous: it is a diagnostic, not a fix. Use it once to confirm the plugin is running and reachable, then replace it with the explicit host list. Shipping it means any origin can invoke your API from a browser with the user's context. ## Cause 3 — you are debugging the wrong hop In production the request usually passes a reverse proxy, CDN or API gateway. Any of them can strip response headers, answer `OPTIONS` itself, or add its own CORS headers that conflict — and duplicate `Access-Control-Allow-Origin` headers are themselves invalid. Curl the origin server directly and then through the edge; if the two differ, the problem is not in Ktor at all. ## The judgment part Two statements separate a senior answer. First: **CORS is enforced by the browser, not the server.** The server merely states a policy. So "disable CORS" in a client, or a browser flag, proves nothing and fixes nothing — and a non-browser client was never restricted in the first place. If a teammate proposes turning off checks in the browser, that is the moment to push back. Second: **the policy is a security boundary.** The list of allowed origins is the set of web applications permitted to drive your API with the user's cookies. Widening it to end an outage is a real reduction in the system's security posture, and it deserves to be treated as such rather than as a build fix. ## Order of operations, condensed 1. Reproduce the preflight and the actual request with curl, against the origin server. 2. Confirm the install scope covers the route, and that nothing responds earlier in the pipeline. 3. Diff the browser's requested origin, method and headers against the configuration. 4. Check the edge for stripped or duplicated headers. 5. Fix by narrowing configuration to what is genuinely needed — never by allowing every host.