FEAT(Security): Implement Browser Security Hardening To Improve Lighthouse Best Practices#59
Conversation
… improve Lighthouse Best Practices
|
@ayyushh-18 is attempting to deploy a commit to the rishabhjtripathi2903-3434's projects Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughThe PR adds security headers to Vercel, Vite, and the backend server, updates backend server startup/export behavior, and adds an integration test that checks the ChangesSecurity header hardening
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment Warning |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
app/vite.config.ts (1)
20-29: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winDo not reuse dev-only CSP allowances for preview.
preview.headersshould approximate production, but it currently carries dev allowances such as'unsafe-eval', broadws:/wss:, andhttp://localhost:5000. Splitserverandpreviewpolicies so preview catches production CSP regressions instead of masking them.🤖 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 `@app/vite.config.ts` around lines 20 - 29, The preview CSP in the Vite config is still reusing development-only allowances, so split the policies between the server and preview configs. Update the preview.headers in vite.config.ts to remove dev-only sources like 'unsafe-eval', broad ws:/wss: entries, and http://localhost:5000, and keep it aligned with production; use the existing preview and server config blocks to locate the CSP definitions and ensure preview catches real production regressions.
🤖 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 `@app/vercel.json`:
- Around line 10-11: The Content-Security-Policy in the Vercel config is still
not strict enough to match the intended hardened deployment. Update the CSP
entry by removing unsafe allowances like 'unsafe-eval', ws:/wss:, and the
localhost socket exception unless they are truly required, and add Trusted Types
directives only after auditing the app’s use of dangerouslySetInnerHTML for
compatibility. Keep the CSP settings aligned with app/vite.config.ts so preview
and production enforce the same policy, and reference the existing
Content-Security-Policy value in vercel.json when making the change.
In `@app/vite.config.ts`:
- Line 42: The empty fallback from vite.config.ts is being overridden by the
consumer in main.tsx, so the local health ping still resolves to the Render URL
instead of staying empty. Update the import.meta.env.VITE_API_BASE_URL usage in
app/src/main.tsx to respect the empty-string fallback from VITE_API_BASE_URL
(remove or conditionalize the hardcoded Render default), and keep the behavior
aligned with the static replacement performed by Vite define.
- Around line 8-10: The Vite dev server Content-Security-Policy in
server.headers is too strict for `@vitejs/plugin-react`’s React Refresh preamble,
which prevents HMR in development. Update the CSP in vite.config.ts so it allows
the React Refresh inline script during dev, either by making the policy dev-only
and adding 'unsafe-inline' or by supplying an appropriate nonce/hash, while
keeping the production policy unchanged.
---
Nitpick comments:
In `@app/vite.config.ts`:
- Around line 20-29: The preview CSP in the Vite config is still reusing
development-only allowances, so split the policies between the server and
preview configs. Update the preview.headers in vite.config.ts to remove dev-only
sources like 'unsafe-eval', broad ws:/wss: entries, and http://localhost:5000,
and keep it aligned with production; use the existing preview and server config
blocks to locate the CSP definitions and ensure preview catches real production
regressions.
🪄 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: 835aa16e-7c3b-4642-aefa-7724a07f4508
⛔ Files ignored due to path filters (2)
app/package-lock.jsonis excluded by!**/package-lock.jsonbackend/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
app/vercel.jsonapp/vite.config.tsbackend/package.jsonbackend/src/server.tsbackend/tests/securityHeaders.test.ts
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📌 Overview
This Pull Request addresses (#40) the Lighthouse Best Practices security findings by implementing modern browser security hardening across the application.
The primary objective was to improve the application's browser security baseline while ensuring that all existing functionality—including authentication, routing, animations, and API communication—continues to work without regressions.
Closes #40
🚀 What was implemented
🔒 Browser Security Hardening
🛡️ Content Security Policy Improvements
🔑 Authentication Compatibility
Special care was taken to ensure that security policies do not interfere with the existing authentication system.
Verified compatibility with:
⚙️ Security Header Improvements
Implemented or configured appropriate browser security headers, including:
✅ Validation
The following areas were verified after implementation:
📈 Expected Outcome
📄 Files Updated
✔️ Checklist
I would appreciate any feedback or suggestions for further improving the security configuration. Thank you for reviewing this PR!
Summary by CodeRabbit