[FIX] Frontend CSP: add unsafe-eval for RJSF and blob: for PDF viewer - #1875

Frontend Lint Report (Biome)

✅ All checks passed! No linting or formatting issues found.

No actionable comments were generated in the recent review. 🎉

Summary by CodeRabbit

• Chores
  • Updated web server security configuration to support additional application requirements and improve platform compatibility.

Walkthrough

Updated the Content-Security-Policy header in nginx configuration to allow 'unsafe-eval' for scripts and blob: protocol for connections, with corresponding inline documentation updates.

Changes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

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 @coderabbitai help to get the list of available commands and usage tips.}

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Greptile Summary

This PR relaxes two CSP directives in frontend/nginx.conf to fix two separate runtime breakages introduced by the parent PR #1834:

• 'unsafe-eval' in script-src: Unblocks RJSF (new Function() usage) so that the Adapter Test Connection dialog and API deployment pages render correctly.
• blob: in connect-src: Unblocks PDF.js's internal fetch() of blob-URL documents so that Prompt Studio can display PDFs.

Key observations:

• The blob: addition to connect-src is low-risk — blob: URLs are origin-scoped and cannot be used to exfiltrate data to external hosts.
• The 'unsafe-eval' addition is functionally correct and well-commented, but it is a meaningful security trade-off: combined with the existing 'unsafe-inline' in script-src, the policy no longer restricts dynamic code execution at all — only script origins are enforced. Any future XSS vulnerability in the app would be more exploitable with this directive present.
• It is worth investigating whether RJSF v5's configurable validators (e.g. ajv8) or nonce-based approaches could restore unsafe-eval restriction in a follow-up, rather than leaving it as a permanent exception.

Confidence Score: 3/5

• Functional fix for real breakages, but unsafe-eval combined with unsafe-inline in script-src leaves CSP providing only origin-based script restriction — worth a follow-up investigation before treating as permanent.
• The blob: addition to connect-src is safe and well-scoped. The unsafe-eval addition is the pragmatic fix for a genuine RJSF requirement, but it represents a cumulative security weakening (both unsafe-inline and unsafe-eval are now present). The change is in a configuration file only and introduces no runtime logic errors, but the security trade-off warrants careful consideration before merging into production.
• frontend/nginx.conf — specifically the combination of 'unsafe-inline' and 'unsafe-eval' in script-src

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Browser
    participant Nginx
    participant RJSF as RJSF (React JSON Schema Form)
    participant PDFjs as PDF.js Viewer

    Browser->>Nginx: GET /index.html
    Nginx-->>Browser: Response + CSP Header
    Note over Browser,Nginx: script-src now includes 'unsafe-eval'<br/>connect-src now includes blob:

    Browser->>RJSF: Render schema form
    RJSF->>Browser: new Function() to compile schema
    Note over Browser,RJSF: Previously blocked by CSP (no unsafe-eval)<br/>Now allowed ✓

    Browser->>PDFjs: Load PDF document
    PDFjs->>Browser: URL.createObjectURL() → blob: URL
    Browser->>Browser: fetch(blob:...) for PDF data
    Note over Browser,PDFjs: Previously blocked by CSP (no blob: in connect-src)<br/>Now allowed ✓
    PDFjs-->>Browser: PDF rendered successfully

This is a comment left during a code review.
Path: frontend/nginx.conf
Line: 58

Comment:
**`unsafe-eval` significantly weakens XSS protection**

Adding `'unsafe-eval'` to `script-src` is a notable security relaxation. With both `'unsafe-inline'` and `'unsafe-eval'` now present in `script-src`, the CSP offers minimal protection against XSS: any injected string can be executed via `eval()` or `new Function()`, and inline scripts are also allowed. The CSP essentially only restricts script *sources* now.

Before accepting this as a permanent fix, it's worth investigating whether RJSF's dependency on `new Function()` can be scoped or avoided:

1. **RJSF v5** introduced a `noHtml5Validate` prop and custom validator support (`ajv8` validator) — check whether the specific RJSF feature triggering `new Function()` can be replaced with a stricter validator that avoids dynamic code generation.
2. Alternatively, some bundlers (e.g. webpack `nonce`-based approaches) can emit a CSP nonce so that only specific inline/eval uses are allowed rather than blanket-enabling it for all scripts.

If this is genuinely unavoidable, the comment is helpful, but it would be worth adding a TODO or linking the upstream RJSF issue so future contributors can re-evaluate when the library matures.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Fix frontend CSP: add unsafe-eval for RJ..." | Re-trigger Greptile}