Troubleshooting Cross-Origin Errors (net::ERR_BLOCKED_BY_ORB) with Deployment Protection

When using Vercel's Deployment Protection (Vercel Authentication), you may encounter errors like net::ERR_BLOCKED_BY_ORB where static assets such as CSS or JavaScript files fail to load. This guide explains why this happens and how to resolve it, particularly when integrating with a headless CMS like Sitecore.

Vercel's architecture generates different types of URLs, which is fundamental to understanding this issue:

1. Unique Deployment URL: Every git push creates an immutable, atomic deployment with a unique URL, such as my-app-a1b2c3d4-my-team.vercel.app. This is the direct, unchangeable address for the files of that specific deployment. The System Environment Variable VERCEL_URL always resolves to this unique URL.
2. Stable Alias / Public-Facing Domain: This is a consistent, user-facing URL that points to a specific deployment. This category includes:
3. Custom Domains (e.g., www.myapp.com)
4. Git Branch URLs (e.g., my-app-git-main-my-team.vercel.app)
5. The primary Project Domain (my-app.vercel.app)

Vercel Deployment Protection works by setting an authentication cookie on the Stable Alias that you are visiting. When you access a protected domain, your browser receives a cookie for that specific domain. Any subsequent requests to the same domain will include this cookie, granting you access.

The error occurs when there is a mismatch between the domain you are visiting (the Stable Alias) and the domain from which your static assets are being requested (the Unique Deployment URL).

1. A user accesses a protected deployment through a Stable Alias (e.g., https://www.myapp.com). The browser is successfully authenticated and receives a cookie for www.myapp.com.
2. The application's framework (often configured by a headless CMS integration) incorrectly uses the VERCEL_URL environment variable to construct absolute URLs for static assets like CSS and JavaScript files.
3. This results in the browser trying to fetch an asset from the Unique Deployment URL (e.g., https://my-app-a1b2c3d4-my-team.vercel.app/_next/static/style.css).
4. Because the asset is requested from a different domain (my-app-a1b2...) than the one the user is on (www.myapp.com), the browser does not send the required authentication cookie.
5. Vercel's protection layer sees an unauthenticated request for the asset and returns a 401 Unauthorized status.
6. The browser, enforcing its Cross-Origin Read Blocking (CORB) security policy, blocks the response, leading to the net::ERR_BLOCKED_BY_ORB error in the console.

The most secure and robust solution is to ensure your application generates relative paths for assets (e.g., /_next/style.css) instead of full URLs. Relative paths are domain-agnostic and will always resolve correctly from whichever public-facing domain the user is visiting.

For Sitecore JSS applications, this can be achieved by overriding the default behavior. As seen in the Sitecore JSS source code, the framework will fall back to relative paths if the PUBLIC_URL environment variable is present but contains an empty string.

To implement this fix:

1. Go to your Project in the Vercel Dashboard.
2. Navigate to the Settings tab and click on Environment Variables.
3. Add the following environment variable:

• Name: PUBLIC_URL
• Value: (Leave the value field empty)

By setting PUBLIC_URL to an empty string, you prevent the Sitecore JSS framework from using VERCEL_URL and force it to generate relative asset paths, permanently solving the issue.

If your application strictly requires absolute URLs for assets, you can configure PUBLIC_URL with your stable, public-facing domain. This also resolves the authentication error but is less flexible than using relative paths.

In your Project's Environment Variables settings, add:

• Name: PUBLIC_URL
• Value: https://your-stable-public-facing-domain.com (e.g., https://www.myapp.com)

This ensures that the asset URLs match the domain the user is visiting, allowing the authentication cookie to be sent correctly. This approach aligns with the guidance in the official Sitecore documentation.

As a temporary measure, you can disable Deployment Protection.

• Location: Project Settings > Deployment Protection > Vercel Authentication
• Impact: Disabling this setting makes your preview deployments publicly accessible to anyone with the URL. Vercel automatically adds an x-robots-tag: noindex header to prevent search engines from indexing preview deployments, but the site will not be private.

This is not the recommended long-term solution. The best practice is to resolve the underlying pathing issue by correctly configuring the PUBLIC_URL environment variable.

Observability and Logs

You can monitor your application through the Vercel dashboard.

• Runtime Logs: View real-time logs for Serverless Function invocations from your project's "Logs" tab.
• Log Drains: For advanced observability, you can forward your logs to third-party services via Log Drains.
• For more information, visit the Vercel Logs documentation.