29
votes

At some point recently Chrome has stopped showing data loaded via jsonp with the error

[blocked] The page at https://user.example.com/category/12345 ran insecure content from http://livedata.example.com/Data.svc/jsonp/GetData?category=12345&callback=_jsp&_1346417951424=.

It still works fine on all other browsers, and has been confirmed on several different computers running Chrome.

The only mention I've seen of this problem before is when the page was served from one of Google's own domains (a security feature for Google Apps I guess?), is this something that has been enabled on all domains now in a recent version of Chrome?

Ideally we don't want to have to enable https on our livedata subdomain because of the extra server load it would cause, the data is all publicly available so there's no pressing need to encrypt it.

2

2 Answers

19
votes

It definitely should block it - it's insecure and breaks the promise of HTTPS.

A JSONP resource fetch is done by creating a <script> resource pointing at the target. That means the target server can run any JavaScript it likes on the including page, and hence any man-in-the-middle can inject arbitrary script into a supposedly-HTTPS-protected page (eg adding a keylogger, or completely replacing the page content). An HTTPS page with a <script> coming from HTTP is no more secure than a plain HTTP page.

You will need to provide an HTTPS version of your data feed, if you want HTTPS pages to be able to access it. Otherwise browsers should, at the very least, produce warnings. Chrome now defaulting to block doesn't change the nature of the problem, it's just giving you the extra push you need to fix it properly.

7
votes

<script src="//domain.com/script.js"></script> solves the problem if remote server allows HTTPS... // will automatically set protocol to https if site is accessed by https.