What are potential drawbacks of loading an external widget over HTTP when my website is accessible over HTTPS ?
<!-- https://www.example.com -->
<script src="http://www.external-source.com/widget.js"></script>
Are any warnings going to be displayed to the user? Any way to suppress them? Will this script be loaded in all times?
EDIT:
What happens when we load an external JS over HTTPS, but with non-commercial certificate? Will the warnings be shown?
Loading a script with plain (insecure) http inside a secure (https) site completely defeats the security of the site. Therefore most modern browsers will simply refuse to load the script without any warnings and without giving the user a way to enforce the loading.
Related
There are some javaScripts which is essential to load a graph in my web page. But the problem is all of the scripts blocked by my browser.Therefore I need to give permission from my browser to execute those scripts. But I need to resolve that from from my code level.
http://code.highcharts.com/modules/no-data-to-display.js
I download the relevent js files from highcharts and set the source for that js files. But the problem is when I run from My netbeans there will be no issues. But when I try to run it by deploy in a server these scripts will not be run. And I need to give permission from my browser. Are there any solution to resolve the problem from code level?
Because your page is HTTPS, the scripts it loads should be loaded via HTTPS. The one you've listed (http://code.highcharts.com/modules/no-data-to-display.js) is available via HTTPS (https://code.highcharts.com/modules/no-data-to-display.js). If the others aren't, then perhaps copy them locally and serve them through your HTTPS server.
One common technique here (provided you know the resources area available via both HTTP and HTTPS) is to use a protocl-relative URL for the scripts:
<script src="//code.highcharts.com/modules/no-data-to-display.js"></script>
In a page loaded via HTTPS, that will be https://..., but on a page loaded via HTTP, it'll be http://... (and this is standardized behavior, not an undocumented hack).
Here are the links to the page in question:
http version
https version
The https version of the page doesn't render the video embedded on the top of the article. I inspected the source code and found that HTTPs is missing an entire block of code, as you can see in the images below:
I wonder how this happens? Isn't http(s) just the protocol to communicate with the server? Why do I get different code by using different protocols?
From Chrome Developer Toolkit:
The page at 'https://www.eyeviewdigital.com/blog/eyeview-launches-addressable-tv-ads-with-cablevision-dish-programmatic-tv-w-clypd-and-wideorbit/' was loaded over HTTPS, but requested an insecure script 'http://pshared.5min.com/Scripts/PlayerSeed.js?sid=281&width=480&height=401&playList=519141523'. This request has been blocked; the content must be served over HTTPS.
You typically need to load your content in either http or https. Mixing them together results in the error above.
On line 252 replace
http://pshared.5min.com/Scripts/PlayerSeed.js?sid=281&width=480&height=401&playList=519141523
with
https://delivery.vidible.tv/aol?sid=281&width=480&height=401&playList=519141523.js
Long story short the content was never loaded so the page looked different.
You're right that there should be no difference based on http/https as it is just the transport layer. There must be something in the server's code that is producing the html, that behaves differently based on the url used to make the request. I suggest you provide information on the web server code to help analyse the issue.
This is most likely caused because you're loading elements from insecure sources. Google Chrome for example, loading an image over http when your page is loaded over https can result in the image not loading at all. This is all for security purposes, of course. Just go through all of your code and make sure all sources are accessed through secure https so that they load in properly.
I'm quite new to bookmarklets. I'm trying to load a javascript file from my own server/domain by using the following bookmarklet/javascript code:
javascript:(function(){s=document.createElement('script');
s.type='text/javascript';
s.src='http://www.test.com/js.js?v='+parseInt(Math.random()*99999999);
document.body.appendChild(s);})();
This code works nicely (js.js is loaded and executed) when i press the bookmarklet on my firefox toolbar when visiting pages on the test.com domain.
But when i go to google.com or any other sites and press the bookmarklet button the http://www.test.com/js.js isn't even loaded (looking in server log)
I know about cross domain restrictions but don't they apply to ajax request and related things?
This has nothing to do with CORS
You are loading unsafe content (http) in a secure page (https). Mixed content on secure pages don't work. You need to serve your script with https as well
I have a secure (HTTPS) web app which needs to load a custom stylesheet from an insecure (HTTP) origin (customer's own website). This is blocked by modern browsers, however I need a workaround because:
1) I cannot ask my customers to host their custom stylesheets on HTTPS. They don't have the know-how and some of them have policies about what hosts and regions stuff can be hosted in (ironically, not about HTTPS though).
2) I obviously cannot ask the end user to disable security features in their browser.
I tried, loading stylesheets using <style>#import url(...);</style>, I tried creating an iframe with src="about:blank" and loading the stylesheet from within there, I tried XHR and fetch (but that will require CORS to be enabled on the remote host which I cannot reasonably expect).
Short of creating a secure proxy that will serve any stylesheet on the web, is there any other workaround I'm missing here?
Any sorcery to get my page to load a cross-origin stylesheet over HTTP?
If there was a workaround to be able to load insecure resources on secure pages, it should be patched ASAP. No, the policy exists because without HTTPS on all resources, you're not truly secured. Any HTTP connection may be intercepted and man-in-the-middled, so the page is not secure. Even something minor like a stylesheet can undermine that security.
You will have to serve the stylesheet over HTTPS, and if your customers can't do it, you will have to do it for them.
Is it perhaps possible to download their CSS server-side, and serve it to your own users via HTTPS?
I tried to do the same thing with a webapp that i builded. The real issue with what you want to do is the browser. It doesnt allow a secure connection to be spoiled by an insecure connection, especially when you want to inject something on that page. I used this technic:
document.createElement("link")
to inject. And with browser security being a big issue, I don't think you'll find a hack..
Best of luck! :)
I have a web application which has root html and this html (say index.html) loads some java script. This application is accessible through https and I want to load one java script which is exposed over http.
https://mydomain/index.html contains this line of code:
<script src="http://unsecure/custom.js" type="text/javascript"/>
When I try to run my application thorugh IDE everything works fine but problem happens when I bundle my application in war file and run it.
It fails to load the included java script by saying:
[blocked] The page at https: //mydomain/ ran insecure content from http: //unsecure/custom.js.
Is there any way to load this unsecure javascript or do I need to publish this unsecure javascript through a secure way and then access it (can change this included java script protocol from http to https)?
All content which is used by a site, which is accessed through HTTPS, must use HTTPS as well, otherwise you get this warning.
The reason for this: If not all content of a HTTPS site is HTTPS, the browser can't tell that the site is "secure" and therefore gives the user a warning.
You could either do below two things:
1) Download it over your local and create war. Then you would be using relative path.
2) Place in some https location.
If its a third party library and you do not have control on the frequent changes that would happen for this library, you could ask them to put it in https. Majority of the times hosted JS would be both http and https too.