Insecure (Mixed) script loaded on

RESOLVED FIXED in 2013-07-04

Status Graveyard
Developer Pages
5 years ago
2 years ago


(Reporter: briansmith, Assigned: canuckistani)


(Blocks: 1 bug, {compat, dogfood, sec-high})

compat, dogfood, sec-high


+++ 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.
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://".
Blocks: 843977
No longer blocks: 815321
Any update here?  All that is required is an extra "s".
Pull request opened:
Assignee: nobody → jgriffiths
Is there progress towards fixing this bug?  We want to fix all mozilla sites before Firefox 23 hits stable (August 8th).
Priority: -- → P2
I made a pull request back in April, which just needs to be reviewed and merged in:
: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.
Jeff, will that be June 25th?

(I'm on the web app security team, tracking the dependencies for the overall mixed content bug, 843977)
Flags: needinfo?(jgriffiths)
Flags: needinfo?(jgriffiths)
This page looks fixed -

Were there any other affected pages to test?
The google search box is included from a template, so if one page works they all should.
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

4 years ago
Closing. Original reported issue is resolved.

If additional issues are found please open a bug per issue.
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2013-07-04
Product: → Graveyard
You need to log in before you can comment on or make changes to this bug.