Security / Allowed domains
Allowed domains
Your publishable key is meant to ship in browser code, so it's public by design. Allowed domains are what stop someone who copies that key out of your bundle from using it from their own site: Onelo checks the browser's Origin header against the list of domains you've verified for the app. The SDK sends that header automatically — you write nothing.
What it protects
The gate applies to requests that carry a publishable key from a browser — the ones that arrive with an Origin header. Onelo rejects any request whose origin isn't on your app's verified list. The requests it covers:
| Endpoint | What it does |
|---|---|
/config | SDK bootstrap config for your app. |
/initiate | Mints the hosted sign-in URL. |
/flow/init | Starts the hosted sign-in flow. |
/signin | Direct sign-in (custom UI, paid plans). |
/signup | Direct sign-up (custom UI, paid plans). |
/refresh | Rotates a session — issues a new access token. |
monitor batch | Browser Monitor event/error batches. |
paywall | Browser paywall/store calls. |
onelo_sk_live_*) is trusted because it never leaves your server and carries no browser Origin. The domain allowlist exists specifically to defend the publishable key, which anyone can read out of your web bundle.Add & verify a domain
In your dashboard go to app → Security → Allowed Domains and add your domain (hostname only, e.g. myapp.com — no https://). The dashboard shows a verification token and offers two ways to prove you own the domain. Pick either one:
Option 1 — DNS TXT record. Add a TXT record at _onelo-verify.<your-domain> whose value is your token:
Type: TXT Host: _onelo-verify.myapp.com Value: onelo-verify=<token-from-dashboard>
Option 2 — HTTP well-known file. Serve a plain-text file at your domain's /.well-known/ path containing the token:
GET https://myapp.com/.well-known/onelo-domain-challenge.txt <token-from-dashboard>
Once either check passes, the domain is marked verified and its origin is added to the app's allowlist. From then on the browser SDK works from that domain with no further setup.
Localhost & dev origins
You can't prove ownership of localhost — there's no public DNS to point a record at, and the well-known fetch's SSRF guard hard-rejects any private/loopback address. But a loopback origin is also a legitimate dev origin (a remote site can't make a victim's browser send Origin: http://localhost), so Onelo auto-verifies these hosts with no DNS/HTTP step:
| Host | Notes |
|---|---|
localhost | Plus any subdomain — *.localhost is loopback per RFC 6761. |
127.0.0.1 | IPv4 loopback. |
::1 | IPv6 loopback. |
*.localhost | e.g. app.localhost. |
localhost:5175 sends Origin: http://localhost:5175, so add it with the port included — both http:// and https:// variants are allowed for you.When it's enforced
Enforcement depends on whether the app is live and whether the allowlist is empty. The two edge cases:
| App state | Allowlist | Result |
|---|---|---|
| Live | Empty | Rejected — 403. A live web app with no verified domains means a live publishable key with no protection, so Onelo refuses the request. Going live on web requires ≥1 verified domain, so an empty list here means origins were removed after activation. |
| Draft (not live) | Empty | Fail-open — allowed. So a first-deploy app doesn't lock itself out while you're still wiring things up before going live. |
| Any | Non-empty | Exact-match. The request's Origin must be on the list, otherwise 403. |