CORS and Allowed Origins

Cross-Origin Resource Sharing (CORS) is a standard that helps protect websites by controlling whether one website is allowed to request data from another. It works like a security guard: the server decides which websites may access its information, and the browser blocks requests from websites that do not have permission.

In Flowgear, you can control which websites are allowed to invoke the Workflow and Core APIs by setting Allowed origins on each Site Environment.

Configure origins

  1. Open the Site settings screen.
  2. Edit the target Environment.
  3. Enter permitted origins in Allowed origins, one per line.
  4. Save the Environment.
  5. Retry the browser request against that Environment's hostname.

An origin includes scheme, host, and port, for example https://app.example.com or http://localhost:5173. Matching is case-insensitive but otherwise exact. Do not enter URL paths. * permits any origin and should be used only after reviewing credential and data-exposure risk.

Flowgear's own Console origins remain permitted. A request without an Origin header is not evaluated as a browser CORS request.

Platform-owned headers

For an allowed Workflow HTTP request, the platform supplies the appropriate Access-Control-Allow-Origin, permitted HTTP Methods, credentials, exposed headers, and requested headers. It handles an OPTIONS preflight before Workflow invocation.

Do not add Access-Control-* headers to v2 Runtime HTTP respond Steps. Duplicate or conflicting headers can produce misleading browser failures, and they do not override the Environment allowlist.

Workflow MCP uses the same Environment allowlist but a narrower transport policy for its Streamable HTTP endpoint. Browser MCP clients must use an allowed origin and the supported authorization and protocol headers.

Apps

An embedded App normally uses the Console bridge and current user context. A standalone browser App that calls a Workflow endpoint directly needs:

  • Its exact frontend origin in the target Environment.
  • An authorization model valid for that Environment and Workflow.
  • A published, enabled backend Workflow.

CORS only controls whether a browser may read a cross-origin response. It does not replace API-key, user, Workflow, or Environment authorization.

Diagnose a browser failure

Check the browser network panel for the exact Origin, preflight Method, requested headers, target hostname, and response status. A 403 before Workflow logs are created commonly indicates a disallowed origin or failed authorization rather than a Workflow design error.

See Site Environment, App Security Model, and HTTP Workflow Request and Response.