Same-origin request causes “Access-Control-Allow-Origin doesn’t match” error, though origin of course matches. Note: has CSP policy w/ “sandbox”

问题

When the exact same URL is being used in both by CORS and its web pages' URL, I still get the same error messages in my Firefox development console.

Browser console messages were:

Cross-Origin Request Blocked: \
  The Same Origin Policy disallows reading the remote resource \
  at https://egbert.net/fonts/fontawesome-webfont.woff2?v=4.7.0. \
  (Reason: CORS header ‘Access-Control-Allow-Origin’ does not \
  match ‘https://egbert.net’).

Header Settings, lighttpd Server

Access-Control-Allow-Origin: https://egbert.net
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range
Content-Security-Policy: \
    default-src 'none'; \
    base-uri 'none'; \
    script-src 'strict-dynamic'; \
    object-src 'none'; \
    style-src 'self'; \
    img-src https://egbert.net/favicon.ico https://egbert.net/images/ https://egbert.net/blog/articles/*/images/*.png data:; \
    media-src https://egbert.net/media/ data:; \
    frame-src https://egbert.net/frames/; \
    frame-ancestors 'self'; \
    worker-src 'self'; \
    child-src https://egbert.net/frames/; \
    font-src https://egbert.net/fonts/; \
    connect-src 'self' https://egbert.net/; \
    form-action 'none'; \
    require-trusted-types-for; \
    trusted-types template; \
    sandbox; \
    report-uri https://ssoseo1.report-uri.com/r/d/csp/enforce; \
    report-to endpoint-1; \
    upgrade-insecure-requests; \
    block-all-mixed-content;
Feature-Policy: accelerometer 'none'; camera 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; notifications 'none'; payment 'none'; push 'none'; sync-xhr 'none'; speaker 'none'; usb 'none'; vibrate 'none';
Referrer-Policy: no-referrer

HTML settings

  <link rel="stylesheet" href="https://egbert.net/css/m-dark.compiled.css">

CSS path

 */@font-face {
 font-family:'FontAwesome';
 src:url('../fonts/fontawesome-webfont.eot?v=4.7.0');
 src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.7.0') format('embedded-opentype'),
 url('../fonts/fontawesome-webfont.woff2?v=4.7.0') format('woff2'),
 url('../fonts/fontawesome-webfont.woff?v=4.7.0') format('woff'),
 url('../fonts/fontawesome-webfont.ttf?v=4.7.0') format('truetype'),
 url('../fonts/fontawesome-webfont.svg?v=4.7.0#fontawesomeregular') format('svg');
 font-weight:normal;
 font-style:normal
}

I've ensured that all font files are able to be downloaded by the same browser in separate tabs.

And what's weirder is that the error message implies "remote resource". They're the exact same URL.

No plugins were loaded, this is safe mode Firefox v73.0.1.

Update 1

It didn't change anything when I replaced the relative path ('../fonts') in the /@font-face of CSS with an absolute directory path.

Update 2

It didn't change anything when I added the scheme and domain (https://egbert.net/) to the /@font-face of CSS in front of the absolute directory path for a full-blown URL path.

This is not the same issue as:

• Why doesn’t Postman get a “No 'Access-Control-Allow-Origin' header is present on
• Font from origin has been blocked from loading by Cross-Origin Resource Sharing policy
• Firefox 'Cross-Origin Request Blocked' despite headers
• How to get a cross-origin resource sharing (CORS) post request working
• Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
• Same origin Policy and CORS (Cross-origin resource sharing)
• Socket.IO: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource
• google maps - Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
• Cross-Origin Request Blocked Microsoft Azure Function

回答1:

Replacing sandbox with sandbox allow-same-origin in the CSP policy will fix the problem.

Explanation:

The CORS problem the question describes is ultimately caused by the fact the browser is setting the origin value to null. So even though the Access-Control-Allow-Origin response header is set to the origin value that’d normally be expected — matching the URL shown in the browser address bar — it actually doesn’t match, due to the fact the browser has set the origin to null.

So you end up in what looks like a paradox, with the document seeming to not match its own origin.

The answer at https://stackoverflow.com/a/42242802/441757 outlines all cases where browsers set an origin to null. The specific cause of the case in the question arises from HTML spec text at https://html.spec.whatwg.org/multipage/#attr-iframe-sandbox which states that if sandbox is set:

…the content is treated as being from a unique origin, forms, scripts, and various potentially annoying APIs are disabled, links are prevented from targeting other browsing contexts, and plugins are secured. The allow-same-origin keyword causes the content to be treated as being from its real origin instead of forcing it into a unique origin.

So the bottom line is: Whenever you specify sandbox somewhere, in most cases you want to be specifying it with the allow-same-origin keyword included — in order to prevent surprising and hard-to-troubleshoot problems/side-effects such as the CORS problem described in the question.

来源：https://stackoverflow.com/questions/62289103/same-origin-request-causes-access-control-allow-origin-doesn-t-match-error-th