Skip to content

fix: skip security headers when devtools is active#2331

Open
RYGRIT wants to merge 1 commit intonpmx-dev:mainfrom
RYGRIT:fix/devtools-csp
Open

fix: skip security headers when devtools is active#2331
RYGRIT wants to merge 1 commit intonpmx-dev:mainfrom
RYGRIT:fix/devtools-csp

Conversation

@RYGRIT
Copy link
Copy Markdown
Contributor

@RYGRIT RYGRIT commented Mar 30, 2026

🔗 Linked issue

🧭 Context

Strict CSP and frame restrictions (such as X-Frame-Options) interfere with Nuxt DevTools' resource injection and iframe UI. This change ensures an improved developer experience without compromising security in the production environment.

📚 Description

@vercel
Copy link
Copy Markdown

vercel bot commented Mar 30, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
npmx.dev Ready Ready Preview, Comment Mar 30, 2026 0:50am
2 Skipped Deployments
Project Deployment Actions Updated (UTC)
docs.npmx.dev Ignored Ignored Preview Mar 30, 2026 0:50am
npmx-lunaria Ignored Ignored Mar 30, 2026 0:50am

Request Review

@codecov
Copy link
Copy Markdown

codecov bot commented Mar 30, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Mar 30, 2026

📝 Walkthrough

Walkthrough

A runtime-mode guard has been added to modules/security-headers.ts that determines whether execution occurs within Nuxt DevTools dev runtime by evaluating Nuxt dev/devtools settings and the TEST environment variable. When this runtime mode is detected, the module's setup function returns early, bypassing all security header configuration including CSP meta injection and catch-all route rules header additions. Security header logic remains active in non-dev or test environments.

🚥 Pre-merge checks | ✅ 1
✅ Passed checks (1 passed)
Check name Status Explanation
Description check ✅ Passed The pull request description clearly explains the context, problem, and solution: it addresses CSP and frame restriction interference with Nuxt DevTools by skipping security headers during dev runtime, which aligns with the changeset in security-headers.ts.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1


ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 207422fc-b94f-41a9-a915-47432109451b

📥 Commits

Reviewing files that changed from the base of the PR and between b3da028 and f02eb39.

📒 Files selected for processing (1)
  • modules/security-headers.ts

Comment on lines +23 to +24
const isDevtoolsRuntime =
nuxt.options.dev && nuxt.options.devtools !== false && !process.env.TEST
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

In Nuxt module setup, what is the exact type/shape of nuxt.options.devtools (boolean vs object), and what is the recommended way to check whether DevTools is enabled when object-form config is used?

💡 Result:

In a Nuxt module's setup function, nuxt.options.devtools is an object (not a boolean). It has the shape of the DevTools module options, where the primary property to check for enabling DevTools is enabled: boolean (defaults to true). The recommended way to check whether DevTools is enabled (when object-form config is used) is: !!nuxt.options.devtools?.enabled. This handles cases where devtools might be undefined (if not explicitly set) or an object without enabled explicitly defined (falls back to default true). Examples from official docs and module source: - devtools: { enabled: true } or devtools: { enabled: false } - Full options: devtools: { enabled: true, vscode: {}, ... } Nuxt DevTools docs explicitly state "To configure Nuxt DevTools, you can pass the devtools options" and show object form with enabled. No sources show devtools as a top-level boolean in current versions (boolean shorthand was discussed in old issues but deprecated).

Citations:


Line 23–24: DevTools enabled check is incomplete; does not verify the enabled property.

The current check nuxt.options.devtools !== false will be true even when devtools.enabled is explicitly false, because nuxt.options.devtools is an object. This causes security headers to be incorrectly skipped when DevTools is disabled via configuration.

Suggested fix
-    const isDevtoolsRuntime =
-      nuxt.options.dev && nuxt.options.devtools !== false && !process.env.TEST
+    const isDevtoolsRuntime =
+      nuxt.options.dev && !!nuxt.options.devtools?.enabled && !process.env.TEST

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant