Network allowlist requirements for Phaselaw
Last updated: July 30, 2026
Instructions for ensuring that the Phaselaw product is reachable
For customer IT and network administrators
Phaselaw is a browser-based application. For it to work correctly on your network, the domains below must be reachable and must not be modified in transit by web proxies, secure web gateways, TLS/SSL inspection, or cloud-access security tools.
Your Phaselaw workspace uses a subdomain unique to your organization. Throughout this article, replace <your-subdomain> with yours (for example, if you access Phaselaw at https://acme.phaselab.co, your subdomain is acme).
Domains to allowlist
Domain | Purpose |
|---|---|
| Web application |
| Application API |
| Document viewer / engine |
| Sign-in (authentication) |
If your tooling supports wildcards, allowlisting *.phaselab.co covers all of the above.
Requirements
For these domains, please ensure your proxy / firewall / security tooling does not do any of the following:
TLS/SSL inspection (HTTPS decryption). Add these domains to your inspection bypass/exclusion list.
HTTP header modification or stripping. The application relies on standard CORS headers (notably
Access-Control-Allow-Origin) and custom headers. Removing or altering them will break the document viewer.URL rewriting or domain "cloaking." Tools such as Microsoft Defender for Cloud Apps / Conditional Access App Control that rewrite or suffix URLs are not supported for these domains.
Blocking cross-origin (CORS) preflight requests. The browser sends
OPTIONSpreflight requests between these domains; these must be allowed through.Blocking WebSocket connections. The document viewer uses secure WebSockets (
wss://) on the-docs.api.phaselab.codomain.
Ports 443 (HTTPS) and WebSocket over 443 must be open outbound.
Why this matters
The web app (<your-subdomain>.phaselab.co) and the document viewer (<your-subdomain>-docs.api.phaselab.co) are separate domains that communicate using a browser security mechanism called CORS. Security tools that inspect or rewrite HTTPS traffic frequently strip the CORS response header or block the preflight request, even though the request and response are otherwise valid. When that happens, documents fail to load and the browser console shows an error such as:
Access to fetch at https://<your-subdomain>-docs.api.phaselab.co/… from origin https://<your-subdomain>.phaselab.co has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Adding the domains above to your inspection-bypass and header-preservation exclusions resolves this.
How to confirm if you're encountering a network/proxy issue
If users see the error above, an administrator can confirm the cause:
Have an affected user open browser DevTools → Network, reproduce the error, and click the failed request (its URL ends in
/auth).Check the Response Headers:
If the
ServerorViaheader shows a proxy/security appliance (i.e. notDocument Engineorawselb), that appliance is intercepting the request.If
Access-Control-Allow-Originis absent from the response, it is being stripped in transit.
Applying the exclusions above to the four domains resolves both cases.
Still need help?
Contact Phaselaw support at support@phaselab.co. If possible, include the DevTools Response Headers from the failed /auth request described above — it helps us pinpoint the intercepting device on your network.