I ran into IE’s mixed content security alert feature earlier today when trying to load our application’s secure credit application page. Obviously it’s a bad user experience and it looks bad on us so I set out to fix it and found the following things that hopefully will save someone else some time.

The reason for the warning is that you’re on an SSL-secured (https protocol) page that is attempting to load non-SSL (http protocol) content. It’s ok if you’re on an HTTP page and you request HTTPS; you won’t receive the error.

First of all, you should download a tool for HTTP sniffing. I use Fiddler.

Run Fiddler and then browse to the page that is causing the message. You’ll see a bunch of requests go through, most likely. You can ignore any CONNECT requests; anything else should be showing up as HTTPS.

Most likely, you have a script or CSS file that is requesting HTTP content. If you set them all to HTTPS or leave them as relative paths, you should be ok.

For example:
/css/site.css - OK
https://www.example.com/css/site.css - OK
http://www.example.com/css/site.css - Error

Here’s your checklist of things to do:

• All loaded assets, such as images, scripts, css, favicons, etc. must be relative paths or be HTTPS.
• All iframes must point to an actual page (relative or HTTPS). No SRC attribute, or an SRC of # or about:blank will raise the error. Some people have used javascript: false; with success.
• Make sure all requests from your page are HTTPS. Google Analytics and other 3rd-party tools often have a special link you can use for HTTPS.
• The codebase attribute of an object (Flash, Applets, etc) must be HTTPS. IE doesn’t actually make a request on this, but it does check the protocol for some reason.
• Anything that returns an HTTP error will cause the error to pop up, since IE considers its error pages to be “insecure”. Of course, the whole browser’s insecure, but that’s another article.
• If you have a JavaScript that calls removeChild() on a node that has a background image, it may cause this error. You can set outerHTML = ” instead without consequence. Retarded, but it works.

Things that you don’t have to worry about:

• DOCTYPES
• XHTML namespaces
• Links in the page (anchors, not the link element)

The one that got me was the codebase attribute of an object element. I figured it was just too stupid to be the actual problem. Silly me; IE strikes again.

Hope this saves some folks time.

Ok, so we all know how much the Flash Player security model blows. So, because we weren’t in enough pain, Adobe is in the process of making the player even more strict (which is good) by giving you even more mundane tasks to complete if you ever want to do something totally crazy and out there like load SWFs from a subdomain.

You’ve probably already dealt with the crossdomain.xml file, but there are a few changes that you can make to it now, specifically to prohibit crossdomain spoofing if you allow file uploads. You can set the crossdomain file in the root of your folder to be the meta-mega-powerful-nothing-else-counts crossdomain file now.

The really great part about all of this is that regardless of how your set your crossdomain files, Flash Player will NEVER let you load a SWF from another domain and operate on it without the Security.allowDomain() set on the loaded SWF. It doesn’t matter if your crossdomain is as loose as a college cheerleader, or if you do the meta-crossdomain file, or set a crossdomain on both the loading and loaded domain. It doesn’t matter. The only way to get around this is to create a proxy SWF on the domain of the loaded site and pass in the URL that’s on the same domain as the proxy that you actually want to load.

More info on the Flash Player 9 Security Updates.