# Website domain checks for browser requests

Apply website domain checks to selected browser requests used by embedded chat and the operator console.

*Release 3.3 · admin, developer, operator, visitor*

**Settings › General Settings › Admin**

## What it is

**Check White List Domains** lets Powerfront enable domain checks for selected browser requests associated with your website. INSIDE also applies separate checks to selected console requests and protected form submissions. These checks work alongside sign-in and permissions.

## Who uses it and why

Administrators give Powerfront the domains that should host their INSIDE experience. Developers check browser behaviour when embedding chat or moving a site. Operators and visitors may encounter a failed request if the applicable domain or form checks do not pass.

## Where to find it

Powerfront manages **Check White List Domains** and **Whitelist Domains** under **Settings › General Settings › Admin**. Anti-forgery checks are part of the affected forms; they have no client Settings toggle.

## How it works

For relevant cross-origin browser requests, INSIDE attempts to identify the website. If checking is enabled and its domain list is non-empty, the request origin is compared with the permitted domains. Platform-approved domains can also be accepted.

When checking is off, or a website's list is empty, the website's cross-origin handling can allow the requesting origin. An empty list therefore does not mean that all origins are blocked.

Selected visitor and console requests separately check the request method and available origin or referring-page information. A failed check can return **Request Forbidden**.

Protected forms such as password reset use an anti-forgery token issued to the browser. Browser domain approval does not replace that token or the account's required permissions.

## Configure it

Ask Powerfront to review **Whitelist Domains** and enable **Check White List Domains**. Supply the domains used for your live website and any approved additional hosting arrangements. Powerfront can review wildcard entries where needed.

Test the embedded chat and relevant browser integrations after a domain change. Console domain policy is managed separately by Powerfront; changing the website list does not define every console request rule.

### Settings

| Setting | Where | Applies to | Default | Who can change it | What it does |
|---|---|---|---|---|---|
| Check White List Domains | Settings › General Settings › Admin | website | Off | Powerfront, on request | Enables website domain-list checking for relevant browser requests when a list is present. |
| Whitelist Domains | Settings › General Settings › Admin | website | Not set: an empty list adds no website-domain restriction | Powerfront, on request | Defines approved website domains for the checks, alongside platform-approved domains. |

## Limits and good to know

- The switch is **Off** by default. The saved list alone does not enable it.
- Browser-origin approval does not authenticate the caller or grant API access.
- A successful browser preflight only concerns browser access to the response. It does not prove the following action is authorised.
- Static resources, forms and other requests can have different policies. Do not treat this switch as a universal security-header control.
- Domain checks differ from operator IP restrictions and approved operator email domains.

## Depends on and works with

### This feature uses

- **Configured in** Admin settings and feature switches (managed by Powerfront): Powerfront manages the website domain controls.
- **Related** [Browser API requests](EXT-020.md): Browser requests must satisfy the applicable origin policy as well as their identity checks.
- **Related** [Visitor chat pane](VX-002.md): Test the embedded visitor chat pane after changing approved website domains.

### Used by

- **Configures** [Traffic Optimizer for visitor tracking](VIS-019.md): Website origin and page-domain checks are part of tracking admission.
- **Configures** [INSIDE API](EXT-018.md): Applicable browser-origin and request checks can reject otherwise identified calls.
- **Configures** [Browser API requests](EXT-020.md): Browser-origin and request restrictions still apply to API requests.

## FAQ and troubleshooting

### Why did chat stop working after a website move?

Ask Powerfront to check the new page's domain against the website policy. Include the affected page and browser error without sending credentials.

### Why does a request fail despite an approved domain?

The request may still fail its method, sign-in, permission or anti-forgery checks. Ask Powerfront to investigate the specific failed action.

### Does an empty whitelist block every browser?

No. A website with an empty list does not enforce this list as a deny-all policy.

### Why did password reset fail after submitting an old page?

The form has a separate anti-forgery check. Reload the reset page and retry; ask Powerfront to investigate if submission still fails.

### Can this restrict operators to our office network?

Ask Powerfront to configure **Operator Access Limitation** for that purpose. Website domains and operator source IP addresses are different controls.