Edge Function returns HTTP 520 "Origin is disallowed" for every POST request

[carloschavez8]

Problem

A deployed Supabase Edge Function accepts GET and OPTIONS requests, but every
POST, PUT, and DELETE request is rejected with:

HTTP 520
Origin is disallowed

The rejected requests do not appear in the Edge Function logs, which suggests
that they are being rejected before reaching the Deno runtime.

Verified behavior

• GET /health returns HTTP 200 and {"status":"ok","version":"3"}
• GET /owner/status returns HTTP 200
• OPTIONS returns HTTP 204
• POST /health returns HTTP 520 Origin is disallowed
• POST /owner/bootstrap returns the same HTTP 520 response
• The result is the same with no authorization, anon authorization, API key,
  or both headers
• The result is the same with and without an Origin header

Configuration

• Supabase Edge Functions
• TypeScript / Deno
• Hono
• @supabase/supabase-js
• Legacy JWT verification is disabled
• CORS was tested using Hono middleware and manual headers
• Access-Control-Allow-Origin: *
• Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
• Access-Control-Allow-Headers: Content-Type, Authorization, apikey

Additional information

The function was redeployed successfully from the Supabase dashboard.
The problem still occurs after redeployment.
Supabase support ticket: SU-517126

What project or gateway setting could reject all unsafe HTTP methods with
"Origin is disallowed" before the request reaches the Edge Function runtime?

[kirlyr]

Interesting that GET and OPTIONS work, but every POST fails even without an Origin header.

Since you've already ruled out the usual CORS configuration changes, I'd try deploying a minimal temporary Edge Function with no Hono middleware or custom authentication, just a POST handler returning a simple JSON response.

If that works, it would help narrow the issue to your existing function's middleware or routing. If it fails with the same 520 response, that would be useful evidence for your Supabase support ticket.

I'd also compare the response headers and request IDs between the successful GET and failed POST, along with their UTC timestamps.

I wouldn't relax the origin checks or authentication rules until the rejecting layer is identified. Hope this helps narrow it down!

[DYNOSuprovo]

The exact phrase "Origin is disallowed" is not coming from a Supabase gateway or Cloudflare setting—it is the literal, hardcoded error message from Hono's csrf() middleware:

// From hono/src/middleware/csrf/index.ts:
if (!isAllowed(origin)) {
  return c.text('Origin is disallowed', 403)
}

This explains 100% of the symptoms you observed:

---

Why the behavior matched your test results:

1. GET and OPTIONS return 200 / 204:
   CSRF protection by design only validates state-changing / unsafe HTTP methods (POST, PUT, PATCH, DELETE). Safe methods (GET, HEAD, OPTIONS) completely bypass the check.
2. POST /health fails even without authentication:
   CSRF middleware runs before route handlers and before auth middleware.
3. Fails even without an Origin header (e.g. via curl / Postman):
   By default, Hono's csrf() middleware requires a valid Origin (or Sec-Fetch-Site) matching your host for mutating requests. If the header is missing or does not match your host, it rejects the request with "Origin is disallowed".
4. Why it looks like it never reached the function:
   Early middleware rejections in Hono that terminate before invocation of application logs often get returned directly. When run behind the edge runner, custom 403 rejections with specific header formats can surface as a proxy status or 520 depending on upstream header parsing.

---

How to Fix It

Check your Hono initialization in your Edge Function entry point (index.ts):

Option A: If this is an API / Backend Service (Remove CSRF)

For APIs where clients (mobile apps, frontend SPAs with Bearer tokens, or backend workers) interact via POST using Authorization headers, CSRF protection is unnecessary and should not be used:

import { Hono } from 'https://deno.land/x/hono/mod.ts'
import { cors } from 'https://deno.land/x/hono/middleware.ts'
// ❌ REMOVE THIS:
// import { csrf } from 'https://deno.land/x/hono/middleware.ts'

const app = new Hono()

// Keep CORS for cross-origin browser requests:
app.use('*', cors({
  origin: '*',
  allowMethods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowHeaders: ['Content-Type', 'Authorization', 'apikey'],
}))

// ❌ REMOVE THIS LINE:
// app.use('*', csrf())

Option B: If you need CSRF, configure allowed origins explicitly

If your Edge Function serves cookie-authenticated sessions from a specific web app:

import { csrf } from 'hono/csrf'

app.use(
  '*',
  csrf({
    origin: (origin) => {
      // Allow your frontend origins or local development:
      return origin.endsWith('.yourdomain.com') || origin === 'http://localhost:3000'
    },
  })
)

Remove csrf() from your Hono middleware stack and your POST /health and POST /owner/bootstrap endpoints will immediately succeed! If this pinpoints the exact culprit in your code, please feel free to mark this as the accepted answer!

[tisankanj]

Hono CSRF middleware is worth checking, but the error text alone does not establish that it explains your HTTP 520 response. In particular, the earlier “100%” diagnosis omits the content-type condition and assumes an undocumented 403 → 520 transformation.

The current Hono documentation says its built-in check applies to unsafe methods with form-compatible content types (application/x-www-form-urlencoded, multipart/form-data, text/plain). The source reviewed here also treats a missing Content-Type as text/plain and rejects with 403/Forbidden. Your deployed version may differ, so first capture the exact Hono version/import and middleware order.

A useful controlled comparison on a side-effect-free staging handler is:

• Identical POSTs with explicit Content-Type: application/json versus text/plain, and otherwise identical headers.
• A minimal handler with no Hono middleware, versus the same handler with your exact middleware stack.
• A log at handler entry, before routing/middleware, containing only a synthetic correlation ID and method. Compare those timestamps with the response status/body and gateway request ID.

Do not use a privileged bootstrap endpoint for these probes. Absence from your application logger does not by itself establish absence from the runtime if that logger runs after a rejecting middleware.

If JSON and form requests both fail identically in the minimal handler, the current built-in CSRF path is a poor fit; attach that evidence to SU-517126. If the failure appears only after adding middleware, bisect that stack.

I would retain the existing protections until the rejecting layer is identified. CORS response headers do not authenticate callers or resolve a server-side origin check, and changing an origin allowlist cannot explain a gateway error without evidence. I have not reproduced your deployment.

[otaviomoliterno]

To make the isolation test suggested above concrete, deploy a separate temporary function named origin-probe with no Hono imports:

Deno.serve((req) => {
  console.log("origin-probe-entered", req.method);

  return new Response(
    JSON.stringify({ reached: true, method: req.method }),
    {
      status: 200,
      headers: {
        "Content-Type": "application/json",
        "X-Origin-Probe": "v1",
      },
    },
  );
});

Keep its gateway JWT-verification setting consistent with your existing function. Call the project's standard endpoint directly, supplying valid authentication headers if required:

https://<project-ref>.supabase.co/functions/v1/origin-probe

Compare GET and POST using curl or another non-browser client, and inspect both Invocations and Logs in the dashboard.

• If both return the probe JSON and X-Origin-Probe: v1, the project can execute POST requests. The next step is to instrument the original handler before it delegates to Hono, then add its middleware back incrementally.
• If GET reaches the probe but POST returns 520 without its response marker or entry log, collect the response headers and UTC timestamps for your support ticket. That points toward rejection outside this minimal handler, although missing logs alone do not identify the exact infrastructure layer.
• If POST returns 401, resolve the probe's authentication configuration before interpreting the result as evidence about the original 520.

If your application uses a custom domain or another reverse proxy, compare that path with the standard project endpoint too.

A browser CORS failure and an HTTP 520 returned to a non-browser client are different observations. Changing Access-Control-Allow-Origin alone would not establish why this response is being generated.

Reference:
https://supabase.com/docs/guides/functions/logging

[kirlyr]

I found one detail that might help narrow this down.

The exact combination of HTTP 520 + Origin is disallowed actually exists in Cloudflare Containers' ContainerProxy:

https://github.com/cloudflare/containers/blob/main/src/lib/container.ts

It returns that response when an outbound request's hostname is rejected by allowedHosts or deniedHosts.

Meanwhile, Hono's built-in csrf() in v4.10.0 returns 403 Forbidden, not that 520 response:

https://github.com/honojs/hono/blob/v4.10.0/src/middleware/csrf/index.ts

I'm not saying Cloudflare Containers is definitely involved here. Its host restriction applies to outbound requests, and it wouldn't normally explain GET succeeding while POST fails against the same destination.

But that exact error signature makes me curious whether there's another proxy, Worker, or sandbox layer involved in how you're invoking the function.

If you haven't already, I'd compare:

1. A direct POST to the standard *.supabase.co/functions/v1/... endpoint from your local terminal.
2. The same POST through your application's normal request path, if it uses any intermediary.
3. The result from the middleware-free origin-probe suggested above.

If the direct request succeeds but the proxied request returns 520, check the intermediary's outbound host restrictions. If even the direct JSON POST to the minimal function returns 520, I wouldn't attribute it to Hono CSRF or Cloudflare Containers without more evidence.

That difference, along with the response headers, would be useful for ticket SU-517126.

[solvionholdings]

One thing can be ruled out from source: Hono's csrf() middleware doesn't produce this message. When its check fails it throws a 403 whose body is plain Forbidden (https://github.com/honojs/hono/blob/main/src/middleware/csrf/index.ts). It also only checks form-compatible content types (application/x-www-form-urlencoded, multipart/form-data, text/plain) and skips application/json entirely (https://hono.dev/docs/middleware/builtin/csrf). Note that a request with no Content-Type is treated as text/plain. If csrf() is in your stack, a bare curl -X POST with no body would get Forbidden, not this message. A 520 with a different body means something else is rejecting it.

The requests never show up in your function logs, so they're stopped before your code runs. To find which layer, run a quick test:

// supabase/functions/probe/index.ts — no Hono, no middleware
Deno.serve(async (req) => {
  console.log(req.method, req.headers.get('content-type'));
  return Response.json({ method: req.method });
});

supabase functions deploy probe --no-verify-jwt
curl -si -X POST "$SUPABASE_URL/functions/v1/probe" \
  -H 'content-type: application/json' -d '{}'

• If probe also returns 520 on POST, the problem is at the project or gateway level and isn't in your code. Add the sb-request-id/cf-ray headers from that response to ticket SU-517126.
• If probe returns 200, re-add your Hono app piece by piece until the 520 comes back.

Don't widen CORS or turn off auth to make it go away. CORS is enforced by browsers, not by curl, so it can't explain a 520 you get from curl. And verify_jwt should stay on for user-facing functions anyway (https://supabase.com/docs/guides/functions/auth).