Cross-Origin Resource Sharing (CORS)

Destry · 2019-03-03 09:31:55

Being under the impression that ‘origin’ is an official-like term for a domain (e.g. domain.tld), I wanted to find a place to kind of prove that, and I think I found it well-enough here, the WHATWG’s 7.5 Origin spec.

But then I started focusing on what it was saying there about cross-origin resource sharing — and what MDN says too — plus the fact I’m using a number of subdomains in relation to my origin domain, and I’m thinking, Huh, maybe there’s header biz here I need to be paying attention to and fixing.

Now, I’m not developing applications or pulling content from origin to a subdomain, but I do use a single contact form (at the origin) for all other sites to share, by pointing a reader to that location and using an ‘External link’ popup hover. Same for policies, style guide declaration, etc.

But maybe there’s some technical handshaking I need to put in place too via the headers, or something, just to make it official and avoid any "SecurityError" DOMException nonsense in the browsers? Anyone work with this before that might offer some clarity forward?

jakob · 2019-03-03 09:56:54

Someone else can probably give a more qualified response, but maybe the infos in HTML5Boilerplate htaccess file can help. The file is commented with links to further information sources.

Destry · 2019-03-03 10:57:53

Wow, that is an great resource. Thanks, J. There’s some things in there I would have liked using a long time ago, like the ‘clickjacking’ prevention and a few others. And I hadn’t thought about single-sourcing fonts and images… Definitely doing that for reusable /assets stuff.

This means the strategy is to always have the origin up and running first and foremost, however; a new assurance procedure.

While the recommendation there is duly noted for adding such rules in the Apache httpd.conf file, I think it’s more practical from an ease-of-access standpoint to use .htaccess. I’ll just have to trim it down to the essentials. At least until I get oriented with o2switch’s setup.

But looks like I’m always running with some file mods, one way or the other.

Destry · 2019-03-03 11:18:09

Unfortunately I don’t understand it very well.

Let’s take this seemingly basic example with fonts fetching

The notion is, I put my fonts on the origin domain, say at domain.tld/assets/fonts. The boilerplate (beginning line 46) says to put this in the .htaccess:

# Allow cross-origin access to web fonts.

<IfModule mod_headers.c>
    <FilesMatch "\.(eot|otf|tt[cf]|woff2?)$">
        Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

Does that go in the .htaccess of the origin, the subdomain site, or both?

Hmm.. now that I think about it, maybe it just goes in the subdomain, because that Access-Control-Allow-Origin part is probably the key that communicates “the origin must be common at source and receiving domains”?

But what if you owned domain1.tld and domain2.tld (i.e. not subdomain on the same origin)… Wouldn’t that be possible? I’m not doing that, but I’m just trying to understand how the code knows what is an allowed connection and what isn’t.

Last edited by Destry (2019-03-03 11:27:02)

Destry · 2019-03-03 11:33:34

Destry wrote #316832:

Let’s take this seemingly basic example with fonts fetching

‘Sites can explicitly allow cross-site loading of font data using the Access-Control-Allow-Origin HTTP header.’

That actually sounds like it’s saying to set the rules at the origin, and that seems logical since it has the files of interest. So it set’s the permission handshake?

But then wouldn’t any site on the web be able to link up?

This handshake permission part is what’s eluding me. Or maybe there isn’t one? It’s either on and open to all who may know, or it’s not on?

Destry · 2019-03-03 11:40:58

Another question, so I might bug you less on this matter…

How would one test whether the fetch was set correctly? Where/how would you look for that "SecurityError" DOMException?

Destry · 2019-03-04 08:08:29

I’m beginning to think I don’t need to worry about this because I’m not using any API, that I’m aware of. But maybe someone smarter can decipher this example :

For example, if Example Bank’s Web site, hosted at bank.example.com, tries to examine the DOM of Example Charity’s Web site, hosted at charity.example.org, a “SecurityError” DOMException will be raised.

What do they mean by ‘examine’?
What if all I am doing is linking from one domain to the contact form at another? Is that against the laws of the web protocol gods?

And it also seems from that example that an ‘origin’ is not what I thought they were. They’re not the root of a domain, in fact, but basically any separate website whether a sub-domain or not.

And this seems to suggest that it’s all moot anyway if you’re on a shared hosted environment, which I’m pretty sure I am:

Note: The document.domain attribute is used to enable pages on different hosts of a domain to access each other’s DOMs.

Warning: Do not use the document.domain attribute when using shared hosting. If an untrusted third party is able to host an HTTP server at the same IP address but on a different port, then the same-origin protection that normally protects two different sites on the same host will fail, as the ports are ignored when comparing origins after the document.domain attribute has been used.

Zzz

None of you have ever mused over this stuff before?

philwareham · 2019-03-04 09:48:25

Unless you are sharing assets/feeds/APIs across domains, you don’t really need to state CORS headers, since in compliant browsers (e.g. Firefox) it is assumed the resource is restricted to the parent domain unless a CORS header is present and states otherwise.

For example, web fonts are by default restricted by CORS, so if you wanted to serve those fonts from a single domain across to some other domains, you’d need to add a CORS header. We do that in this forum in fact because the font is stored on textpattern.com (as we don’t want users to go the .com page, download fonts, then go to forum and then have to download the same fonts again from subdomain and waste their bandwidth and time).

The header goes on the domain where the asset is served from, not the domain where it is served to. So the process is:

server gets a request from example2.com to use an asset from example1.com.
server checks that the CORS header on example1.com allows this.
If yes, serves the asset, if no, blocks the request.

I can’t find a definitive list of what types of resource are blocked by default – definitely AJAX and fonts are. I’d assume most resources – apart from images and other embedded media such as audio and video – are blocked.

Destry · 2019-03-04 10:32:35

Thanks, Phil.

Fonts are one definite use in my case, stored at the root/origin domain to be used at sub-domains too. So I guess that would qualify, and the relevant rules from the file Jakob shared would be prudent.

I guess that also means, since I’m on a shared server, that anyone else on the shared server could grab the files too, but the odds are unlikely anyone will, me figures.

It’s not a paid-for typeface — free to the world — but it’s not generally on one’s computer either.

And I think I see better now about just linking to content (a contact form, for example), which has no relevance here, in fact. It’s more about referencing a file source to use. The fog is clearing.

philwareham · 2019-03-04 10:44:21

Destry wrote #316851:

I guess that also means, since I’m on a shared server, that anyone else on the shared server could grab the files too, but the odds are unlikely anyone will, me figures.

It’s by domain, not server, so you should be safe if you restrict the domains you want to allow, for example:

# Allow restricted cross-origin access to web fonts.
<FilesMatch "\.(eot|otf|tt[cf]|woff2?)$">
    <IfModule mod_headers.c>
        SetEnvIf Origin "http(s)?://(www\.)?(example1.com|staging.example1.com|development1.example.com|otherdomain.example|dev02.otherdomain.example)$" AccessControlAllowOrigin=$0
        Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
        Header merge Vary Origin
    </IfModule>
</FilesMatch>

FYI the example you listed from H5BP is a wildcard entry, meaning the font resources would be shared to everyone. My example limits to only the domains/subdomains you state.

Textpattern CMS

Textpattern CMS support forum

#1 2019-03-03 09:31:55