Get started Bring yourself up to speed with our introductory content.

Firefox security features: Introduction to Mixed Content Blocker, CSP

Application security expert Michael Cobb discusses how Firefox's addition of Mixed Content Blocker and Content Security Policy improve Web security.

I saw Mozilla has made a few security improvements to Firefox. It now has a Mixed Content Blocker to help prevent man-in-the-middle attacks. Also, following in the footsteps of Google's Chrome and Microsoft's Internet Explorer, Mozilla has added Content Security Policy 1.0 to Firefox. Can you explain the effects of these Firefox security features on Web browser security?

Ask the Expert

SearchSecurity expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit them now via email. (All questions are anonymous.)

Mixed Content Blocker, which is enabled by default in Firefox 23, provides added protection for users when they access a webpage that contains content delivered via HTTPS and HTTP. While users can easily validate the source of HTTPS content, resources loaded via HTTP can't necessarily be trusted. Lazy site design can result in mixed content pages, which means the site can be subverted by hackers to launch a man-in-the-middle attack.

To mitigate this threat, Mixed Content Blocker prevents certain types of resources from appearing in an HTTPS page if they are loaded insecurely over HTTP. Content that has access to and can affect parts of the Document Object Model, such as scripts (e.g., Mixed Active Content), is blocked by default because it can be used in an attack to steal sensitive data from users. Mixed Passive Content (e.g., images, audio and video), is far less dangerous and therefore is allowed to load.

Though Mixed Content Blocker is one of the Firefox security features turned on by default, as with any security control, it is good to take the time to learn why it is important and how it protects users.

Content Security Policy (CSP) allows Web administrators to send an HTTP response header to a browser stating the locations from which additional content embedded in an HTML document can be loaded. This is an easy way for sites to protect users from cross-site scripting (XSS) and other data-injection attacks. Browsers assume all the content on a webpage is legitimately part of that page, but XSS, for example, tricks a website into delivering malicious code along with the intended content and allows hackers to abuse the assumed trust.

By whitelisting the domains in a CSP header and dictating where resources such as scripts can come from, administrators can prevent arbitrary or injected code hosted elsewhere from executing. By default, whitelisting also prevents inline scripts from executing and inline styles from being applied to the page.

Some attacks use cascading style sheets (CSS) selectors to exfiltrate data from the page and use attributes to overlay one element on top of another as part of a phishing attack. While script resources are the most obvious security risks, CSP provides policy directives for other resources, including fonts, frame content, images, video, audio, Flash and other plugins, and stylesheets. By default, these directives are wide open, allowing resources to be loaded from anywhere -- so there is some work involved for Web administrators and developers when they implement CSP. For example, functions that can parse JavaScript code from strings, such as eval(), are not allowed when using CSP. Now is a good a time to start implementing CSP, though, as it has become a standard.

Mozilla did add an implementation of CSP to Firefox 4.0 in 2011, but CSP 1.0, which is supported by Google Chrome and partially by Internet Explorer 10, is now the formal World Wide Web Consortium specification. This means that there is no longer a requirement to send multiple CSP headers with different syntaxes to different browsers. Developers who made use of Firefox's initial implementation of the feature should check out Mozilla's security blog because it offers information about the changes in the new implementation and details what needs to be done to guarantee that existing implementations will continue to work after the transition period.

This was last published in November 2013

Dig Deeper on Web browser security

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.