Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subresource Integrity (SRI) not working #66901

Closed
darthmaim opened this issue Jun 15, 2024 · 3 comments · Fixed by #73891
Closed

Subresource Integrity (SRI) not working #66901

darthmaim opened this issue Jun 15, 2024 · 3 comments · Fixed by #73891
Labels
bug Issue was opened via the bug report template. locked

Comments

@darthmaim
Copy link
Contributor

darthmaim commented Jun 15, 2024

Link to the code that reproduces this issue

https://github.com/darthmaim-reproductions/vercel-next.js-66901

To Reproduce

  1. run npm run build && npm run start
  2. Open http://localhost:3000 in a browser and inspect the source code

Current vs. Expected behavior

Current
No integrity attribute present on any <script>

Expected
integrity attribute added to <script>

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Thu Jan 11 04:09:03 UTC 2024
  Available memory (MB): 15953
  Available CPU cores: 8
Binaries:
  Node: 20.7.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: 6.11.0
Relevant Packages:
  next: 15.0.0-canary.32 // Latest available version is detected (15.0.0-canary.32).
  eslint-config-next: N/A
  react: 19.0.0-rc.0
  react-dom: 19.0.0-rc.0
  typescript: 5.3.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next start (local), Other (Deployed)

Additional context

The only change to the reproduction template was adding this config to next.config.mjs:

  experimental: {
    sri: { algorithm: 'sha256' }
  }

There is a test (https://github.com/vercel/next.js/tree/canary/test/production/app-dir/subresource-integrity) that is supposed to test this, which has the same config as my reproduction repository, but I was not able to get SRI working.

There is a .next/server/subresource-integrity-manifest.json file generated which contains all the correct hashes.

@darthmaim darthmaim added the bug Issue was opened via the bug report template. label Jun 15, 2024
@darthmaim
Copy link
Contributor Author

Adding export const runtime = 'edge'; to the page will correctly output integrity attributes, so I guess the issue is only with the node.js runtime and related to the following comment in the test:

    // Currently webpack chunks loaded via flight runtime do not get integrity
    // hashes. This was previously unobservable in this test because these scripts
    // are inserted by the webpack runtime and immediately removed from the document.
    // However with the advent of preinitialization of chunks used during SSR there are
    // some script tags for flight loaded chunks that will be part of the initial HTML
    // but do not have integrity hashes. Flight does not currently support a way to
    // provide integrity hashes for these chunks. When this is addressed in React upstream
    // we can revisit this tests assertions and start to ensure it actually applies to
    // all SSR'd scripts. For now we will look for known entrypoint scripts and assume
    // everything else in the <head> is part of flight loaded chunks

I wonder if this is fixed in react by now (the comment was added Aug 30, 2023 in #54752), and if not, what is missing in react, and if there is a tracking issue in the react repo.

@oliviertassinari
Copy link
Contributor

oliviertassinari commented Sep 19, 2024

Now supported in Safari 18 https://webkit.org/blog/15865/webkit-features-in-safari-18-0/

WebKit for Safari 18.0 adds support for subresource integrity in imported module scripts, which gives cryptographic assurances about the integrity of contents of externally-hosted module scripts.

Copy link
Contributor

github-actions bot commented Jan 1, 2025

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot added the locked label Jan 1, 2025
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 1, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue was opened via the bug report template. locked
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants