CORS errors that only happen in production: read the message, then fix the cause.

CORS applies when a page on one origin (scheme, host and port) calls another. Locally, your dev server often proxies /api to the backend, so the browser only ever talks to localhost:5173. Or the API allows http://localhost:3000 and nothing else. In production the frontend is on https://example.ca and the API on https://api.example.ca or https://your-api.canner.app: two origins, and the browser now asks the API for permission.

Treat “CORS error” as a symptom. The browser hides the response from your code, so a crashed endpoint, a 404 and a real policy mismatch all look the same in the console until you open the request.

Chrome’s messages start with Access to fetch at '…' from origin '…' has been blocked by CORS policy:. The rest of the line is the part that matters:

A GET, HEAD or POST with only safelisted headers and a Content-Type of application/x-www-form-urlencoded, multipart/form-data or text/plain goes straight through. Anything else is preflighted first: PUT, PATCH, DELETE, a JSON body, an Authorization header, any custom X- header. That is why a form post works and the same call from fetch() with JSON fails.

The preflight is an OPTIONS request with Access-Control-Request-Method and Access-Control-Request-Headers. Access-Control-Max-Age lets the browser cache the answer; without it the default is 5 seconds, so a slow API pays for two round trips on most calls.

• `www` and the apex are different origins. With Serve www on, Canner answers www.example.ca with a 301 to example.ca (custom domains). A frontend that calls https://www.example.ca/api gets that redirect, and a preflight can’t follow it. Point API calls at the host that serves the app.
• Plain `http://` is redirected to HTTPS at the proxy, which also breaks a preflight. An http:// API URL on an HTTPS page is blocked as mixed content anyway (proxy headers and mixed content).
• Previews have their own origin. A pull-request preview runs at branch--project.canner.app. If the frontend is a separate project, its previews call your API from https://<branch>--web.canner.app, which isn’t on a list written for production.
• Previews share the project’s environment variables. An ALLOWED_ORIGINS set for production applies to previews too. Canner sets CANNER_ENV=preview and CANNER_URL to the preview’s address (environment variables), so code can tell them apart. For a Vite frontend, remember the API URL is baked in at build time (Vite env in production).
• **Never allow every *.canner.app origin.** Other customers’ apps live there. Match your own project’s preview pattern, as in the code below.

// Express, with the cors package. ALLOWED_ORIGINS="https://example.ca,https://admin.example.ca"
const allowed = (process.env.ALLOWED_ORIGINS ?? "").split(",").filter(Boolean);
// Pull-request previews of the frontend project "web": https://<branch>--web.canner.app
const preview = /^https:\/\/[a-z0-9-]+--web\.canner\.app$/;

app.use(cors({
  origin: (origin, cb) => cb(null, !origin || allowed.includes(origin) || preview.test(origin)),
  credentials: true, // only if the browser sends cookies
}));

# FastAPI
app.add_middleware(
    CORSMiddleware,
    allow_origins=os.environ.get("ALLOWED_ORIGINS", "").split(","),
    allow_origin_regex=r"https://[a-z0-9-]+--web\.canner\.app",
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

Canner’s proxy doesn’t add, remove or change Access-Control-* headers, and it passes OPTIONS requests through to your running app. Whatever CORS headers reach the browser are the ones your app sent. That cuts both ways: if your app crashes and answers 500 from an error handler that runs outside the CORS middleware, or doesn’t answer and the proxy returns a 502, the response has no CORS headers and the browser reports a CORS error. Check the app’s logs for that request before touching the policy.

Caches are the other trap. When the API reflects the request’s origin, it must send Vary: Origin, or a shared cache can hand one site’s Access-Control-Allow-Origin to another. Canner’s optional cache never stores a response that varies on Origin, so it can’t cause this; a CDN you put in front yourself might.

• Network tab, not the console. Find the failed request. If there’s an OPTIONS row before it, that’s the preflight: check its status and response headers.
• Compare the `Origin` request header with Access-Control-Allow-Origin in the response. They must match exactly.
• Right-click → Copy as cURL to replay the request outside the browser, then send the preflight yourself (below). curl ignores CORS, so it shows what the server really returns.
• Set the allowed origins as a variable and change them without a code change: canner env set ALLOWED_ORIGINS=https://example.ca,https://admin.example.ca with the CLI, then redeploy.

# Send the preflight the browser would send
curl -i -X OPTIONS https://api.example.ca/items \
  -H "Origin: https://example.ca" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: content-type, authorization"

# A good answer: a 2xx status and, at least,
#   Access-Control-Allow-Origin: https://example.ca
#   Access-Control-Allow-Methods: ... POST ...
#   Access-Control-Allow-Headers: content-type, authorization
#   Vary: Origin

If the frontend and API are yours, serving both from one origin removes the problem: the API under /api in the same app, or a rewrite in the frontend’s server that forwards /api to the backend. Cookies get simpler too. Separate origins make sense when the API has other clients or a different release cycle. More guides are under hosting by framework.