Figure out how to load site with Content-Security-Policy without stripping header #1030

bahmutov · 2017-12-07T01:56:30Z

Feature proposal

Currently we strip "content-security-policy" when loading documents.

allow rewriting this header in a plugin to only strip what is preventing Cypress from iframing the site

By passing through CSP, and possibly tweaking it, we should be able to add security testing to Cypress.

is my CSP setup correctly?
are my violations reported?
can I load code / style / object from given domain or will it throw an error?

Observation

if we run content security policy with report-only mode, everything is working and no problems are reported when running the test itself (and any inline scripts are executed, but reported)

using helmet to generate CSP, we can do nothing and just run in report mode.

// basically do not allow inline scripts
app.use(
  helmet.contentSecurityPolicy({
    directives: {
      scriptSrc: ["'self'"],
      reportUri: '/report-violation'
    },
    reportOnly: true
  })
)

In the following page we catch two errors:

<!DOCTYPE html>
<html lang="en">

<head>
  <title></title>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
</head>

<body>
  <p>a few scripts from files index.0.js etc</p>
  <script src="index.0.js"></script>
  <script src="index.1.js"></script>
  <script src="index.2.js"></script>
  <p>an inline script with alert below</p>
  <script>alert('abc')</script>
</body>

</html>

the Cypress injection code <head> <script type='text/javascript'> document.domain = 'localhost'; var Cypress = window.Cypress ...
inline alert call

The server receives the following calls from the browser

Example app listening on port 3000!
CSP Violation:  { 'csp-report': 
   { 'document-uri': 'http://localhost:3000/',
     referrer: 'http://localhost:3000/__/',
     'violated-directive': 'script-src \'self\'',
     'effective-directive': 'script-src',
     'original-policy': 'script-src \'self\'; report-uri /report-violation',
     'blocked-uri': 'inline',
     'line-number': 4,
     'status-code': 200 } }
CSP Violation:  { 'csp-report': 
   { 'document-uri': 'http://localhost:3000/',
     referrer: 'http://localhost:3000/__/',
     'violated-directive': 'script-src \'self\'',
     'effective-directive': 'script-src',
     'original-policy': 'script-src \'self\'; report-uri /report-violation',
     'blocked-uri': 'inline',
     'line-number': 16,
     'status-code': 200 } }

Which leads me to conclude that we should inject our Cypress top level script from external url and not inline (where it might conflict)

The text was updated successfully, but these errors were encountered:

bahmutov · 2017-12-07T14:14:17Z

allow customizing and editing content-security-policy header
move injection script into separate file instead of being inline
or
serve injection script inline but with a nonce value to allow specific script. This is tricky because the plugin editing content-security-policy header would have to know the nonce values.

bahmutov · 2017-12-07T14:16:53Z

BTW, it would be nice to stub report violation calls, but since they are not XHR, we would need to #687 to do this. Then it would be sweet!

jamime · 2019-07-19T13:57:06Z

We were hoping to test that there were no CSP violations. The way this is currently implemented prevents us from doing so.

tlolkema · 2020-02-06T16:14:14Z

Any update on this one?

mdantonio · 2020-09-11T19:35:39Z

It would be a very useful improvement

flotwig · 2020-09-25T20:39:21Z

We had some additional discussion for the actual implementation of this improvement here: #7936 (review)

Now it just needs to be implemented.

bahmutov · 2020-12-02T17:59:19Z

Extra context: https://glebbahmutov.com/blog/testing-csp-almost/

DJSdev · 2021-04-14T20:12:06Z

+1 to this. It would be nice to test for CSP violations

Co-authored-by: Zach Bloomquist <git@chary.us> Closes #1030

AtofStryker · 2023-01-12T18:30:14Z

Hi @pgoforth. First I want to say thank you for the work you put in on getting #24760. Unfortunately, we have to revert the changes due to some issues we found that I described in the revert request #25445. We are hoping to revisit this soon and find a way to make CSP as compatible as possible with Cypress. We are still discussing options, but for right now we need to revert the change to prevent us from breaking existing users. I hope you understand and once again thank you for the large effort on the contribution!

pgoforth · 2023-04-10T22:12:19Z

@AtofStryker Thanks for these notes. It appears that the course of action should be:
1.) Figure out why the CSP is overriding Content-Security-Policy=upgrade-insecure-requests (or other CSP headers in this style) instead of augmenting it. This seems like an instance where I can start by writing tests against this specific type of CSP header and work my way out to testing against all valid CSP headers in an exhaustive way
2.) The frame-ancestors issue should be much more straightforward. There will have to be either:

A selective stripping of that CSP header...which would allow Cypress to run
An augmentation that would remove 'none' and add the src Cypress is being served from...which could prove difficult because it's likely based on environment and may not be available at runtime.

EDIT
@AtofStryker @flotwig
After going through everything i have the following solutions:
1.) The RegExp was indeed incorrect for detecting CSP directives that did not contain values. I have fixed the RegExp and have added a test loop against all valid CSP directives, and arrays of valid values for each (including undefined) which results in ~250 permutation tests. Those are all passing now with the new RegExp.

2.) I have added a excludeCSPDirectives array that contains any individual directives that Cypress wants to strip in order to maintain functionality (frame-ancestors being the only one currently).

The thought occurred to me while doing this that people have probably written a lot of tests assuming that Cypress is stripping CSP headers. Headers like upgrade-insecure-requests is an example where your test environment could be hosting local files over an insecure protocol, but your response headers could be sending the upgrade-insecure-requests directive. This results in a situation where Cypress is now no longer stripping that header, and your tests are failing, but the actual behavior is correct because your local files over http: are not actually available over https.

That brought me to the following idea which could be executed in two ways:
1.) Opt-In for CSP Header stripping (default true to maintain parity with previous Cypress versions)
2.) Allow customer defined/maintained excludeCSPDirectives and/or includeCSPDirectives array (default to includeCSPDirectives=[] which would {again} maintain parity with previous Cypress versions)

EDIT 2
I have opened a PR that uses a new config option stripCspDirectives that defaults to true. This allows the behavior to be opt-in, meaning that by default, Cypress will still strip all CSP headers from the response. This should avoid any accidental consequences from this feature. I am unsure if I implemented the new config option correctly, so any eyes on that part of the PR would be very helpful.

Addresses [cypress-io#1030](cypress-io#1030)

bahmutov added the type: feature New feature that does not currently exist label Dec 7, 2017

JakeChampion mentioned this issue Jan 11, 2018

Pa11y 5.0.0-beta.5 fails to run on pages with strict Content-Security-Policy. pa11y/pa11y#364

Closed

jennifer-shehane added the stage: needs investigating Someone from Cypress needs to look at this label Sep 14, 2018

jennifer-shehane mentioned this issue May 2, 2019

Cypress setup not running on my other machines. #4088

Closed

flotwig mentioned this issue Sep 25, 2020

fix(proxy): omit CSP report only header #7936

Merged

coryhouse mentioned this issue May 13, 2022

Automated Testing coryhouse/reactjsconsulting#6

Open

Betree mentioned this issue Jun 7, 2022

Enforce Content Security Policy in cypress tests opencollective/opencollective#5624

Open

pgoforth mentioned this issue Nov 21, 2022

feat: Do not strip CSP headers from HTTPResponse #24760

Merged

2 tasks

cypress-bot bot added stage: needs review The PR code is done & tested, needs review and removed stage: needs investigating Someone from Cypress needs to look at this labels Nov 21, 2022

flotwig closed this as completed in #24760 Jan 11, 2023

flotwig pushed a commit that referenced this issue Jan 11, 2023

feat: Do not strip CSP headers from HTTPResponse (#24760)

0472bb9

Co-authored-by: Zach Bloomquist <git@chary.us> Closes #1030

AtofStryker pushed a commit that referenced this issue Jan 11, 2023

feat: Do not strip CSP headers from HTTPResponse (#24760)

61ceb84

Co-authored-by: Zach Bloomquist <git@chary.us> Closes #1030

AtofStryker mentioned this issue Jan 12, 2023

fix: revert CSP header and script-src addition #25445

Merged

4 tasks

AtofStryker reopened this Jan 12, 2023

nagash77 assigned mjhenkes Apr 11, 2023

pgoforth mentioned this issue Apr 11, 2023

feat: Selective CSP header stripping from HTTPResponse #26483

Merged

3 tasks

pgoforth added a commit to pgoforth/cypress that referenced this issue Apr 14, 2023

feat: Selective CSP header directive stripping from HTTPResponse

3d41cea

Addresses [cypress-io#1030](cypress-io#1030)

mjhenkes assigned mschile and unassigned mjhenkes Apr 25, 2023

mschile removed their assignment May 9, 2023

mjhenkes closed this as completed in #26483 Jun 14, 2023

crfrolik mentioned this issue Jul 13, 2023

Cypress 12.15 broke the ability to run Web Workers in cypress tests #27298

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Figure out how to load site with Content-Security-Policy without stripping header #1030

Figure out how to load site with Content-Security-Policy without stripping header #1030

bahmutov commented Dec 7, 2017

bahmutov commented Dec 7, 2017 •

edited

Loading

bahmutov commented Dec 7, 2017

jamime commented Jul 19, 2019

tlolkema commented Feb 6, 2020

mdantonio commented Sep 11, 2020

flotwig commented Sep 25, 2020

bahmutov commented Dec 2, 2020

DJSdev commented Apr 14, 2021

AtofStryker commented Jan 12, 2023

pgoforth commented Apr 10, 2023 •

edited

Loading

Figure out how to load site with Content-Security-Policy without stripping header #1030

Figure out how to load site with Content-Security-Policy without stripping header #1030

Comments

bahmutov commented Dec 7, 2017

Feature proposal

Observation

bahmutov commented Dec 7, 2017 • edited Loading

bahmutov commented Dec 7, 2017

jamime commented Jul 19, 2019

tlolkema commented Feb 6, 2020

mdantonio commented Sep 11, 2020

flotwig commented Sep 25, 2020

bahmutov commented Dec 2, 2020

DJSdev commented Apr 14, 2021

AtofStryker commented Jan 12, 2023

pgoforth commented Apr 10, 2023 • edited Loading

bahmutov commented Dec 7, 2017 •

edited

Loading

pgoforth commented Apr 10, 2023 •

edited

Loading