`usePress` style insertion is blocked and logging an error when a strict CSP directive is in effect

[pleunv]

Provide a general summary of the issue here

#8200 was fixed by inserting a style node into the DOM (see here. The problem with this approach is that this breaks anywhere a Content Security Policy is applied that does not allow unsafe-inline. This will more often than not be the case. The result is a block on the style insertion and a console error:

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-…'". Either the 'unsafe-inline' keyword, a hash ('sha256-…'), or a nonce ('nonce-...') is required to enable inline execution.

🤔 Expected Behavior?

Ideally an alternative solution for #8200 is found that does not require insertion of style nodes and thus does not cause the aforementioned error. At the very least, the current solution should support nonces but that's generally not always very straightforward to set up from a library consumer point of view as it requires a way to communicate the nonce to the runtime code.

😯 Current Behavior

usePress is doing style insertion here:

react-spectrum/packages/@react-aria/interactions/src/usePress.ts

Lines 829 to 842 in 77b3442

	const style = ownerDocument.createElement('style');
	style.id = STYLE_ID;
	// touchAction: 'manipulation' is supposed to be equivalent, but in
	// Safari it causes onPointerCancel not to fire on scroll.
	// https://bugs.webkit.org/show_bug.cgi?id=240917
	style.textContent = `
	@layer {
	[${PRESSABLE_ATTRIBUTE}] {
	touch-action: pan-x pan-y pinch-zoom;
	}
	}
	`.trim();
	ownerDocument.head.prepend(style);
	}, [domRef]);

This operation is blocked in browsers when a CSP directive is applied that does not allow style-src: unsafe-inline, which is generally the case.

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

I attempted to set up a repro but because of how codesandbox operates under the hood, attempting to configure a CSP directive with a strict style-src completely breaks the preview, unfortunately. Alternatively you can try this out locally by adding the following meta tag in the index.html:

<meta http-equiv="Content-Security-Policy" content="style-src 'self'" />

Version

1.9.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[devongovett]

Not really sure what other options we have if we cannot use inline <style> elements, and we cannot use inline style attributes (due to performance - see #8086).

We could put a try...catch around that and hope the user manually adds touch-action to their elements if they have a CSP. But that's not great.

We could require you to configure a nonce, or add a hash to your CSP that matches our style element. Also not great.

We could try importing this style rule as a CSS file so that it gets included at build time. But not all bundlers will have configured CSS importing support.

Are there any other options?

[devongovett]

It looks like CSSStyleSheet.insertRule is not subject to CSP, whereas inserting a <style> element is. document.adoptedStyleSheets and the CSSStyleSheet constructor are also fine. However, adoptedStyleSheets are placed after the document's existing stylesheets in their precedence, which is the opposite of what we want. We need our rule to have the lowest precedence possible. We could implement that like this:

// If there are stylesheets in the document, insert a new rule to declare
// our layer as the first rule so that it has the lowest possible precedence.
if (document.styleSheets.length) {
  document.styleSheets[0].insertRule('@layer react-aria-pressable', 0);
}

// Add a new stylesheet with our rule.
let style = new CSSStyleSheet();
style.replaceSync('@layer react-aria-pressable { [data-react-aria-pressable] { ... }}');
document.adoptedStyleSheets.push(style);

We cannot simply insert the [data-react-aria-presable] rule within the first stylesheet because the stylesheet may start with an @import rule, and rules other than @layer statement rules (without a block) cannot be inserted prior to @import. So just declaring the layer first, and then inserting a second stylesheet with the new rule into it should work.

Are there any other constraints or restrictions that would break this approach?

[devongovett]

One downside is that adoptedStyleSheets is only available in Safari 16.4 (2023) or later. Do we need to support older versions still?

[devongovett]

hmm, looks like insertRule won't work when document.styleSheets[0] is from a different origin...

[pleunv]

We could put a try...catch around that and hope the user manually adds touch-action to their elements if they have a CSP. But that's not great.

I'm guessing (can't verify right now) that this would still cause the CSP error which in itself is an annoyance as this would cause CSP reports ad infinitum. The thing about CSP errors is that you really want to go out of your way to avoid them at all costs 🙃

We could require you to configure a nonce, or add a hash to your CSP that matches our style element. Also not great.

Nonces should not be deterministic/static and instead be randomized on every request or they defeat the purpose, so that wouldn't work. There's also the hash approach but I don't think I've ever seen that used in practice due to additional complexity involved. It would probably fix the issue without any library input necessary but if you have a lot of chunks you would most likely run into HTTP header limits.

We could try importing this style rule as a CSS file so that it gets included at build time. But not all bundlers will have configured CSS importing support.

When it comes to UI libraries that already include opinionated styling I think that's probably the most reasonable approach. But in the case of react-aria or react-aria-components that's not what users would expect since it's basically BYOS(tyles). Honestly, I'm not really sure what a good approach could be. Personally I'd be perfectly fine adding the touch-action styles myself to a root stylesheet but I'm part of the small percentage of devs that have to worry about CSP constantly. For everyone else this would simply be additional friction.

One other approach I've seen is the one described in cristianbote/goober#471, which will use a predefined <style id="_goober" nonce> node if found (you can override the target id in userland with a global if so desired), and will create its own (non-nonce) node if not. It adds friction, but only to those that require CSP to work, which is a minority.

---

edit: If anyone else were to land here, you can work around this for now by pinning @react-aria/interactions to 3.25.0.

[snowystinger]

Linking up another nonce issue from a while ago LocalizedStringProvider: nonce parameter for Content Security Policy
This demonstrates one of the ways I believe Devon was suggesting. How to configure a nonce for yourself, non-deterministic.

[pleunv]

Harder to achieve here because there's no global provider necessary for things that are pressable, and you need a way to pass that nonce, also at runtime.

Runtime nonces are not necessarily impossible, vite for example has a cspNonce config option which it maps to a <meta property="csp-nonce" nonce="…" /> node in the build output which is then read and used for every injected <script nonce> or <style nonce>. If you configure the cspNonce with a placeholder value, your server can interpolate that into your index.html for every request to make sure it's randomized. It's a bit out there and there's probably a lot of unsafe, static nonces in use but there's not much else you can do. But the main problem even then remains: how do you pass that to every usePress()?

[raix]

@devongovett regarding

Not really sure what other options we have if we cannot use inline <style> elements, and we cannot use inline style attributes (due to performance - see #8086).

I get that if you have > 2.000 pressable items then there's a performance hit - but injecting style tags per pressable is also not without a cost. Imho libraries should not inject styles/scripts etc. and forcing teams downstream to use nonce etc. is a pretty huge cost.

Would it be possible to revert the work in 8086 and solve the initial performance issue in another way?

[nwidynski]

@raix The original reason for injecting a style wasn't performance related but rather to address #7993, which can only be solved by styling or injecting a meta tag.

[Roy-Prins-Ksyos]

We are running into CSP errors, but I see a potential solution here: fkhadra/react-toastify#1209 (comment) (provide an unstyled build, with separate CSS file)