Cypress cannot test sites that implement SRI

[billyross]

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. https://github.com).
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.

Versions

Cypress 3.1.0
Fedora 28
Chrome 68.0.3440.106

[KittyGiraudel]

Confirmed, we have the same problem.

[billyross]

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]

Bug Description

Test code to reproduce issue

it('fails to pass SRI', function () {
  cy.visit('https://github.com')
})

Console error on test above:

Implementation Details for Cypress to Investigate

Specification for SRI: https://w3c.github.io/webappsec-subresource-integrity/

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.

[abu-wizata]

Still happening for me.

Cypress package version: 3.1.5
Cypress binary version: 3.1.5

[rgoldfinger-quizlet]

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) {
      mutation.addedNodes.forEach(processNode);
    });
  }).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'));
	parent.appendChild(fb);
	node.remove();
    };
  }
};
}

[rahul2906]

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?
Thanks!

[shyammeduri]

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

[ryan-mulrooney]

Same issue here too!

[flotwig]

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

There is a WIP PR for this: #5273

[gagagast]

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

[castrorogerio]

Hello,
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

[flotwig]

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">

[cypress-bot]

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.

[cypress-bot]

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.

[flotwig]

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.