Security & domains

Allowed domains

Each application has a list of domains where its games may appear. We enforce it two ways:

In the browser: the game is served with a Content-Security-Policy: frame-ancestors header listing only your domains, so browsers refuse to show it inside any other site.
On our servers: the page that embeds the game is checked when it loads; unknown sites get a "not enabled for this website" message and the attempt is logged.

Add each host separately (example.com, www.example.com) or use a wildcard *.example.com (subdomains only, not example.com itself).
IP addresses aren't allowed, except 127.0.0.1/localhost which work automatically with test keys.
Live embeds refuse to run when opened directly in a browser tab.

Publishable keys are public by design — they only work on your domains.
Keep secret keys in server environment variables. Never put them in HTML, JavaScript, mobile apps or Git.
If a secret key may have leaked, rotate or revoke it immediately from the dashboard.

Credits are charged only on our servers, inside a database transaction, with unique session and launch identifiers — replayed or duplicated requests can't charge twice.
Scores are checked against each game's maximum possible score and rate-limited.
Session starts are rate-limited per visitor network (30/hour per application) to stop credit-draining bots.
Embeds set no cookies and receive no data from your page.
Webhooks are signed; secrets are encrypted at rest; the API rejects keys in URLs.
Every sensitive action (key changes, domain changes, suspicious requests) is written to an audit log.