CSP header causes issues

[C-odes]

Prerequisites

• [x ] I have read the documentation;

Description

I get this message spammed at me in console chrome.
I have a huge schema, and I expect the dependencies to work based on boolean values like checkbox.

Steps to Reproduce

Dont know what about my schema is wrong considering it works in playground .

Expected behavior

I expect the dependencies to work, so for a boolean checkbox value, if I answer yes(check the box) I am supposed to get a input field appear.
[What you expected to happen]

Actual behavior

Nothing happens. I get a form with checkbox and when I check it , No input fields arrive. This is one example, considering my schema is big , I have many dependencies but noone work.

WEIRDEST PART IS: in a dummie project, it works. In the playground, it works. BUT NOT IN MINE. AND I commented out everything other than sending the schema I get from backend to the Form.

Version

"react-jsonschema-form": "^1.6.1"

example of console:

( in chrome):

[epicfaace]

What's your schema?

[C-odes]

I will need to give you a sample of one dependency that does not work. And also change sensitive info with more non sensitive names.

Itll have to wait for tomorrow tho. Thanks so much for the help in advance!

[C-odes]

Turns out is was CSP set up messing for this library. The project without it had it working.

[epicfaace]

That's interesting -- how would the CSP affect the behavior of react-jsonschema-form?

[C-odes]

Honestly no clue. Was working from home on a tight schedule. Considering the exact same schema worked on the playground and a small test project I made (simple create react app) , I suspected maybe I had some packages that was ruining for this library somehow. Today a colleague just told me when he commented out the csp, the dependencies worked again like a charm.

[C-odes]

It was a change to the csp that was newly made I believe. I remember it was giving either a warning or an error in the console log. But didnt think it was related to this

[epicfaace]

Ok, good it works then!

[nathfy]

@epicfaace can you re-open this issue? we've just been burnt by it too. If you apply a CSP header like:

<meta http-equiv="Content-Security-Policy" content="base-uri 'none';
  default-src 'self' 'unsafe-inline';
  object-src 'none';">

Then it breaks - we are investigating, I'll report back if we find a way to get the CSP and the package to work together. Then can add to documentation.

[epicfaace]

@nathfy any updates?

[nathfy]

@epicfaace the only way we got it working was to add the CSP header containing:

default-src 'unsafe-inline';

Which is a problem as it allows inline scripts - there is a work around: https://developers.google.com/web/fundamentals/security/csp/#if_you_absolutely_must_use_it_
So this resolves the issue for now, but really it'd be better to remove the inline scripts requirement.

[killua-eu]

So I encountered the same problem too. Simple way to replicate is to

• yarn add react-jsonschema-form
• the resulting node_modules/react-jsonschema-form/dist/react-jsonschema-form.js contains this: "<script>document.F=Object<\/script>" (see i.e. https://unpkg.com/[email protected]/dist/react-jsonschema-form.js )
• the above mentioned piece of code is interpreted by browsers as unsafe-inline, which is something noone wants to use with CSP since its obviously unsafe.
• typically, inline javascript is marked as safe with nonces which are required to be unique on each request. the nonce is set in the header and the same nonce must be added to every inline <script> as <script nonce="the-unique-nonce-thats-also-in-the-headers">. Since there's no reasonable way how to do that in a static dist file, rjsf is and will be broken, until "<script>document.F=Object<\/script>" disappears from the dist file.

[epicfaace]

Looks like it might be coming from core-js? (See, for example, https://github.com/gaynor-landmark/react3-tic-tac-toe/blob/898ba0acb1dd93be060dfeb9e0ae4e2b8cbc513e/jspm_packages/npm/core-js%402.1.5/library/modules/_object-create.js)

[killua-eu]

@epicfaace > javascript is not my domain, but yeah looks like the same thing. BTW, CSP can also break on the eval function ... I can also see Function("return this")()||(0,eval) in the dist build of rjsf.

[wegry]

 yarn why ajv
├─ @rjsf/core@npm:2.4.2
│  └─ ajv@npm:6.12.6 (via npm:^6.7.0)
│
├─ @rjsf/core@npm:2.4.2 [6c96e]
│  └─ ajv@npm:6.12.6 (via npm:^6.7.0)
│

It looks like ajv requires unsafe-eval to be used in CSP. https://ajv.js.org/docs/security.html

When using Ajv in a browser page with enabled Content Security Policy (CSP), script-src directive must include 'unsafe-eval'.

Please note: unsafe-eval is NOT recommended in a secure CSP[1], as it has the potential to open the document to cross-site scripting (XSS) attacks.

In order to use Ajv without relaxing CSP, you can compile the schemas using CLI or programmatically in your build code - see Standalone validation code. Compiled JavaScript file can export one or several validation functions that have the same code as the schemas compiled at runtime.

[biggyspender]

Indeed. AJV is a type of compiler, and it uses the Function constructor with strings that contain code in order to evaluate (i.e. run) the validator that it compiles at run-time. This is effectively the same as eval and is treated as such when CSP policies are applied.

It seems viable to me that it might be possible to use ajv-cli to precompile a validator, but there is no path available in rjsf to plug this in.

The validation code here (which uses AJV) is tightly bound to the form code here. Without offering a means of plugging in a precompiled validator, the most restrictive CSP will still require the use of script-src 'unsafe-eval'