We Keep Coding

ERR_BLOCKED_BY_RESPONSE.NotSameOrigin CORS Policy JavaScript

This is the image URL I got from an api
https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d
this is my HTML
<img src="https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d">
I see the image when I go to the URL, directly through the browser. But it is not showing up on my website
When I checked the Debug Console I get this error.
Failed to load resource: net::ERR_BLOCKED_BY_RESPONSE.NotSameOrigin
when I googled this the problem might be due to some CORS Policy issue.
How to load this image on my website without messing with the policy and stuff...?
<img src="https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d">

this should fix it
helmet({
crossOriginResourcePolicy: false,
})

I was getting the same error while fetching images from different api.
I fixed the error by adding crossorigin="anonymous" in image tag.
Just add crossorigin="anonymous" in your img tag like:
<img crossorigin="anonymous" src="https://example.com/image.jpg">
this should resolve the error.

You need to set cross-origin-resource-policy: "cross-origin".
If you're using helmet in your Express App.
try this:
app.use(helmet.crossOriginResourcePolicy({ policy: "cross-origin" }));
For more information read any of these CORP and HelmetJS

It's a CORS issue, and can only be solved server-side.
The response has the header cross-origin-resource-policy: same-origin which tells us that the resource can be accessed only by the same origin (when it's called inside a html page, using modern browsers)
You might host the image in another place to use it.
Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

There is a great proxy out there used just for this - bypassing a CORS block. The source code is here: https://github.com/Rob--W/cors-anywhere, and you would use it like this:
https://cors-anywhere.herokuapp.com/https://scontent-jnb1-1.cdninstagram.com/v/t51.2885-15/e15/242204298_1728375270686500_5634415857798350440_n.jpg?_nc_ht=scontent-jnb1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=3O8LpuGJsdUAX_E1Dxz&edm=AHlfZHwBAAAA&ccb=7-4&oh=0a22779e81f47ddb84155f98f6f5f75f&oe=6148F26D&_nc_sid=21929d
basically just adding the CORS-Anywhere URL before your actual image URL.
If you get rate limited by that website, try https://circumvent-cors.herokuapp.com/, this is one that I have deployed from the GitHub source code, no modifications and I do not think it should rate limit you.
The image you provided has expired, so if you were to give me an example of what API you were using to get the image, or another image blocked by CORS that maybe doesn't expire, I could properly test this and maybe find another answer, if this one doesn't work.
Cheers!

You can use helemt package
const helmet = require("helmet");
app.use(
helmet({
crossOriginResourcePolicy: false,
})
);

This way can fix ERR_BLOCKED_BY_RESPONSE. (by https://stackoverflow.com/a/71878799/12117869)
this should fix it
helmet({
crossOriginResourcePolicy: false,
})
this
BTW,if happen ERR_BLOCKED_BY_RESPONSE issue, Maybe the Reason :
It's a chrome bug. It will happen on the chrome 80 - 85 version. but it was fixed on the 86 version.
[CORS] Set preflight request mode correctly
CORS preflight request mode was set to kNoCors up until now, and with
cross-origin-embedder-policy: require-corp CORS preflights fail unless
a CORP header is attached. Fix the bug.
same issue :
https://bugs.chromium.org/p/chromium/issues/detail?id=1116990#c21
google fix commit: https://chromium.googlesource.com/chromium/src.git/+/ed257e2b7df1d3bdcd95d8687bcbd786bc48e717

Unable to load FontAwesome Fonts using Script tag or External CSS [duplicate]

just noticed on several websites that the font awesome icons aren's showing in Google Chrome. The console shows the following error:
Font from origin 'http://cdn.keywest.life' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://www.keywest.life' is therefore not
allowed access.
I found the exact same issue on several other sites. This can be easily fixed by replacing the own CDN reference with:
//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css
-however, this is not the solution, just a workaround. I would love to know the reason and the right solution.
(the cause is this: the website is using it's own CDN, provided by MaxCDN and has the reference to the font awesome fonts and these are not loaded by Chrome, if you are loading the same resource from the Bootstrapcdn resource -mentioned above- it works)
here is a n example of the issue (in the menu and the social icons in footer: http://www.keywestnight.com/fantasy-fest )
Thanks for any help/explanatioon!

Here is the working method to allow access from all domains for webfonts:
# Allow access from all domains for webfonts.
# Alternatively you could only whitelist your
# subdomains like "subdomain.example.com".
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>

The problem isn't with the CSS file, it has to do with how the font file is served. The font-awesome.min.css file has lines like
#font-face{font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0')
format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0')
format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0')
format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal}
which cause the browser to request an appropriate font file (eot, woff, ttf or svg) from the same server as the CSS file. This is logical and correct.
However, when the browser requests that font file from cdn.keywest.life, it reads the headers for a Access-Control-Allow-Origin header and doesn't find one so it gives that error message. (This seems like a browser bug to me because it's coming from the same server as the CSS file).
Instead, when you use maxcdn.bootstrapcdn.com the response includes the Access-Control-Allow-Origin:* header and the browser accepts this font file. If your cdn server included this header then it would work too.
If you have an Apache server, see this answer: Font-awesome not properly displaying on Firefox / how to vend via CDN?

This issue of accessing font-awesome assets has been a problem for many people without a comprehensive explanation and resolution to the problem.
What is CORS:
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use. A user agent makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port than the one from which the current document originated.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
The Problem:
The problem stems from how the font-awesome fonts are loaded.
#font-face{
font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal
}
The fonts are loaded via the stylesheet (CSS). The situation we have here is:
The Solution:
While CORS rules have been created on your file storage e.g. S3, and access to the resource has been given to the domain in question, when CDN tries to load the fonts specified in the CSS the origin/domain specified when loading these fonts is that of the CDN but no CORS access has given to the CDN domain.
Create a CORS rule for the CDN domain.

I use a CDN that doesn't allow me to modify its response, so I modified font-awesome.min.css, replacing relative path with absolute path and it worked.

None of the answers worked for me, I had to create an edge rule on maxcnd back office (which change config file on you zone)
More info here
https://www.maxcdn.com/one/tutorial/edge-rules-recipes/
https://www.maxcdn.com/one/tutorial/create-a-rule/

The solution to this is to use another cdn for fontawesome.
https://www.cdnpkg.com/font-awesome/5.11.0

If you're like me and using the official WordPress Font Awesome plugin, you'll want to go into settings and switch from "Use a CDN" to "Use a Kit".

Cannot find solutions to "No 'Access-Control-Allow-Origin' header" with CouchDB

I am currently trying to get some documents from CouchDB with AngularJS. My server is running locally on localhost:5984, ans I cannot access it from Brackets' renderer.
The error is the following one:
XMLHttpRequest cannot load http://127.0.0.1:5984/generator/_all_docs. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:54142' is therefore not allowed access.
This error sounds well known and a real pain to deal with, and I already tried methods from this question and searched some other sources, but nothing seems to work. My CouchDB server looks like it is well configurated, with the following members inside its configuration properties:
[cors]
credentials = false
headers = accept, authorization, content-type, origin, referer, cache-control, x-requested-with
methods = GET,PUT,POST,HEAD,DELETE
origins = http://localhost
[httpd]
enable_cors = true
I do not need credentials, at the moment, to access my data, I just need to access them from AngularJS. I would like to know what did I do / where did I go wrong, and if ever I did something wrong with my configuration or anything, how to finally allow my application to access those data. I know this is a CORS problem but as far as I tried, I found no way of doing so.
Thank you in advance !
EDIT
I am using CouchDB 1.6.1 and AngularJS, with Windows Seven. I did not try on other web browsers, but the problem currently happens with Google Chrome.

Okay, so I solved the problem.
The solutions proposed in this topic are correct and solved the problem, but you must not fail while editing your fail. I'll explain:
When I first tried, I forgot a 's' in 'origins', and then suppressed my mistake it from the control panel. The control panel just suppresses the value, and not the original tag. When I tried again, this time by editing manually the local.ini file, I found this line:
origin =
Which was, I guess, interfering with the good interpretation of the rest of the file.
When I removed it, everything went smoothly
Problem solved, thanks to The Head Rush which pushed me on the way to victory with his commentary.

Multiple 'X-Frame-Options' headers with conflicting values

Update: This works for IE but Chrome is still throwing this error.
I am attempting to i-frame a site I own by another site I own. Here is error message I am getting in the JS console on Chrome:
Multiple 'X-Frame-Options' headers with conflicting values ('AllowAll, SAMEORIGIN, AllowAll') encountered when loading 'http://subdomain.mysite.com:8080/Dir/'. Falling back to 'DENY'.
Refused to display 'http://subdomain.mysite.com:8080/Dir/' in a frame because it set 'X-Frame-Options' to 'AllowAll, SAMEORIGIN, AllowAll'.
I did a search for SAMEORIGIN everywhere I am not setting this ANYWHERE.
The main site is www.mysite.com and the other site is subdomain.mysite.com. Obviously same-origin policies keep me from doing this.
So i have set the X-Frame-Options header on my subdomain.mysite.com to "AllowAll". On the begin-request method i have added this:
HttpContext.Current.Response.Headers.Remove("X-Frame-Options");
HttpContext.Current.Response.AddHeader("X-Frame-Options", "AllowAll");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
on the page level I have added this:
<meta name="x-frame-options" content="allowall" />
In Javascript i have added this:
<script type="text/javascript">
document.domain = "mysite.com";
</script>
I am running out of things to try... Thank you in advance for your assistance.

In my case it was the anti-forgery token that was adding the header. Adding this in Application_Start stopped it from adding it:
AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
I then added the X-Frame-Options in the web.config as I needed the whole site to be in an IFrame.

Turns out MVC4 adds the header by itself (unsolicited). The only way to get around this was to explicitly remove the header.
Response.Headers.Remove("X-Frame-Options");
There may be a way to convince MVC4 not to do this but it did not service in my scores of Google queries.

Some further detail to to Mike the Tike's answer, this is added to the application_start method in global.asax.cs, where you'll need the using directive system.web.helpers

IIS might be adding a second header after yours (you can see this by pressing F12 for Developer Tools in Chrome, attempt to load the page, then click Network, and right-click on the failed page to copy the response headers to have a look).
To stop IIS from adding the header:
Run IIS Manager
Select your website
Double click the HTTP Response Headers for the application (or on older IIS, right click on the website, click Properties, then HTTP Headers)
Then you can override or remove the extra header

Resource interpreted as other but transferred with MIME type text/javascript?

I keep getting "Resource interpreted as other but transferred with MIME type text/javascript.", but everything seems to be working fine. This only seems to be happening in Safari 4 on my Mac.
I was advised to add "meta http-equiv="content-script-type" content="text/javascript" to the header, although that did nothing.

The most common way to get the error is with the following code:
<img src="" class="blah" />
A blank url is a shortcut for the current page url, so a duplicate request is made which returns content type html. The browser is expecting an image, but instead gets html.

i received this error due tu a missing element which a jquery plugin tried to call via js var btnChange i commented the none needed (and non existent) images out and the warning (google chrome dev tools) was fixed:
$(mopSliderName+" .sliderCaseRight").css({backgroundImage:"url("+btnChange.src+")"});

The (webkit-based) browser is issuing a warning that it has decided to ignore the mimetype provided by the webserver - in this case text/javascript - and is applying a different mimetype - in this case "other".
It's a warning which users can typically ignore, but a developer might find useful when looking for clues to a problem. For this example it might explain why some javascript wasn't being executed.

Your web server is sending the content with a certain MIME type. For example, a PNG image would be sent with the HTTP header Content-type: image/png. Configure your web server or script to send the proper content type.

It does cause issues if your are calling a javascript that adds functionality, it is likely to fail, as it does for me. No real answers yet.

I was getting this error due to a script with bad permissions bringing up a HTTP 403 error. I gave it read and execute rights across the board and it worked.

There is a setting for the Apache MIME module where it misses adding the type for javascript, to resolve it, simply open the .htaccess file OR httpd.conf file, add the following lines
<IfModule mod_mime.c>
AddType text/javascript .js
</IfModule>
Restart the apache server, issue will be resolved.