To give some context, this is an Electron app, loading the index.html using file://
It seems like the content security policy is contracting itself:
Refused to connect to 'https://o944978.ingest.sentry.io/api/5893671/envelope/?sentry_key=0a6134a5d89d40c4954c6144b0e63c64&sentry_version=7' because it violates the following Content Security Policy directive: "default-src 'unsafe-inline' 'self' 'unsafe-eval' data: *.sentry.io *.cloudfront.net". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.
That URL clearly matches the wildcard *.sentry.io, or am I missing something?
I'm gonna answer myself here: You can't.
The 2 options are: disabling web security or starting a static web server.
It's difficult to know without seeing your implementation, but here are some suggestions:
Test using only *.sentry.io in the CSP at first; add domains as they appear in the errors. This idea is to come up with the minimal CSP that makes it work.
My CSP has "data:" at the end of the list. I don't remember why, but I think there was a reason...
Make sure you are closing each list with a semicolon ";"
(Answered as a post because I don't have enough reputation to comment)
The *.sentry.io source is recomended by docs.sentry.io docs and it definitely should work even you put it in default-src directive instead of connect-src one. CSP supports wilcard to specify a subdomains.
The only reason why CSP can block allowed sources is the presence of browser plugins like NoScript/uBlock and so on.
Suggestion trying to help:
Could you try also explicitly setting the connect-src with
connect-src sentry.io https://*.sentry.io *.sentry.io;
(and maybe other needed hosts)
Do you still get this error?
I'm trying to implement .NET SignalR (v2.4.0) to some of our project but,
SignalR $.connection.hub.start method give CSP error, we don't want to use 'unsafe-inline' CSP directive for scripts because of security conserns
Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src
Is there any method or configuration to solve this problem?
Best Regards
You may need to implement CORS depending on where you are loading resources from.
https://learn.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/hubs-api-guide-javascript-client#crossdomain
The violation message in the Chrome console:
Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src
means you have inline scripts kind of <script>...</script> on the page.
You can allow such scripts by using 'nonce-value' or 'hash-value' tokens. Alternatively you can move this script to external file, in this case it falls under script-src 'self' permission.
I have a mvc web application ,I have configure content security policy as
<add name="Content-Security-Policy" value="default-src 'self';script-src 'self' 'unsafe-inline' 'unsafe-eval' ;style-src 'self' 'unsafe-inline' ;img-src 'self';font-src 'self' ; "/>
which work well in all browser including IE,CHROME,MOZILLA.
I am using lots of inline jquery/javascript code in cshtml page.
but my security team has fail my security of the web application and they wanted us to remove 'unsafe-inline' 'unsafe-eval'
After i remove unsafe-inline and unsafe-eval application only work in IE ,But not working in chrome and mozilla. is there any work around to acheive the above without 'unsafe-inline' 'unsafe-eval'
You can try using NWebSec library to support you in the process of making your MVC application CSP compliant. See the documentation here.
You can take the help of NWebSec TagHelpers to make your scripts CSP compliant with nonce. See the information here.
A good read on this topic is here.
You can use a ASP.Net MVC Boilerplate Template by Rehan Saeed to understand the CSP. It has the NWebSec already implemented.
CSP is (as today 21/03/2018) not fully supported by IE (more information here https://caniuse.com/#search=csp).
Apparently your application is not CSP-compliant and this is why it does not run in a browser that implements CSP (like Chrome or Firefox).
In my ASP.NET MVC 2 app, I have the following lines:
Response.Cache.SetMaxAge(TimeSpan.FromDays(90));
Response.Cache.SetETag(lastWriteTime.Value.Ticks.ToString());
Using Fiddler to trace the HTTP streams, I can see:
ETag: 634473035667000000
in the Response Headers when running under IIS7, but when I'm running under the Visual Studio 2010 web server, this header just... disappears. Whether I set it via Response.Cache.SetETag() or via Response.AppendHeader("ETag", etag), it just never gets returned.
Is this a "feature" of the IIS web server? Is there some config setting I've missed? It's going to make testing cache invalidation a bit fiddly if I have to attach to the IIS process to be able to debug anything...
EDIT: It also appears that despite calling Response.Cache.SetCacheability(HttpCacheability.Public), VS/Cassini always returns resources with HTTP Cache-Control set to "private"... does that help?
The ETag will be suppressed if you use HttpCacheability.Private.
You can find more information on Why does HttpCacheability.Private suppress ETags?
If you change it to HttpCacheability.ServerAndPrivate it should work
Simple - it's Cassini.
Cassini isn't meant to be a production server, but is there to facilitate debugging (which is why it overrides caching too - after all if you recompile and rerun would you want your new code not touched because a page is cached?)
If you want your debugging to work as it would in IIS then IISExpress is where you should be going... there's no attach problem there as it will spin up a real instance of IIS, but in your own user context.
I have an IIS7.5 web-site, on Windows Server 2008, with an ASP.NET MVC2 web-site deployed to it. The website was built in Visual Studio 2008, targeting .NET 3.5, and IIS 5.1 has been successfully configured to run it as well, for local testing.
However, whenever I try and navigate to a page running in IIS7, I get a 404 error.
I have checked the following things:
There is no corresponding 404 log entry in IIS logs.
Actually, there are 404 entries in the IIS log.
The application pool for the web-site is set to use the Integrated pipeline.
The "customErrors" mode is set to off.
.NET 3.5 SP1 is installed
ASP.NET MVC 2 is installed
I've used MVC Diagnostics to confirm all MVC DLLs are being found.
ASP.NET is enabled in IIS, which we've demonstrated by running the MVC Diagnostics page.
KB 2023146 did highlight that HTTP Redirection was off, so we've turned it on, but no joy.
EDIT
Ok, so we've installed the world's simplest MVC application (the one which is created when you create a new MVC2 project in Visual Studio), and we are still getting 404s on any page we try and access - e.g.
<my_server>/Home/About will generate a 404.
Any ideas will be greatly appreciated!
This is quite often caused by the following missing from the web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
Do you have a problem with just 1 page or the whole site is not working?
A) 1 page
You can use RouteDebugger to verify if the route is matched correctly
B) Whole site
I assume you're using Windows Server - check if ASP.NET is enabled in IIS - it's disabled by default, I believe.
You can use MvcDiagnostics page to check if all dlls are deployed properly.
Are you running in IIS7 integrated mode? Classic mode of IIS7 does not automatically map extensionless URLs to ASP.NET (much like IIS6)
Make sure your Web.config tag is configured correctly.
We finally nailed this issue by exporting the IIS configuration of a working server, and comparing it to ours.
It was a really obscure setting which had been changed from the default.
IIS ROOT → request Filtering → Filename Extensions Tab → Edit Feature Settings → Allow unlisted file name extensions
This should be ticked.
This can be set at the IIS level, or the site-level.
Glad that fixed your problem. Others researching this issue should take note of the extensionless URL hotfix: http://support.microsoft.com/kb/980368
If none of the other solutions here solved your issue, check that you have the
Global.asax
file in your website. This solved the issue for me.
Checkout if KB 2023146 applies to your scenario. Also try requesting directly a controller action: /yoursitename/home/index
Apparently this can have many different causes.
For us, the problem was that the DNS entry was configured for two IP addresses, but the IIS configuration would only listen to one of them. So we got unpredictable results, sometimes it would work, sometimes a few files (css, etc) would not load, and sometimes the whole page would not load.
For me it was all about installing .NET Framework 4.6.1 on the server (my app was targeting that version)
You'll also get this if your bindings aren't correct. If you don't have www or a subdomain it'll return a 404.
I had this problem when running my MVC4 site with an app pool set to ASP.NET 4.0 and the Classic pipeline, even though the extension handlers were set in my web.config and were showing correctly in IIS. The site worked in Integrated Pipeline so I knew it was a configuration issue, but I couldn't nail it down. I finally found that ASP.NET 4 was disabled for the server in the ISAPI and CGI Restrictions settings. I enabled ASP.NET 4.0 and it worked.
In addition to checking if you're running in integrated pipeline mode, make sure your application pool is set to use .NET! I recently ran into this problem, and when I went in to check the app pool settings, I found that somehow it had been set to "No Managed Code." Whoops!
My Hosting company fixed this for me by doing this (I removed the original password value of course).
<system.webServer>
<security>
<authentication>
<anonymousAuthentication password="<password>" />
</authentication>
</security>
</system.webServer>
Typically I encounter this issue when there is a Routing problem. I compare a working vs non-working to resolve it.
Today however I accidentially created a Virtual Directory in IIS.
It has to be an Application, right click on the Virtual Directory (with a folder icon) -> Convert to Application:
Don't use runAllManagedModulesForAllRequests. You want to let IIS handle resources such as images.
<system.webServer> <!-- Rather do NOT use this -->
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Instead add the MVC routing module
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
</system.webServer>