> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ghg.gg/llms.txt
> Use this file to discover all available pages before exploring further.

# Blocked Domains

> Network restrictions, allowed domains, and explicitly blocked domains for game bundles.

# Blocked Domains

The Greenhouse Games platform restricts network access from deployed games. Network requests to domains not on the allowed list are detected during the security scan, reported as security findings, and blocked at runtime by Content Security Policy.

## How It Works

When your game is deployed, the enforced CSP limits `connect-src` to `'self' blob:` — meaning network requests (fetch, XHR, WebSocket) can only reach same-origin endpoints. Any attempt to contact an external domain is blocked by the browser.

During the pre-deployment security scan, the platform also inspects your code for references to external domains. Requests to domains not on the allowed list are flagged as findings, and requests to explicitly blocked domains are flagged at a higher severity.

## Allowed Domains

The following domains are permitted by the platform:

| Domain               | Purpose                                       |
| -------------------- | --------------------------------------------- |
| `greenhousegames.io` | Platform origin — same-origin requests        |
| `cdn.cloudflare.com` | Platform CDN for serving deployed game assets |

Requests to these domains will not generate security findings during the scan phase.

## Explicitly Blocked Domains

The following domains are **explicitly blocked** and will trigger security findings:

| Domain         | Reason                                                                  |
| -------------- | ----------------------------------------------------------------------- |
| `bit.ly`       | URL shortener — can redirect to malicious content                       |
| `tinyurl.com`  | URL shortener — can redirect to malicious content                       |
| `pastebin.com` | Paste service — commonly used to host payloads or exfiltrate data       |
| `github.io`    | External hosting — games must not load resources from third-party hosts |

<Warning>
  Referencing explicitly blocked domains in your game code will result in a security finding. Depending on the context, this may be classified as CRITICAL and cause automatic rejection.
</Warning>

## Practical Guidance

To avoid network-related security findings and CSP violations:

### Bundle all assets locally

Include every resource your game needs — scripts, images, fonts, audio, data files — inside your ZIP bundle. Do not rely on fetching anything from an external server at runtime.

### Avoid external network requests

Your game should not make `fetch()`, `XMLHttpRequest`, or `WebSocket` calls to any external domain. The CSP will block these requests in the browser, and the security scan will flag them before deployment.

### Test with CSP applied locally

Before submitting, add the platform's CSP meta tag to your `index.html` and test in a browser to catch violations early:

```html theme={null}
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob:; connect-src 'self' blob:; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; font-src 'self'; frame-src 'self' blob:; worker-src 'self' blob:">
```

Open your browser's developer console and look for CSP violation errors. Any blocked request will appear as an error message indicating which directive was violated.

<Tip>
  If your game works without errors when tested locally with the CSP meta tag applied, it will pass the network-related checks in the security scan.
</Tip>

## Related

* [Blocked APIs](/security/blocked-apis) — prohibited JavaScript APIs
* [Severity Levels](/security/severity-levels) — how findings are classified
* [CSP Policy Reference](/csp/policy-reference) — the full Content Security Policy enforced at runtime
* [Local CSP Testing](/csp/local-testing) — detailed guide to testing with CSP locally