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

Cypress cannot test sites that implement SRI #2393

billyross opened this issue Aug 23, 2018 · 15 comments · Fixed by #5273

Cypress cannot test sites that implement SRI #2393

billyross opened this issue Aug 23, 2018 · 15 comments · Fixed by #5273


Copy link

billyross commented Aug 23, 2018

Current behavior:

When running Cypress against a site that implements SRI hashes, resources on the page are immediately blocked by Chrome and the page will not load due to invalid hashes. Disabling chromeWebSecurity does nothing. The following error appears in the Chrome DevTools console.

Failed to find a valid digest in the 'integrity' attribute for resource 'https://{my-domain}/assets/vendor-cdn-c9965fdc08cb8e112642197db5d0fc54.js' with computed SHA-256 integrity '2/Ht5YqBxaylA4fn2318LzUh4tFwjZH4WlN0lsHme9M='. The resource has been blocked.

Desired behavior:

The page of an SRI enabled site can load and not be blocked by Chrome. Either Cypress dynamically corrects the hash when it tampers with the file, or the chromeWebSecurity option actually disables SRI checks in Chrome.

Steps to reproduce:

  1. Start a Cypress instance and configure to point to a site that implements SRI checking (e.g.
  2. Implement a basic step that verifies anything on the page.
  3. Observe the test fail, the error message in the Chrome DevTools console and resources being unable to load.


Cypress 3.1.0
Fedora 28
Chrome 68.0.3440.106

Copy link

Confirmed, we have the same problem.

Copy link

billyross commented Sep 24, 2018

Is there any word on how this may be addressed or if there is any simple workaround for this?

This prevents us from running any test automation outside our own local machines and prevents us from using Cypress as part of our continuous delivery pipeline.

I'm happy to contribute a solution if a maintainer might point me in the right direction.

@jennifer-shehane jennifer-shehane added stage: ready for work The issue is reproducible and in scope type: bug labels Oct 25, 2018
Copy link

Bug Description

Test code to reproduce issue

it('fails to pass SRI', function () {

Console error on test above:

screen shot 2018-12-05 at 9 19 22 pm

Implementation Details for Cypress to Investigate

Specification for SRI:

When a browser encounters a <script> or element with an integrity attribute, before executing the script or before applying any stylesheet specified by the element, the browser must first compare the script or stylesheet to the expected hash given in the integrity value.

If the script or stylesheet doesn’t match its associated integrity value, the browser must refuse to execute the script or apply the stylesheet, and must instead return a network error indicating that fetching of that script or stylesheet failed.

Workaround Today

From w3c Spec

Note: On a failed integrity check, an error event is fired. Developers wishing to provide a canonical fallback resource (e.g., a resource not served from a CDN, perhaps from a secondary, trusted, but slower source) can catch this error event and provide an appropriate handler to replace the failed resource with a different one.

Today you will want to implement an SRI fallback within the application under test. You can turn this on at all times or only when running in Cypress by detecting your application is running within Cypress - this is up to you.

Copy link

Still happening for me.

Cypress package version: 3.1.5
Cypress binary version: 3.1.5

Copy link

rgoldfinger-quizlet commented Feb 20, 2019

I ran into this issue, seemingly out of the blue. I added the following to a script a the top of the document, and it seems to work:

if (window.Cypress) {
const MutationObserver = window.MutationObserver || window.WebKitMutationObserver;
if (MutationObserver) {
  new MutationObserver(function(mutations) {
    mutations.forEach(function(mutation) {
  }).observe(document, { childList: true, subtree: true });

const processNode = function(node) {
  const tagName = (node.tagName || '').toLowerCase();
  if (
    tagName === 'script'
    && node.integrity
  ) {
    node.onerror = function(e) {
	const fb = document.createElement(tagName);
	const parent = node.parentNode;
	if (node.src) fb.setAttribute('src', node.getAttribute('src'));

Copy link

Hi there! We are experiencing the same issue as above while testing our website.

Are there plans to fix this issue ? I noticed this was slated for sprint 15 but didn't get finished as part of it.
Also, are there any workarounds at the moment which don't involve changing the application under test?

Copy link

Hi, We have the same issue. Is there a plan for when this bug will be fixed in Cypress?

Copy link

Same issue here too!

Copy link

flotwig commented Nov 18, 2019

This is something that we will fix when #1467 is implemented.

There is a WIP PR for this: #5273

Copy link

Hi, we have the same issue.
Is it planned to merge this PR soon ?

Copy link

Have the same issue. Is there any plan to merge those pull requests soon?
Do you have an ETA?
This is really a big blocker for us.

Thanks for your attention,
Foursource QA lead

Copy link

flotwig commented Apr 9, 2020

Just added this in #5273. Once released, SRI integrity attributes in script tags <script type="text/javascript"> will be rewritten to cypress:stripped-integrity attributes.

<script type="text/javascript" integrity="foo">

becomes the below which will cause integrity checking to be skipped.

<script type="text/javascript" cypress:stripped-integrity="foo">

@flotwig flotwig assigned flotwig and unassigned brian-mann Apr 9, 2020
@cypress-bot cypress-bot bot added stage: needs review The PR code is done & tested, needs review and removed stage: ready for work The issue is reproducible and in scope labels May 8, 2020
@cypress-bot cypress-bot bot added stage: pending release There is a closed PR for this issue and removed stage: needs review The PR code is done & tested, needs review labels May 11, 2020
Copy link

cypress-bot bot commented May 11, 2020

The code for this is done in cypress-io/cypress#5273, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

Copy link

cypress-bot bot commented May 20, 2020

Released in 4.6.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v4.6.0, please open a new issue.

@cypress-bot cypress-bot bot removed the stage: pending release There is a closed PR for this issue label May 20, 2020
@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators May 20, 2020
Copy link

flotwig commented May 20, 2020

This fix is available starting in 4.6.0 as an experiment which you can access by setting this config option in your cypress.json or elsewhere:

	"experimentalSourceRewriting": true

The fix is experimental, so there may be some situations where the this is not fixed.

If you're still this issue while setting the experimentalSourceRewriting to true in 4.6.0 - open a new issue with a reproducible example + screenshots, etc - filling out our issue template.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging a pull request may close this issue.