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

Question

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:

Try changing your Content-Security-Policy response header to have `sandbox allow-same-origin` rather than just `sandbox` — or else, completely drop the `sandbox` directive from your CSP policy. Is there a particular reason why you added it? What exactly are you using it to try to prevent? The reason you need to add `allow-same-origin` is, without that added, if you specify `sandbox`, then browsers are required to set the origin of your document to `null`. And I think that’s what’s causing your font request to fail: The browser won’t blocks the request because the document origin is null. — sideshowbarker, Jun 10 '20 at 02:34
Details on when browsers set an origin to null are at https://stackoverflow.com/a/42242802/441757. https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox, explains the specific condition in his case: when `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”* — sideshowbarker, Jun 10 '20 at 02:43
@sideshowbarker, THIS IS IT!!!! Problem SOLVED! replacing 'sandbox' with 'sandbox allow-same-origin' in the CSP portion of HTTP header did THAT trick. Oh my, oh my, what a relief. 10 days of agony solved in ... seconds. As to why I am doing this security thing, it is a proof of concept that one can go 'uber' and get it to work, of which you did. Thank you so very much! — John Greene, Jun 10 '20 at 12:36
Updated OP to show CSP portion of HTTP-RESPONSE header. Please post answer for my wonderful acceptance, @sideshowbarker — John Greene, Jun 10 '20 at 12:44
A bug report over at Mozilla for an enhancement request to FIX the wording of the error message so that others may not fall into this trap. https://bugzilla.mozilla.org/show_bug.cgi?id=1644503 — John Greene, Jun 10 '20 at 12:53

sideshowbarker · Accepted Answer · 2022-01-16T22:38:15.530

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.

There seems to be an update... `sandbox` attribute is for iframe. "Only" for iframe? What about the main/parent DOM context/page? https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox — John Greene, Oct 08 '20 at 19:01
Basically, this HTTP specification is a "TRI-STATE" logic mechanism. We start at 'unknown', then flip to either 'allowed' or 'disallowed'. And 'unknown' is defaulted to 'not-allowed'? Something like that? — John Greene, Jan 16 '22 at 10:14
Specifying `sandbox` is like specifying “disallow everything” or “deny all”. So if you have `sandbox` specified but you want to allow specific things, you need to use the `allow-*` to add back the specific things you want to allow. — sideshowbarker, Jan 16 '22 at 22:44
Just to be clear, specifying `sandbox` alone without any suboptions will block everything. Whereas, not specifying anything `sandbox` defaults to everything allowable. — John Greene, Mar 12 '23 at 23:28

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

Header Settings, lighttpd Server

CSS path

Update 1

Update 2

1 Answers1

Linked