Search code examples
javascriptfirefoxcorssandboxcontent-security-policy

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:

Solution

  • 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 browser having set 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: 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 requirements at https://html.spec.whatwg.org/multipage/#attr-iframe-sandbox which say, if sandbox is set:

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