Allowed origins (CORS) for browser apps
Choose which websites may call your project API from a browser. Unlisted origins — localhost included, unless you list it — get 403 before the request runs.
When a browser calls your project API it sends an Origin header. Sovaria checks it against the project's allowed origins before anything else runs. Listed origins get the right CORS headers (and their preflight OPTIONS requests are answered); every other origin gets 403 ORIGIN_NOT_ALLOWED. Requests without an Origin header — servers, scripts, mobile apps — are not affected.
Set them
Go to Project settings → API → Allowed origins and add one origin per line: scheme, host and port, no path.
| Entry | Allows |
|---|---|
https://app.example.com | Exactly that origin. |
https://*.example.com | Any subdomain of example.com over HTTPS. |
http://localhost:* | Local development on any port. Remove it when you no longer need it. |
New projects start with http://localhost:* and http://127.0.0.1:* listed so local development works out of the box. Both can be removed.
Check it
# Listed origin: 204 with Access-Control-Allow-Origin
curl -s -o /dev/null -w '%{http_code}\n' -X OPTIONS "$URL/api/v1/sql/query" \
-H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: POST'
# Anything else: 403 ORIGIN_NOT_ALLOWED
curl -s -X OPTIONS "$URL/api/v1/sql/query" -H 'Origin: https://evil.example' -H 'Access-Control-Request-Method: POST'What this does and doesn't protect
- It stops other websites from using your anon key from their visitors' browsers.
- It does not replace policies: anyone can call your API from a script with your anon key. Access is decided by policies and Row-level security and access.
- Never put the service role key in a browser app, whatever the origins are.