You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Arbitrary scripts I didn't consent to are injected into my application. I did not expect this nor do should I trust an arbitrary script, or the CDN it comes from--especially without the subresource integrity check.
Expected Behavior
This is a three-parter moving out philosophically:
The integrity attribute should be added to all CDN script requests. 5+ years after Subresource integrity for DASHJS and HLS CDN files? #527 was closed, the issue is not addressed. Reasons why integrity should exist are well known, and the bug mentioned it could be done but never was implemented as far as I can tell.
Runtime script injections should be opt-in. When I include a library into my project, I do not want random scripts to appear without my consent. This is not the same as being able to look through the package.lock and see if there are security issues. The documentation explains how to opt-out of this behavior, not opt-in. I believe the documentation should say to add hls.js to the project, or how to enable the automatic runtime script injection (e.g. <ReactPlayer automaticScriptInjection={true} />). I think runtime script inject, while well-intentioned, is trying too hard to be "easy" while not considering simplicity or security.
CDNs maybe shouldn't be used at all. I'm assuming hls.js, et.al. are not already compiled in as requirements to reduce the size of the project 👍, however ReactPlayer could just throw an error for missing library linking to the documentation on how these libraries are added. This would be a simple solution that would leave the project with less lines of code, no or less need to manually manage the versioning of these scripts compatible versions, and providing better security.
I am open to being wrong in the sense that no. 3 does not align with some usability goals of the project. If that's true, I'm likely better off building this in myself and not using ReactPlayer project, however I do think 1 is a requirement and 2 is a good idea.
Steps to Reproduce
I've come into a fresh project and I'm seeing this in the <head> injected from ReactPlayer:
This whole issue is prompted by me trying to enumerate which domains were needed to support for CSP (content security policy). I do not want CDNs to have my users' data metadata wherever possible nor the stability or security issues of when these CDNs go down or get hacked. Seeing scripts injected by a React component at runtime was a unwelcome surprise. I can move forward easily by now including my own hls.js, but I disagree the current setup and default behavior.
This discussion was converted from issue #1404 on April 20, 2024 12:43.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Current Behavior
Arbitrary scripts I didn't consent to are injected into my application. I did not expect this nor do should I trust an arbitrary script, or the CDN it comes from--especially without the subresource integrity check.
Expected Behavior
This is a three-parter moving out philosophically:
integrityattribute should be added to all CDN script requests. 5+ years after Subresource integrity for DASHJS and HLS CDN files? #527 was closed, the issue is not addressed. Reasons whyintegrityshould exist are well known, and the bug mentioned it could be done but never was implemented as far as I can tell.<ReactPlayer automaticScriptInjection={true} />). I think runtime script inject, while well-intentioned, is trying too hard to be "easy" while not considering simplicity or security.I am open to being wrong in the sense that no. 3 does not align with some usability goals of the project. If that's true, I'm likely better off building this in myself and not using ReactPlayer project, however I do think 1 is a requirement and 2 is a good idea.
Steps to Reproduce
I've come into a fresh project and I'm seeing this in the
<head>injected from ReactPlayer:Environment
Other Information
This whole issue is prompted by me trying to enumerate which domains were needed to support for CSP (content security policy). I do not want CDNs to have my users' data metadata wherever possible nor the stability or security issues of when these CDNs go down or get hacked. Seeing scripts injected by a React component at runtime was a unwelcome surprise. I can move forward easily by now including my own hls.js, but I disagree the current setup and default behavior.
Beta Was this translation helpful? Give feedback.
All reactions