I have a web API hosted on a server. Also, I have an angular website that uses this API to perform transactions. So, my website is constantly communicating with the web API.
when I run my website on the host server (using localhost instead of IP address) it works just fine, but if I use the IP address instead of localhost, then I have the Access-Control-Allow-Origin error.
Also, when I try to access my website outside the host server using the IP address obviously, then I have the same error:
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://IPADDRESS' is therefore not allowed access. The response had HTTP status code 404.
Is there any configuration on IIS am I missing? Because on API web.config code I have the following:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
I'd really appreciate any help on this.
Related
Error:
Access to XMLHttpRequest at 'http://localhost:7078/websync.ashx?token=1&src=js&AspxAutoDetectCookieSupport=1' from origin 'http://localhost:4200' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains multiple values 'http://localhost:4200, *', but only one is allowed.
Goal:
Be able to send a variable from SiteA to SiteB.
(SiteB hosts an iframe that appears on SiteA. SiteA hosts the angular and asp.net webapi. SiteB is the chatserver)
These are the current settings. Do I need both the web.config and the global.asax.cs file? What specifically is causing the error above from my setup?
It is my understanding that this happens when it's set in more than one place. Is having it in the web.config and the asax.cs causing that?
I've been through a lot of documentation about HttpResponse as well as CORS but feel like i'm missing a few pieces here:
SiteA\Web.config:
<add name="Access-Control-Allow-Origin" value="*" />
SiteA\Global.asax.cs:
response.AddHeader("Access-Control-Allow-Headers", "access-control-allow-origin,accept,x-api-applicationid,content-type,authorization");
SiteB\Web.config:
<add name="Access-Control-Allow-Origin" value="*" />
I believe you are missing the Access-Control-Allow-Methods in the response from the server. While not required for CORS requests in general, I believe that header is required for preflight-type CORS requests, e.g. https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
Add this header to your web.config:
<add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" /> //limit this to methods you want to allow CORS on
You should see that your preflight requests are sending an Access-Control-Request-Method which should be one of the methods allowed by Access-Control-Allow-Methods for the preflight to work.
we have written an ASP.NET core 2.2 web application which basically exposes a few web api controllers and we have used the ResponseCachingMiddleware in order to implement a server side response cache in our middleware pipeline.
We followed this Microsoft guide and we decided to add the HTTP response header Vary so that each response from our application includes the following header: Vary: Accept-Encoding, Accept-Charset.
Doing so, as explained in the guide linked above, is needed in order for the response cache to honor the client request headers so that the cached responses are used if and only if they are compatible with the client request.
Testing with postman I noticed that, when deploying the app in Azure (we used a standard Azure App Service to do so), the Vary response header is not what I would expect: it seems that Azure itself adds the value Accept-Encoding so that the value for the Vary header is set as Accept-Encoding, Accept-Charset,Accept-Encoding (this is a combination of the value set by our application and the value that, I suppose, is automatically added by Azure).
That said I have a couple of questions:
is the extra value Accept-Encoding really added by the azure host ?
is there a way to customize the HTTP headers added by the Azure host (if any) ?
is the value Accept-Encoding, Accept-Charset,Accept-Encoding a valid value for the Vary header ? is it going to work as expected even if we have a value repeated twice ?
Hosting ASP .NET Core on Azure App Service (a Windows one) still uses IIS as outlined here. So you should be able to control your headers by adding web.config to your project.
Here is an example of what that would look like and the link to the docs,
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false" /> <!-- Removes ASP.NET version header. Not needed for Ghost running in iisnode -->
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" /> <!-- Removes Server header in IIS10 or later and also in Azure Web Apps -->
</security>
<httpProtocol>
<customHeaders>
<clear /> <!-- Gets rid of the other unwanted headers -->
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
<redirectHeaders>
<clear />
</redirectHeaders>
</httpProtocol>
I created a WebService in C#. All GET methods are working without any problems.
Now I need to provide some POST methods. When calling it via C# it works without any problems. Then I tried to write a small html page with JavaScript to call my methods. But there I get a CORS error ("Preflight channel did not succeed").
I already added the following part to my web.config file:
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="*" />
<add name="Access-Control-Allow-Methods" value="*" />
</customHeaders>
Sadly it is still not working. What am I doing wrong?
So what you have here is not really a valid way to handle CORS requests. The problem is that this will add the CORS headers to all responses, but browsers will use an OPTIONS request in order to check for CORS headers. This would work if you also implement OPTIONS requests for all of your API end points.
The better option is to use one of the CORS frameworks, such as this one: Enabling Cross-Origin Requests in ASP.NET Web API 2 for ASP.NET WebAPI 2. This type of framework will intercept the OPTIONS request for you and supply the appropriate response without the need for you to manually create 2 routes per endpoint.
I am trying to wrap a login section of our page in an iframe which has been created with SSL and display it on several pages across our companies website (kind of like a login widget).
However I keep getting an error on the page rendering the iframe indicating that:
Refused to display in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.`
The login widget and webpages that I want to display it on are hosted under the same domain, is this an issue?
I have searched around and nothing seems to be able to avoid this problem. Does anyone have a solution to this issue?
<iframe sandbox="allow-same-origin allow-forms allow-scripts" src="https://<sitename>/loginiframewidget.aspx"></iframe>
At the moment these are what I have in my web.config
<httpProtocol>
<customHeaders>
<add name="access-control-allow-headers" value="content-type" />
<!--<add name="Access-Control-Allow-Origin" value="*" />-->
<add name="Content-Security-Policy" value="frame-ancestors 'self' mysite.com.au"/>
<add name="X-Frame-Options" value="ALLOWALL"/>
</customHeaders>
</httpProtocol>
And the headers that appear in Chrome Dev Tools on the page are:
There are security issues with this implementation anyway.
The first is that you can't be sure the content of the unencrypted page hasn't been altered on transmission and has pointed the src of the iframe elsewhere.
The second is that even if a user logs in with SSL, their session ID in the cookie is being sent in the clear and is easy to spoof.
Would you consider running the entire site in SSL? These days servers cope with this better than you'd think, and you wouldn't need iframes any more.
Try setting the frame-ancestors directive of the Content-Security-Policy header, and the X-Frame-Option header for older versions of IE.
http://caniuse.com/#feat=contentsecuritypolicy
You can add these through IIS, or add them into your web.config file:
<system.webServer>
...
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="frame-ancestors 'self' mywebsite.com" />
<add name="X-Frame-Options" value="ALLOW-FROM http://mywebsite.com" />
</customHeaders>
</httpProtocol>
...
</system.webServer>
The headers should now be sent down to the browser:
No means big No, you just can't do it, you can't access SSL resources on non SSL page, and is your client willing to expose everything on internet? Allowing frame options will still not work because browser will not allow you to cross SSL boundaries.
HTTP is not at all secure, this is the reason, every site in google is now under SSL, because non SSL content can be altered by ISPs and Firewalls, in fact ISPs, Firewalls and other routers are continuously injecting scripts on page to monitor traffic.
Explain your client that today running an authenticated session under non HTTPS is equivalent to locking doors of home but leaving all windows open !!!.
With keep alive, SSL negotiation any way happens only once and performance is very negligible, you can improve site speed by outsourcing CDN to CloudFront or any other CDN with their subdomain SSL.
OAuth - But Recommended only under SSL anyway
You can implement your own OAuth Provider and use it to distribute OAuth tokens that can be used to validate in your website at server side. Your site can use secondary tokens issued by OAuth provider to validate user and you can redirect users to OAuth Provider which can run under SSL. This way, you can allow users to do limited non secure things under authentication on non SSL pages. Just like how you can use Facebook/Google login etc under non SSL sites as well.
I have removed the x-powered-by using <httpProtocol>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
<remove name="Server" />
</customHeaders>
</httpProtocol>
This hides the X-Powered-By but the server (IIS info ) is still not getting removed
It would be good if there is a way where I can remove all the info in the Response Header
How can i do it?
I believe you need UrlScan to remove the IIS info.
The particular setting you need to configure is: RemoveServerHeader
By default, a Web server returns a header that identifies what Web
server software it is running in all responses. This can increase the
server vulnerability because an attacker can determine that a server
is running IIS and then attack known IIS problems, instead of trying
to attack an IIS server by using exploits that are designed for other
Web servers. By default, this option is set to 0. If you set the
RemoveServerHeader option to 1, you prevent your server from sending
the header that identifies it as an IIS server. If you set
RemoveServerHeader to 0, this header is still sent.