Configuring embedded domain whitelist and CORS allowed origins in Sisense [Linux]
When embedding Sisense into external applications, browser security headers determine whether dashboards can be framed and APIs can be called. This article explains how Sisense configures frame-ancestors and CORS headers, including correct syntax and wildcard usage. Applies to: Sisense Linux, Cloud and On-Prem deployments.
Step-by-Step Guide
Step 1: Navigate to security settings
- Log in to Sisense as an administrator.
- Go to Admin Tab → Security & Access → Security Settings.
Step 2: Configure Embedded Domain Whitelist
The Embedded Domain Whitelist controls which external origins are allowed to embed Sisense content via the browser-enforced header:
Content-Security-Policy: frame-ancestors
Only origins listed here are permitted to load Sisense content inside an iframe. If the list is empty, any origin is allowed.
Supported syntax
Each entry must be a valid origin or wildcard domain:
https://example.com
https://app.example.com
*.example.com
Invalid entries include:
- Standalone *
- Paths or query parameters
- Trailing slashes
- Protocol-prefixed wildcards (for example, https://*.example.com)
Wildcard behavior
- Wildcards are supported only as part of the host
- *.example.com allows all subdomains of example.com
- The apex domain (example.com) is not included unless explicitly added
- Wildcards are not regular expressions and cannot span multiple domain levels
Step 3: Configure CORS Allowed Origins
The CORS Allowed Origins setting controls browser access to Sisense REST APIs by configuring CORS response headers, primarily:
Access-Control-Allow-Origin
This setting applies only to browser-based HTTP requests and does not affect iframe rendering. If the list is empty, no requests are allowed.
Supported syntax
Valid entries include:
https://example.com
http://localhost:4200
*.example.com
*
Invalid entries include:
- Paths or query parameters
- Partial domain wildcards (for example, example.*)
Wildcard behavior
- *.example.com allows API access from all subdomains
- * allows all origins, subject to browser CORS restrictions
- When credentials are used, browser CORS rules may restrict the effective use of *
Step 4: Understand evaluation timing
- Embedded Domain Whitelist is evaluated by the browser when the iframe is created, via Content-Security-Policy: frame-ancestors
- CORS Allowed Origins is evaluated during API requests and preflight (OPTIONS) checks
- The two settings operate independently and serve different browser security layers
Conclusion
The Embedded Domain Whitelist controls iframe embedding through the CSP frame-ancestors directive, while CORS Allowed Origins governs browser API access using CORS headers. Correct syntax and wildcard usage are critical, as browsers enforce these rules before Sisense application logic is reached.
References / Related Content
- Mozilla Developer Network: Content-Security-Policy – frame-ancestors
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/frame-ancestors - Mozilla Developer Network: Access-Control-Allow-Origin
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin - Mozilla Developer Network: Cross-Origin Resource Sharing (CORS)
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS - W3C Content Security Policy Level 3 Specification
https://www.w3.org/TR/CSP3/#directive-frame-ancestors
