Last Comment Bug 844342 - Insecure (Mixed) script loaded on
: Insecure (Mixed) script loaded on
: compat, dogfood, sec-high
Product: Graveyard
Classification: Graveyard
Component: Developer Pages (show other bugs)
: unspecified
: All All
: P2 major
: 2013-07-04
Assigned To: Jeff Griffiths (:canuckistani) (:⚡︎)
Depends on:
Blocks: mozorg-mixedcontent
  Show dependency treegraph
Reported: 2013-02-22 15:48 PST by Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
Modified: 2016-02-04 14:49 PST (History)
9 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-02-22 15:48:10 PST
+++ This bug was initially created as a clone of Bug #843977 +++

We expect Firefox 22 to ship with the mixed content blocker enabled, so any pages that aren't fixed before Firefox 22 ships will be (partially) broken in Firefox 22. Note that all of these pages are already partially broken in IE9+ unless the user explicitly chooses to allow non-secure content. In some cases, the pages are also already broken in Chrome.

Here is my original notice about this change to Firefox in dev-webdev: Please read the thread for important information and suggestions for identifying and fixing mixed-content issues. I suggest replying to the dev-webdev thread with questions.

Note that we are going to start blocking this kind of content because it (<script src> in particular) is a major security issue for any HTTPS website. In particular, if you load non-HTTPS script, then a MitM can basically "undo" all the protection that SSL gives the page. For example, it is trivial for them to modify the page to steal passwords and non-HttpOnly cookies.

The affected page on is:

Note that that is the documentation for the old version of the Addon SDK. The current version of the documentation doesn't seem to have this bug.

Google Chrome and Internet Explorer 9 both disable the search box on the affected page (like Firefox 22 will). So, in their browsers, it is a bug in that functional is lost, as opposed to a security bug.

Marking this sec-high because it can compromise to serve malicious content to users and possibly steal credentials. But, really it should be re-ranked by AMO team.
Comment 1 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-02-22 15:50:57 PST
Oh, I forgot: the insecure load is this:

 <script src="" type="text/javascript"></script>

AFAICT, the fix is simply to replace the "http://" with an "https://".
Comment 2 Tanvi Vyas - behind on reviews [:tanvi] 2013-03-29 16:54:27 PDT
Any update here?  All that is required is an extra "s".
Comment 3 Christopher Van Wiemeersch [:cvan] 2013-04-01 18:31:30 PDT
Pull request opened:
Comment 4 Tanvi Vyas - behind on reviews [:tanvi] 2013-05-30 11:28:49 PDT
Is there progress towards fixing this bug?  We want to fix all mozilla sites before Firefox 23 hits stable (August 8th).
Comment 5 Christopher Van Wiemeersch [:cvan] 2013-05-30 11:56:15 PDT
I made a pull request back in April, which just needs to be reviewed and merged in:
Comment 6 Jeff Griffiths (:canuckistani) (:⚡︎) 2013-05-30 16:11:01 PDT
:cvan, that PR is not the right approach, the docs are generated using this template:

The template is already updated to use an SSL url. We are going to re-generate the docs and publish them with the release of Firefox 22 in a few weeks, that new docs set will resolve this issue.
Comment 7 Adam Muntner [:adamm] (use NEEDINFO) 2013-06-06 13:29:35 PDT
Jeff, will that be June 25th?

(I'm on the web app security team, tracking the dependencies for the overall mixed content bug, 843977)
Comment 8 Jeff Griffiths (:canuckistani) (:⚡︎) 2013-06-06 15:35:34 PDT
Comment 9 Tanvi Vyas - behind on reviews [:tanvi] 2013-06-27 13:25:53 PDT
This page looks fixed -

Were there any other affected pages to test?
Comment 10 Jeff Griffiths (:canuckistani) (:⚡︎) 2013-07-02 12:32:33 PDT
The google search box is included from a template, so if one page works they all should.
Comment 11 Tanvi Vyas - behind on reviews [:tanvi] 2013-07-02 13:52:11 PDT
I think we are good to go here then.  Adam, do you have a scanner or something you could run against before we close this bug?  Or should we just close it?
Comment 12 Ben (:bensternthal) 2013-07-03 15:14:51 PDT
Closing. Original reported issue is resolved.

If additional issues are found please open a bug per issue.

Note You need to log in before you can comment on or make changes to this bug.