No security headers in Firebase Hosting — firebase.json#217
Conversation
|
@krishnnag998-del is attempting to deploy a commit to the hrx01-dev's projects Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughSecurity response headers were added to Firebase Hosting and the Vite dev server. Both configs now set nosniff, frame blocking, XSS protection, a referrer policy, and a Content-Security-Policy. ChangesSecurity headers configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@firebase.json`:
- Line 41: The Firebase Hosting CSP is too permissive in the header
configuration. In the firebase.json security header value, remove the unused
`unsafe-eval` and `ws:` allowances while keeping the inline script/style
allowances needed by `index.html`. If you tighten further, update the
`window.__SERVIO_FP__` inline snippet to use a nonce/hash or move it into the
bundle, and keep the change localized to the CSP header entry.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2917cc35-e374-40ab-8da5-dcf738a7b81e
📒 Files selected for processing (2)
firebase.jsonvite.config.ts
| }, | ||
| { | ||
| "key": "Content-Security-Policy", | ||
| "value": "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com data:; img-src 'self' data: https: blob:; connect-src 'self' https: wss: ws:; frame-src 'self' https:; object-src 'none';" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether production code truly needs eval-like APIs or direct WebSocket endpoints.
rg -n -C2 '\beval\s*\(|new Function\s*\(|WebSocket\s*\(|ws://|wss://' --glob '!dist/**' --glob '!node_modules/**'
rg -n -C2 '<script(?![^>]*\bsrc=)|<style' index.htmlRepository: hrx01-dev/Servio
Length of output: 154
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the Firebase Hosting headers and the app entry HTML.
sed -n '1,120p' firebase.json
printf '\n--- index.html ---\n'
sed -n '1,220p' index.html
printf '\n--- search for websocket/eval-like usage ---\n'
rg -n -C2 '\beval\s*\(|new Function\s*\(|WebSocket\s*\(|ws://|wss://' . --glob '!dist/**' --glob '!node_modules/**' --glob '!build/**'
printf '\n--- search for inline script/style in HTML files ---\n'
rg -n -C2 '<script(?![^>]*\bsrc=)|<style' . -g '*.html'Repository: hrx01-dev/Servio
Length of output: 4562
Remove the unused CSP allowances from Firebase Hosting. index.html still needs the inline script/style allowances, but nothing in the codebase uses eval-like APIs or WebSockets, so unsafe-eval and ws: can be dropped from the header. If you want to tighten it further, move the inline window.__SERVIO_FP__ snippet into the bundle or protect it with a nonce/hash first.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@firebase.json` at line 41, The Firebase Hosting CSP is too permissive in the
header configuration. In the firebase.json security header value, remove the
unused `unsafe-eval` and `ws:` allowances while keeping the inline script/style
allowances needed by `index.html`. If you tighten further, update the
`window.__SERVIO_FP__` inline snippet to use a nonce/hash or move it into the
bundle, and keep the change localized to the CSP header entry.
description
Here is the simple, easy-to-understand breakdown of what I changed:
I updated exactly two files to act as a "shield" for your website:
I added a new section that tells Firebase to attach security instructions (called "headers") to every single page it sends
to your users.
• What it means: When a user visits your live site, their browser receives these instructions and knows exactly how to
block hackers from tampering with the page.
2. vite.config.ts (For your Local Testing)
I added those exact same security instructions to your local development server (the one you use when you run npm run dev
).
• What it means: This ensures that when you are building and testing the app on your own computer, it behaves exactly the
same way it will on the live website. I also added plain-English comments next to each rule here so you can easily remember
what they do.
What do these new rules actually do?
Think of these headers as a strict set of rules for the user's web browser:
• No Fake Buttons: It stops hackers from putting an invisible layer over your website to trick users into clicking things
they shouldn't (Clickjacking).
• No Sneaky Files: It forces the browser to only read files exactly as they are meant to be read, stopping hackers from
disguising a virus as a normal text file.
• Stop Bad Scripts: It tells the browser to immediately block the page if it catches a hacker trying to run malicious code
(XSS).
• Protect Privacy: It stops your website from accidentally leaking private info (like secret web addresses) when a user
clicks a link to leave your site.
• Approved List (CSP): It gives the browser a strict "VIP Guest List" of where it's allowed to download images, fonts, and
data from. If a hacker tries to sneak in a file from an unapproved source, the browser throws it in the trash.
closes #208
Summary by CodeRabbit