CORS preflight failing: "Request header field … is not allowed by Access-Control-Allow-Headers"

Fix it yourself

Follow the repair

1. Read the error literally, then inspect the OPTIONS request. The browser's message names the exact header being rejected: "Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response." That is your shopping list. Then open DevTools, go to Network, trigger the failure, and click the OPTIONS request. Its status splits the problem in two: 404, 405, or 500 means the server is not handling preflights at all; a 200 or 204 means it answers, but its Access-Control-Allow-Headers value does not include the named header. The fixes differ, so know which one you have.
2. On Express, let the cors middleware answer preflights — globally, before your routes. The cors package handles OPTIONS automatically, but only for requests that pass through it, so it must be registered with app.use before your route definitions, not attached to individual routes the preflight never reaches.

   // npm install cors
   import cors from "cors";
   import express from "express";
   
   const app = express();
   
   app.use(cors({
     origin: "https://your-site.com",
     allowedHeaders: ["Content-Type", "Authorization"],
   }));

   List every custom header your frontend sends in allowedHeaders (or leave the option out and the package reflects what the browser asks for). If you wrote your own header-setting middleware instead, you must answer OPTIONS explicitly with a 204 and the same headers — a handler that only decorates GET and POST responses leaves the preflight to die on its own.
3. In a Next.js API route, export an OPTIONS handler that allows the headers. Route handlers do not answer preflight automatically. Add an OPTIONS export alongside your GET or POST, returning the permission headers — including the one your error named.

   const corsHeaders = {
     "Access-Control-Allow-Origin": "https://your-site.com",
     "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
     "Access-Control-Allow-Headers": "Content-Type, Authorization",
   };
   
   export async function OPTIONS() {
     return new Response(null, { status: 204, headers: corsHeaders });
   }
   
   export async function POST() {
     // your handler, returning responses with corsHeaders attached
     return Response.json({ ok: true }, { headers: corsHeaders });
   }

   If you handle CORS in a middleware.ts instead, check its matcher actually covers the API path being called — a matcher that skips the route means the preflight meets nothing at all.
4. On a Supabase Edge Function, handle OPTIONS first and list Supabase's own headers. Edge Functions receive the preflight like any other request, and if your function ignores it, every call from the browser fails — because supabase-js always sends apikey and Authorization headers, so every call is preflighted. Supabase's documented pattern is a shared cors.ts:

   // supabase/functions/_shared/cors.ts
   export const corsHeaders = {
     "Access-Control-Allow-Origin": "*",
     "Access-Control-Allow-Headers":
       "authorization, x-client-info, apikey, content-type",
   };

   And in the function itself, answer the preflight before doing anything else:

   import { corsHeaders } from "../_shared/cors.ts";
   
   Deno.serve(async (req) => {
     if (req.method === "OPTIONS") {
       return new Response("ok", { headers: corsHeaders });
     }
     // real work here — and include corsHeaders on this response too
   });

5. Verify against the preflight, not the error message. Reload, trigger the call again, and click the OPTIONS request in the Network tab. You want: status 200 or 204, an Access-Control-Allow-Origin matching your site's origin, and an Access-Control-Allow-Headers value that contains the header the error named. The moment those three line up, the real request fires immediately behind the preflight and you will see both in the list. If the preflight succeeds but the real request now fails with a different CORS message about the origin header, that is the sibling problem — the response to the actual request needs the same origin header attached.
6. Do not dodge the preflight by stripping your request down. It is tempting to remove the Authorization header or send the body as text/plain so the request counts as "simple" and skips the rehearsal. That can silence the error while breaking authentication or leaving your server parsing a body it did not expect — the error gone, the feature quietly wrong. Preflight is not the enemy; it is a checklist the server is failing. Answer the checklist on the server and every browser, not just yours, gets through.