I have a website with SSL (https instead of http). I am attempting to embed a widget that references files (js, css) from another domain. This other domain does not have SSL (http instead of https). As a result, I get an net::ERR_INSECURE_RESPONSE and the widget will not load.
How can I tell my site to allow the insecure content used by the widget?
You cannot tell a website to allow insecure content in the page as it is not the site that is blocking access to the scripts - it's the Browser.
When using SSL the browser puts a minimum level of security on the connection and ensures that no unencrypted connections are being made from the page. This stops any unencrypted connections being used to transmit data in the requests.
The simplest option I can think of to work around this is to host the scripts yourself on the domain that is secured by SSL. It may or may not be possible to edit the widget easily so it uses the locally hosted script instead of the ones from the non-https site.
Related
I am trying to embed or get the content of a https website and tried already some ways:
Iframe - is forbidden:
[Error] Refused to display 'https:// any url ?width=100?data=data' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
Get the content with tunnel - CONNECT request. Is not allowed.
Is there any way, how i can achieve this? I have read many old posts, that this is possible, but i think all of them are deprecated. Can i proxy the website somehow?
Thanks for your help!
The browser adheres to the directives stated in headers found on web resources response, for various security reasons (e.g., X-Frame-Options header that prevents loading in an iframe).
Old bypass methods that you might've found for these restrictions, are bound to be prevented eventually as they are considered security holes.
Notice that these are client-side restrictions. I believe that methods that involve a special client or a service that ignores these restricting headers, might be the right path to your problem. It all depends on what you're trying to achieve (Just showing the secured page content? Allowing the user to interact with the page? User can log-in to the secured website? etc.)
For example, a web service that fetches a page and serve it to the requesting client without the restricting headers.
This method isn't bulletproof - You might need to rewrite the resource's URLs in the HTML, deal with cookies, prevent javascript code from detecting if the page is in an iframe, etc.
So I deployed all of my React apps that are using an API. I am having problems sending this api and something block them and so my apps aren't working.
Note: all of my requests are cors so there is no problem with them.
github block my request
and this is link to the project in picture news-blog
The problem is that you're trying to fetch non-secure (http) content from a secure (https) site, which violates the site's Content-Security-Policy (CSP). This is an insecure behavior as far as modern browsers are concerned.
From MDN:
The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).
The right way of solving this would be to load the data from a secure source. For example, instead of fetching from http://newsapi.org/v2/everything, try https://newsapi.org/v2/everything (note the difference between http and https).
When setting up a site to run over https:// is there a way to stop the page from blocking any external css or javascript loaded from standard http://.
Some of the external files are under the same domain, so could be called via https://, but some are from another domain that has no secure connection available.
There shouldn't be. Such security measures are in place for good reason.
Even if you could remove them, doing so would be a very bad idea.
A man-in-the-middle attack would allow the JS or CSS (which can have embedded JS via various browser extensions) to be substituted.
This would allow an attacker to run any JS they liked on the page.
That JS could grab any data from the page and send it to the attacker.
The page would not be secure.
Copy the assets somewhere that you can access them over HTTPS.
You can rewrite your links without using scheme (like "//example.com/styles/mystyle.css").
See this questions for details
In case some external content is unavailable via HTTPS, you can make a HTTPS proxy on your server (with some sort of caching and ACL if you like).
I am designing a website that uses JavaScript Ajax XHR calls to retrieve dynamic data.
I have two C++ based applications that serve data on their own ports, and I have control of the ports that they use.
Dynamic Data is requested with HTTP 1.1 requests and data is returned with an HTTP 1.1 header, and I have control of the header data. Effectively, I have a custom HTTP server embedded in my dynamic data applications, so I have full control of both ends of the conversation.
If I choose two arbitrary ports to serve the dynamic data on, will the browser-based user have to open those ports on their firewall to allow the request from my web page?
For example, the web page would be served as www.mydomain.com/default.aspx, and within it, it would have Ajax XHR calls to make connections to www.mydomain.com:8080 and www.mydomain.com:8081 (or whatever port numbers are chosen).
Am I going to be blocked by the same origin policy?
Could I get away with using ports that are often open on firewalls, but not actively being served on my server?
What is the best way to work around this so that the user does not have to make firewall changes and does not get a cross domain warning? I'm hoping not to use iFrames if possible.
This topic may have been asked before, I have searched thoroughly but have not found anything that matches.
Wikipedia says you have to keep the same scheme, host and port but notes that some unnamed browsers do not enforce the port.
http://en.wikipedia.org/wiki/Same_origin_policy
The scheme is like HTTP:
The host name is like my.yahoo.com but there are some possiblilites to access any ???.yahoo.com in some browsers.
Port is pretty clear but notice that HTTP and HTTPS use different ports as the default.
This page is interesting:
http://www.w3.org/Security/wiki/Same_Origin_Policy
I have already working modal login dialog. The problem is that if the origin page is loaded via http I still want to pass credentials to server via https. And of course I want to do with as little rewriting of working code as it can be.
I cannot use JSONP for my case because login data is passed to server via POST AJAX request.
Any ideas?
The Same Origin Policy makes this impossible (at least in browsers which don't support cross domain XHR, which is enough).
(And since the host document is served over HTTP it is subject to interception and alteration on the wire, which would make the data vulnerable even if it was transported over SSL)
Just out of curiosity, why don't you force the user to a secure page to begin with? Why had a similar issue a while back, so now, we force the user to https (via redirect) as soon as they hit our page.
Please note that according to Same-origin policy it should be not possible, as you're trying to post non-secured credentials to secured page. And if login landing page is not using SSL, then an attacker could modify the page as it is sent to the user and change the form submission location or insert JavaScript which steals the username/password as it is typed. So login landing page must use SSL.
To illustrate, the following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".
Compared URL Outcome Reason
http://www.example.com/dir/page2.html Success Same protocol and host
http://www.example.com/dir2/other.html Success Same protocol and host
http://u:pass#www.example.com/x/o.html Success Same protocol and host
http://www.example.com:81/dir/other.html Failure Same protocol and host but different port
https://www.example.com/dir/other.html Failure Different protocol
http://en.example.com/dir/other.html Failure Different host
http://example.com/dir/other.html Failure Different host (exact match required)
http://v2.www.example.com/dir/other.html Failure Different host (exact match required)
http://www.example.com:80/dir/other.html Depends Port explicit. Depends on implementation in browser.
Unlike other browsers, Internet Explorer does not include the port in the calculation of the origin, using the Security Zone in its place.
How to relax the same-origin policy
In some circumstances the same-origin policy is too restrictive, posing problems for large websites that use multiple subdomains. Here are four techniques for relaxing it:
document.domain property,
Cross-Origin Resource Sharing,
Cross-document messaging,
JSONP,
If you really what to do that, it is possible, but you need to make sure that your public key certificate of your website has been verified by certification authority therefore it is valid.
If it is not, you may try to add your certificate to the white list in your web browser. Or try with different web browsers.
Alternatevely you can make sure that users are always on a secure pages when being presented with the login form or disable modal form for login forms.
Other workaround include adding rewrite rule by forwarding the non-secured traffic into ssl, e.g.
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# Force <front> to ssl for modal use of secure log in module.
RewriteRule http://www.example.net/^$ https://www.example.net [R=301,L]
See also:
Is posting from HTTP to HTTPS a bad practice?
Is it secure to submit from a HTTP form to HTTPS?
How to stop “secure and nonsecure items” warning on your site?
Getting Chrome to accept self-signed localhost certificate
Installing root certificate in Google Chrome