fix(nginx): allow 'unsafe-eval' in production CSP for guest fingerprinting

[thewrz]

Why

On production (app.wrzdj.com), the browser console throws on guest surfaces:

CSP: The page's settings blocked a JavaScript eval (script-src) ... (Missing 'unsafe-eval')

useGuestIdentity lazy-loads @thumbmarkjs/thumbmarkjs and calls getFingerprint() to mint the guest identity that backs the human-verification / anti-bot gate (join, collect, NicknameGate). The fingerprint probes the JS engine via eval, which production CSP script-src blocks. The dev-proxy CSP already includes 'unsafe-eval', so it worked locally but silently degraded/broke guest fingerprinting in production — a dev→prod config drift.

What

Add 'unsafe-eval' to script-src in both CSP blocks (server-level + /e/{code}/overlay) of the production nginx template, restoring parity with the dev-proxy.

• Scoped to app.yourdomain.com via server_name; the API (api.yourdomain.com) CSP in security_headers.py is untouched.
• Security tradeoff: 'unsafe-eval' weakens XSS mitigation. Accepted to keep the fingerprint-based human gate working (the same call the dev-proxy already permits). Documented inline.

Not the kiosk bug: the kiosk pairing/display paths deliberately avoid useGuestIdentity, so this is independent of the fix/kiosk-pair-cors-header effort (no file overlap).

⚠️ Production deploy

nginx is host-level — deploy.sh does not apply this. After merge + deploy, re-run:

APP_DOMAIN=app.wrzdj.com API_DOMAIN=api.wrzdj.com ./deploy/setup-nginx.sh

Then verify the response Content-Security-Policy header on https://app.wrzdj.com contains 'unsafe-eval'.

Testing

• Confirmed dev-proxy already carries 'unsafe-eval' (parity target)
• No test/code asserts the nginx app CSP string (grep-verified; bridge-app + API CSPs are separate surfaces)
• Post-deploy: guest join/collect pages no longer log the CSP eval error; fingerprint POST /api/public/guest/identify succeeds
• nginx -t clean after setup-nginx.sh

🤖 Co-authored by Claude Opus 4.8 (1M context).

[coderabbitai]

Warning

Review limit reached

@thewrz, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 14 minutes and 12 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more credits in the billing tab to continue.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e43faeb5-1765-4b88-b522-1dfc492766bc

📥 Commits

Reviewing files that changed from the base of the PR and between 002f752 and 94139e9.

📒 Files selected for processing (1)

• deploy/nginx/app.conf.template

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/prod-csp-unsafe-eval

---

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