Link to home
Start Free TrialLog in
Avatar of dlearman1
dlearman1Flag for United States of America

asked on

How can I resolve Firefox CORS security errors?

I'm trying to resolve a CORS issue. Firefox was updated to Firefox Developers Edition 95.0b12 and I'm suddenly confronted with two security errors;


Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///Volumes//Current/Modules/Card/source/_css/main.css.  (Reason: CORS request not http).

and
Security Error: Content at moz-nullprincipal:{481aa54d-8412-44b4-a56d-903c17f681a6} may not load or link to file:///Volumes/Current/Modules/Card/source/_css/fonts.css.


I've set the following Firefox variables to what seems to be the correct value.

privacy_file_unique_origin = false

content.cors.disable. = false
 network.cors_preflight.allow_client_cert = true


These settings didn't solve the problem.  Maybe one or more them are incorrect, or maybe there are other settings required. I'm not able to identify any additional Firefox variables that might possibly relate to the errors. The only other approach I'm thinking of, is to have our ISP set CORS headers on the server. This wasn't needed for previous FF versions.


I'm hoping a Firefox savvy expert can inform me of what's needed.


I probably should point out that the errors are generated by "same domain" local files during development in Sublime Text 3/Codekit 3/Firefox DE environment.


Avatar of lenamtl
lenamtl
Flag of Canada image

Hi,

The error is triggered because your files are not http but direct path try to change the path for both using http
 file:///Volumes//Current/Modules/Card/source/_css/main.css 

to something like this
<link rel="stylesheet" type="text/css" href="_css/main.css">

Open in new window

1) CORS policies are implemented at the server level.

2) There's no reason to have an CORS policy for local files, which relates to all URIs you've posted above.

3) Fix: Turn off all server level CORS policy definitions.
Another simple solution, if you must access files both locally + remotely relates to @lenamtl's comment.

Use protocol agnostic URLs.

So rather than https://foo.com/flarg.jpg or http://foo.com/flarg.jpg use a URI if /flarg.jpg with no protocol specifier.

This will also avoid both CORS problems + browser security blocks.

This also allows site to be renamed easily, as there's also no domain/host embedded in any URI.
Avatar of dlearman1

ASKER

I believe the issue comes up because I'm using "view-in-browser" extension to Sublime Text during development,oes  which I believe does bring CORS into the picture. Codekit does offer a virtual local server setup, which would probably solve the problem. But, during the initial Codekit setup I had trouble getting the feature to work, so I went with View-In-Browser option, as being quicker and simpler at the time.

All HTML pathnames are relative; i.e., <link rel="stylesheet" href="./_css/main.css" crossorigin="anonymous">

Firefox explains the browser policy changed back in v68: 

Local File Security in Firefox 68

 When a user opened a page using a file:/// URI in Firefox 67 and earlier,  the origin of the page was defined as the directory from which the page was opened.  Resources in the same directory and its subdirectories were treated as having the same  origin for purposes of the CORS same-origin rule.
    • In response to CVE-2019-11730,  Firefox 68 and later define the origin of a page opened using a file:///  URI as unique. Therefore, other resources in the same directory or its subdirectories no  longer satisfy the CORS same-origin rule. This new behavior is enabled by default using  the privacy.file_unique_origin preference. 

I thought changing the default value of privacy_file_unique_origin = false from true to false would fix the problem.

Thanks for your help.

ASKER CERTIFIED SOLUTION
Avatar of Scott Fell
Scott Fell
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Scott... You make  good point: Chrome behaves the same way. Looks like I will be calling my ISP to set headers and get Codekit builtin server running. Not sure why this problem didn't crop up before.