Configuring embedded domain whitelist and CORS allowed origins in Sisense [Linux]
Summary: Taras Skvarko provides a comprehensive step-by-step guide for configuring embedded domain whitelists and CORS allowed origins in Sisense for Linux. The guide includes navigating to security settings, configuring the Embedded Domain Whitelist, understanding wildcard behavior, and configuring CORS Allowed Origins. It explains the importance of correct syntax and a clear understanding of the evaluation timing for both settings, highlighting their roles in browser security. The guide concludes with references to relevant resources for further information.
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-ancestorsMozilla Developer Network: Access-Control-Allow-Origin
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-OriginMozilla Developer Network: Cross-Origin Resource Sharing (CORS)
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORSW3C Content Security Policy Level 3 Specification
https://www.w3.org/TR/CSP3/#directive-frame-ancestors
