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

<your-subdomain>.phaselab.co

Web application

<your-subdomain>.api.phaselab.co

Application API

<your-subdomain>-docs.api.phaselab.co

Document viewer / engine

login.phaselab.co

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:

  1. TLS/SSL inspection (HTTPS decryption). Add these domains to your inspection bypass/exclusion list.

  2. 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.

  3. 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.

  4. Blocking cross-origin (CORS) preflight requests. The browser sends OPTIONS preflight requests between these domains; these must be allowed through.

  5. Blocking WebSocket connections. The document viewer uses secure WebSockets (wss://) on the -docs.api.phaselab.co domain.

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:

  1. Have an affected user open browser DevTools → Network, reproduce the error, and click the failed request (its URL ends in /auth).

  2. Check the Response Headers:

    • If the Server or Via header shows a proxy/security appliance (i.e. not Document Engine or awselb), that appliance is intercepting the request.

    • If Access-Control-Allow-Origin is 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.