0

Problem: When a web server responds with the header

Content-Security-Policy: sandbox; default-src 'none'; img-src 'self'; style-src 'self';

this appears to cause Chromium to add the header

Sec-Fetch-Site: cross-site

when requesting the stylesheet from the same origin (and directory) as the containing html page. Instead, it is expected that the above CSP cause the browser to submit Sec-Fetch-Site: same-origin.

To reproduce using nginx+Chromium:

Add the following 4 lines to a location directive in an nginx config file:

add_header Content-Security-Policy "sandbox; default-src 'none'; img-src 'self'; style-src 'self';";
if ($http_sec_fetch_site = 'cross-site') {
  return 403;
}

Serve the following 2 static files report.html and report.css from that location.

report.html:

<!DOCTYPE html>
<html>
<head>
  <title>Report</title>
  <link rel="stylesheet" href="report.css">
</head>

<body>
  <h1>Report</h1>
</body>
</html>

and

report.css:

body { font-family: sans-serif }

Here are screenshots of both the report.html and subsequent report.css requests with the Developer tools Network window:

enter image description here

enter image description here

Note that the request for report.css is 403 Forbidden due to the incorrect Sec-Fetch-Site: cross-site header in the request.

Question: Why is Chromium submitting Sec-Fetch-Site: cross-site for a file that should be same-origin based on the given CSP which allows same-origin stylesheets?

Note: If it seems the issue is not being reproduced, verify that the following header is seen in the server response when report.html is requested:

Content-Security-Policy: sandbox; default-src 'none'; img-src 'self'; style-src 'self';

in order to set the CSP for the subsequent request for report.css.

Chromium Version 113.0.5672.126 (Official Build) Arch Linux (64-bit)

Matt
  • 20,108
  • 1
  • 57
  • 70
  • Are you sure the first request origin is also `http://localhost` and not `http://127.0.0.1`? – 273K Jun 06 '23 at 01:40
  • Yes, good question. Added screenshots for the `report.html` and `report.css` requests for verification. – Matt Jun 06 '23 at 14:09
  • Got similar issues with Safari: Reports `Sec-Fetch-Site: cross-site` on same-site – doublemax Jun 13 '23 at 20:35
  • @Matt were you able to find a solution for this. I have a case where I make a request to the exact same domain/path and Chrome decides to treat it as `cross-site` for some reason. – S Raghav Aug 21 '23 at 14:09
  • @SRaghav Yes, it requires replacing `sandbox;` in the CSP server response w/ `sandbox allow-same-origin;`. In case you were encountering this issue in Jenkins (as I was) they should have a fix for it in version 2.417. – Matt Aug 21 '23 at 14:23
  • Thanks @Matt. would you like to convert the above comment to an answer? Also in my case Chrome returned same-site/cross-site randomly and apparently it may be somehow related to the limit on header size on the server. – S Raghav Aug 22 '23 at 18:17

1 Answers1

0

This appears to be a misconfiguration on the server side. The header:

Content-Security-Policy: sandbox; default-src 'none'; img-src 'self'; style-src 'self';

is actually self-contradictory. The directives default-src 'none'; img-src 'self'; style-src 'self'; attempt to allow same-origin images and stylesheets. However, sandbox without allow-same-origin causes resources to fail the same-origin policy:

allow-same-origin

If this token is not used, the resource is treated as being from a special origin that always fails the same-origin policy (potentially preventing access to data storage/cookies and some JavaScript APIs).

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox

Thus the most secure adjustment to be made in order to keep sandbox and only allow images and stylesheets to be served from the same origin is to add allow-same-origin to the sandbox directive:

Content-Security-Policy: sandbox allow-same-origin; default-src 'none'; img-src 'self'; style-src 'self';

For anyone encountering this problem in Jenkins, a fix is expected to be released in Jenkins 2.417.

Other workarounds have recently been updated with this information on https://www.jenkins.io/doc/book/security/configuring-content-security-policy/

Matt
  • 20,108
  • 1
  • 57
  • 70