---
title: "Blocked by CORS policy"
description: "Work out whether the browser is refusing a public Fillo endpoint, code sync, a private API, or direct storage."
group: "Reference"
order: 1
type: "troubleshooting"
parent: "troubleshooting"
keywords:
  - "CORS"
  - "origin"
  - "browser"
  - "sync_origin_denied"
  - "S3"
updated: "2026-07-14"
---

A CORS error names the response the browser refused to expose, so find that request first. Fillo's public endpoints for reading and submitting published forms allow browser origins — code sync, private management calls, and browser-direct storage each have different boundaries.

## Classify the request

| Request | Expected browser behavior |
| --- | --- |
| Load or submit a published form | Allowed from browser origins |
| Sync a code-defined schema with a `pk_` key | Subject to workspace sync policy and allowed origins |
| Call the Management API with an `fsk_` key | Server-side only, with no browser CORS contract |
| Upload directly to S3 | Controlled by the bucket's CORS configuration |
| Upload directly to Google Drive or Box | Uses the signed provider flow created by Fillo |

If a public request shows up as a CORS failure, check its URL and status. A proxy, deployment rewrite, HTML error page, redirect, or wrong API origin can leave out the expected headers even though the endpoint itself supports browsers.

## Fix a code sync origin denial

The developer console can report `sync_origin_denied` when a publishable-key sync comes from an origin that isn't on the workspace allowlist.

1. Open **Settings > Developers**.
2. Check whether publishable-key staging is enabled.
3. Add the exact application origin, including scheme and non-default port when present.
4. Don't include a page path or query string.
5. Reload from that origin and try again.

For stricter production control, keep the workspace on authenticated-only staging and push reviewed schemas with the CLI or a server sync token. A public key never publishes a staged change live.

## Keep management credentials on the server

Don't work around a Management API CORS failure by standing up a public proxy that forwards arbitrary requests. Put the `fsk_` key in a server-only environment variable, validate the operation in your backend, and call Fillo from there.

## Configure S3 separately

An S3 upload goes straight from the respondent's browser to your bucket. Allow your actual form origins, the required multipart methods, and the provider-required headers in the bucket policy. Fillo can't add a missing bucket CORS rule at request time.

## Related

- [File upload was rejected](/docs/troubleshooting/upload-rejected): Separate storage CORS from file validation.
- [API reference](/docs/api): Choose the public or server-side endpoint for the job.
- [CLI](/docs/cli): Stage code-defined forms without browser sync access.
