Critical CSP Bug: Platform blocks 'unsafe-eval' despite correct config

[cyrusgilani-2125]

Hello,

I am writing to report a critical, unresolvable Content Security Policy (CSP) issue on my project (print-port3-d-shell-rdde) that is causing a complete application crash (blank page).

After multiple hours of debugging, I have come to the conclusion that Vercel is actively blocking a CSP directive ('unsafe-eval') that is explicitly allowed in my next.config.js file.

Project Details

• Project URL: https://print-port3-d-shell-rdde.vercel.app

• Most Recent Deployment ID: EFsPwnou3

---

Summary of Factual Evidence

This issue presents a direct logical contradiction between my deployment’s configuration and the platform’s behavior.

• The Application Requirement My application is dependent on Builder.io, which (as confirmed by build-file analysis - app-468...js) requires 'unsafe-eval' to function.

• The Deployed Configuration My currently deployed next.config.js file explicitly and correctly allows 'unsafe-eval' in the script-src directive of the Content-Security-Policy header.

• The Observed Result (The Contradiction) Despite Facts 1 & 2, the browser console proves that the Vercel platform is still blocking 'unsafe-eval'. The console error is: Content Security Policy of your site blocks the use of 'eval' in JavaScript

  

This lead us to the conclusion that the next.config.js header is being ignored or overridden by a more restrictive policy at the platform level.

---

Summary of Troubleshooting Steps Performed

To isolate this issue, I have ruled out all other possible causes I could think of.

1. Cleared “Zombie” Headers: I successfully cleared an initial “duplicate header” conflict. The browser’s “Issues” tab no longer reports any warnings about unneeded headers.

2. Disabled Vercel Analytics: I have confirmed Vercel Web Analytics is, and has been, disabled for this project.

3. Disabled Vercel Speed Insights: I have confirmed Vercel Speed Insights is also disabled.

4. No Conflicting <meta> Tag: I have confirmed the DOM contains no <meta http-equiv="Content-Security-Policy"> tags that could be causing a conflict.

5. Cleared All Caches: The most recent deployment was triggered with the “Redeploy with a clean build cache” option. This action did not resolve the issue.

Request

I have exhausted all code-level and project-level debugging steps. The evidence points to a platform-level configuration that is incorrectly overriding my project’s deployed next.config.js headers.

Please investigate the platform/edge configuration for this project (print-port3-d-shell-rdde) and remove the restrictive CSP rule that is causing this contradiction.

Thank you,
Cyrus Gilani

[jacobparis]

When I go to the URL you linked, I see a quick loading screen followed by a soft 404. I can see in the response headers that it’s matching a wildcard route

However if I go to https://print-port3-d-shell-rdde.vercel.app/login I get a blank page but I do see the CSP headers applying correctly

Can you show which route you expect to work and where I can see the CSP not applying? I suspect there’s a redirect in the middle that is causing the issues for you

[cyrusgilani-2125]

Hi Jacob, thank you for the quick response.

Sorry for the confusion, I am only expecting the https://print-port3-d-shell-rdde.vercel.app/login url to load a page, as the root url is not configured. You are correct, the CSP header is applying properly.

However, the problem is not with the header being sent, but with the policy being enforced by the browser. This demonstrates a conflict between the HTTP header we send and a srthat is enforced before execution.

The Issue

What the Network Tab Shows (What you see): The server sends a Content-Security-Policy header that explicitly includes and allows ‘unsafe-eval’ (for the core Builder.io runtime).

What the Browser Enforces (The failure point): The browser’s security engine still registers a failure and blocks ‘eval’. (View attached screenshot from the /login url)

Here is the error from the browser’s Issues tab that shows the blockage.

This leads us to the conclusion that a policy stricter than the one in the HTTP response is overriding it before the JavaScript can run, as we have confirmed that the headers are correct and have ruled out Analytics or Speed Insights causing the issue.

Thank you very much for your help with this issue.

[jacobparis]

Have you tried different browser? I don’t see any matching issues in my dev tools, although it’s possible that since I’m not logged in I’m just not getting far enough to see them

[cyrusgilani-2125]

Thank you, it turned out to just be a browser extension enforcing the CSP.