Mixed Content

Editor’s Draft,

This version:
https://w3c.github.io/webappsec/specs/mixedcontent/
Latest version:
http://www.w3.org/TR/mixed-content/
Previous Versions:
http://www.w3.org/TR/2014/WD-mixed-content-20140722/
Version History:
https://github.com/w3c/webappsec/commits/master/specs/mixedcontent/index.src.html
Feedback:
public-webappsec@w3.org with subject line “[MIX] … message topic …” (archives)
Editor:
(Google Inc.)

Abstract

This specification describes how a user agent should handle fetching of content loaded over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document.

Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Changes to this document may be tracked at https://github.com/w3c/webappsec.

The (archived) public mailing list public-webappsec@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “MIX” in the subject, preferably like this: “[MIX] …summary of comment…

This document was produced by the Web Application Security Working Group.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 August 2014 W3C Process Document.

The following features are at-risk, and may be dropped during the CR period:

Table of Contents

1. Introduction

This section is not normative.

When a user successfully loads a resource from example.com over a secure channel (HTTPS, for example), the user agent is able to make three assertions critical to the user’s security and privacy:

Together, these assertions give the user some assurance that example.com is the only entity that can read and respond to her requests (caveat: without shocking amounts of work) and that the bits she’s received are indeed those that example.com actually sent.

The strength of these assertions is substantially weakened, however, when the encrypted and authenticated resource requests subresources (scripts, images, etc) over an insecure channel. Those resource requests result in a resource whose status is mixed, as insecure requests are wide open for man-in-the-middle attacks. This scenario is unfortunately quite common.

This specification details how a user agent can mitigate these risks to security and privacy by limiting a resource’s ability to inadvertently communicate in the clear.

Note: Nothing described in this document is really new; everything covered here has appeared in one or more a user agent over the years: Internet Explorer led the way, alerting users to mixed content since at least version 4.

2. Key Concepts and Terminology

2.1. Terms defined by this specification

mixed content
A resource is said to be mixed content if the resource’s origin is insecure, and the context responsible for loading it restricts mixed content. See §5.1 Does settings object restrict mixed content? for a normative definition of the latter.
The image http://example.com/image.png is mixed content when loaded by https://not.example.com/.
potentially secure origin
potentially secure URL
An origin is said to be potentially secure if the origin’s scheme component is HTTPS, WSS, or about.

A URL whose origin is potentially secure is itself considered to be potentially secure.

a priori insecure origin
a priori insecure URL
Any origin which is not potentially secure is said to be a priori insecure. We know, for example, that http://example.com/ is insecure just by looking at its scheme component.

A URL whose origin is a priori insecure is itself considered to be a priori insecure.

insecure origin
insecure URL
An resource’s origin is said to be insecure if it is either a priori insecure, or the user agent discovers only after performing a TLS-handshake that the TLS-protection offered is deprecated.

A URL whose origin is insecure is itself considered to be insecure.

deprecated TLS-protection
A resource’s TLS-protection is said to be deprecated if a user agent refuses to trust the resource’s TLS handshake. This determination is vendor-specific.

For example, a user agent may choose to reject resources for which the server presented a publicly-trusted certificate for an "Internal Name" (e.g. https://intranet/), a certificate with an overly-long validity period, a certificate with a weak cipher suite, a certificate signed with SHA-1, or a certificate which otherwise fails to meet the CA/Browser Forum’s Baseline Requirements [CAB].

Note: We recommend that a user agent return network errors rather than fetching resources whose TLS-protection is deprecated.

Note: [WSC-UI] defines "weakly TLS-protected", which is de facto included in user agents' interpretation of what "deprecated" means.

2.2. Terms defined by reference

origin
An origin defines the scope of authority or privilege under which a resource operates. It is defined in detail in the Origin specification [RFC6454].
globally unique identifier
This term is defined in Section 4 of RFC6454 [RFC6454].

Note: URLs that do not use hierarchical elements as naming authorities (for example: blob:, and data:) have origins which are globally unique identifiers [URI].

fetch
"fetching" is the process by which a user agent requests resources, and delivers responses. It is defined in detail in the Fetch living standard [FETCH].
request
request client
request context
request context frame type
request client TLS state
response TLS state
These terms are defined in Section 2.2 of the Fetch living standard [FETCH].
response
network error
These terms are defined in detail in Section 2.3 of the Fetch living standard [FETCH].
environment settings object
Defined in [HTML5].
embedding document
Given a Document A, the embedding document of A is the Document through which A’s browsing context is nested.

3. Content Categories

In a perfect world, each user agent would be required to block all mixed content without exception. Unfortunately, that is impractical on today’s Internet; a user agent needs to be more nuanced in its restrictions to avoid degrading the experience on a substantial number of websites.

With that in mind, we here split mixed content into two categories: §3.1 Optionally-blockable Content and §3.2 Blockable Content.

Note: Future versions of this specification will update this categorization with the intent of moving towards a world where all mixed content is blocked; that is the end goal, but this is the best we can do for now.

3.1. Optionally-blockable Content

A resource is optionally-blockable content when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web. This could be because mixed usage of the resource type is sufficiently high, and because the resource is low-risk in and of itself. The fact that these resource types are optionally-blockable does not mean that they are safe, simply that they’re less catastrophically dangerous than other resource types. For example, images and icons are often the central UI elements in an application’s interface. If an attacker reversed the "Delete email" and "Reply" icons, there would be real impact to users.

This category of content includes:

  • Images loaded via img

    Note: This includes SVG documents loaded as images, as they are banned from executing script or loading subresources.

  • Video loaded via video and source
  • Audio loaded via audio and source
  • Prefetched content [HTML5]

These resource types map to the following Fetch request contexts: audio, image, prefetch, and video. These contexts are optionally-blockable request contexts.

Note: We further limit this category in §5.2 Should fetching request be blocked as mixed content? by force-failing any CORS-enabled request. This means that mixed content images loaded via <img crossorigin ...> will be blocked. This is a good example of the general principle that a category of content falls into this category only when it is too widely used to be blocked outright. The Working Group intends to find more blockable subsets of an otherwise optionally-blockable request context.

3.2. Blockable Content

Any resource that isn’t optionally-blockable is blockable content. Typical examples of this kind of content include scripts, plugin data, data requested via XMLHttpRequest, and so on. Every request context that is not optionally-blockable is a blockable request context. This explicitly includes any contexts defined after publication of this document.

Note: The request contexts form, hyperlink, and location might refer to top-level browsing context navigations, which are not considered mixed content. See the treatment of request context frame type in §5.2 Should fetching request be blocked as mixed content? for details.

4. Strict Mixed Content Checking

In order to give authors assurance that mixed content will never degrade the security UI presented to their users (as described in §7.2 UI Requirements), authors may choose to enable a stricter variant of mixed content checking which will both block optionally-blockable and blockable mixed content, and suppress the user override options discussed in §7.3 User Controls.

To this end, Document objects and browsing contexts have a strict mixed content checking flag which is set to false unless otherwise specified. This flag is checked in both §5.2 Should fetching request be blocked as mixed content? and §5.3 Should response to request be blocked as mixed content? to determine whether the Document is in strict mode.

A Document may opt itself into strict mode by either delivering a Content-Security-Policy HTTP header, like:
Content-Security-Policy: strict-mixed-content-checking

or by embedding the policy in a meta element, like:

<meta http-equiv="Content-Security-Policy"
      content="strict-mixed-content-checking">

Note: Strict mixed content checking is inherited by embedded content; if a page opts into strict mode, framed pages will be prevented from loading mixed content, as described in §4.3 Inheriting an opt-in.

4.1. Effects

If a Document's strict mixed content checking flag is set to true, the user agent MUST:

  1. treat optionally-blockable mixed content as though it were blockable.
  2. NOT provide users with a mechanism for forcing blockable mixed content to load.

    Note: This requirement overrides the suggestion in §7.3 User Controls.

  3. NOT provide any user-facing indication that mixed content is present.

    Note: This requirement overrides the suggestion in §7.2 UI Requirements, which is safe to do since the combination of the first and second requirements above ensure that mixed content will never load in this page’s context.

    Note: This requirement does not include developer-facing indicators such as console messages.

  4. ensure that these requirements are applied to any Document in a nested browsing context, as described in §4.3 Inheriting an opt-in.

4.2. Opting-in

Authors may opt a Document into strict mixed content checking via a strict-mixed-content-checking Content Security Policy directive [CSP], defined via the following ABNF grammar.

directive-name  = "strict-mixed-content-checking"
directive-value = ""

When enforcing the strict-mixed-content-checking directive, set the protected resource’s strict mixed content checking flag to true.

This directive has no effect when monitored. This directive’s only effect is to set a policy flag on the protected resource; it will therefore never be violated, and has no reporting requirements.

Note: A similar effect may be achieved on a more granular level by setting individual directives. For example img-src https: would prevent insecure images from loading.

4.3. Inheriting an opt-in

If a Document's strict mixed content checking flag is set, the user agent MUST ensure that all nested browsing contexts inherit the setting in the following ways:

  1. When a nested browsing context context is created, set its strict mixed content checking flag to true if context’s embedding document’s strict mixed content checking flag is set to true.
  2. When creating a new Document object, set its strict mixed content checking flag to true if its browsing context’s strict mixed content checking flag is true.

5. Insecure Content in Secure Contexts

At a high level, the following algorithms allow user agents to determine whether particular requests should succeed, or should result in network errors.

Fetch calls the algorithm defined in §5.2 Should fetching request be blocked as mixed content? during Step 4 of the Fetching algorithm [FETCH] in order to block network traffic to a priori insecure origins.

Note: Hooking into Fetch here ensures that we catch not only the initial request, but all redirects as well. That is certainly the intent.

Further, Fetch calls the algorithm defined in §5.3 Should response to request be blocked as mixed content? during Step 7 of the Fetching algorithm [FETCH] in order to block responses from insecure origins.

Note: This hook is necessary to detect resources modified or synthesized by a ServiceWorker, as well as to determine whether a resource is insecure once the TLS-handshake has finished. See steps 4.1 and 4.2 of the algorithm defined in §5.3 Should response to request be blocked as mixed content? for detail.

The algorithm defined in §5.1 Does settings object restrict mixed content? is used by both §5.2 Should fetching request be blocked as mixed content? and §5.3 Should response to request be blocked as mixed content? , as well as §6 Modifications to WebSockets in order to determine whether an insecure request ought to be blocked.

5.1. Does settings object restrict mixed content?

Both documents and workers have environment settings objects which may be examined according to the following algorithm in order to determine whether they restrict mixed content. This algorithm returns Restricts Mixed Content or Does Not Restrict Mixed Content, as appropriate.

Given an environment settings object settings:

  1. If settings' TLS state is not unauthenticated, then return Restricts Mixed Content.
  2. If settings has a responsible document document, then:
    1. While document has an embedding document:
      1. Let document be document’s embedding document.
      2. Let embedder settings be document’s incumbent settings object.
      3. If embedder settings' TLS state is not unauthenticated, then return Restricts mixed content.
  3. Return Does Not Restrict Mixed Content.
If a document has an embedding document, a user agent needs to check not only the document itself, but also the top-level browsing context in which the document is nested, as that is the context which controls the user’s expectations regarding the security status of the resource she’s loaded. For example:
http://a.com loads http://evil.com. The insecure request will be allowed, as a.com was not loaded over a secure connection.
https://a.com loads http://evil.com. The insecure request will be blocked, as a.com was loaded over a secure connection.
http://a.com frames https://b.com, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as b.com was loaded over a secure connection, even though a.com was not.
https://a.com frames a data: URL, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as a.com was loaded over a secure connection, even though the framed data URL was not.

5.2. Should fetching request be blocked as mixed content?

Note: The Fetch specification hooks into this algorithm to determine whether a request should be entirely blocked (e.g. because the request is for blockable content, and we can assume that it won’t be loaded over a secure connection).

Given a Request request, a user agent determines whether the Request request should proceed or not via the following algorithm:

  1. Let context be request’s context.
  2. Let frame type be request’s context frame type.
  3. Let origin be the origin of request’s URL.
  4. If §5.1 Does settings object restrict mixed content? returns Does Not Restrict Mixed Content when applied to request’s client, return allowed.
  5. If the user agent has been instructed to allow mixed content (as outlined in §7.3 User Controls), return allowed.
  6. If request’s context frame type is top-level, return allowed.
  7. If origin is a priori insecure:
    1. If request’s mode is CORS or CORS-with-forced-preflight, return blocked.
    2. If context is not an optionally-blockable request context, return blocked.
    3. If the user agent is configured to block optionally-blockable mixed content, return blocked.
    4. If request’s client’s strict mixed content checking flag is true, return blocked.
  8. Otherwise, origin is potentially secure, so return allowed.

5.3. Should response to request be blocked as mixed content?

Note: If a request proceeds, we still might want to block the response based on the state of the connection that generated the response (e.g. because the response is for blockable content, but the connection is insecure). This algorithm is used to make that determination.

Given a request request and response response, the user agent determines what response should be returned via the following algorithm:

  1. If §5.1 Does settings object restrict mixed content? returns Does Not Restrict Mixed Content when applied to request’s client, return allowed.
  2. If the user agent has been instructed to allow mixed content (as outlined in §7.3 User Controls), return allowed.
  3. Let context be the request context of request.
  4. If context is not an optionally-blockable request context, or the user agent is configured to block optionally-blockable mixed content, or request’s client’s strict mixed content checking flag is true:
    1. If response’s TLS state is not authenticated, return blocked.

      Note: This covers both cases in which unauthenticated resources are requested, as well as cases in which the TLS handshake succeeds, but the user agent chooses to hold it to a higher standard. The definition of deprecated TLS-protection has some examples of these kinds of scenarios.

  5. Return allowed.

6. Modifications to WebSockets

The WebSocket() constructor algorithm [WEBSOCKETS] is modified as follows:

The Establish a WebSocket Connection algorithm [RFC6455] is modified as follows:

7. Security Considerations

7.1. Form Submission

If §5.1 Does settings object restrict mixed content? returns Restricts Mixed Content when applied to a Document's incumbent settings object, then a user agent MAY choose to warn users of the presence of one or more form elements with action attributes whose values are insecure URLs.

Note: Chrome, for example, currently gives the same UI treatment to a page with an insecure form action as it does for a page that displays an insecure image.

Further, a user agent MAY treat form submissions from such a Document as a request for blockable content, even if the submission occurs in the top-level browsing context.

7.2. UI Requirements

If a user agent would normally indicate to the user that the top-level browsing context is secure, then when the user agent services a request for an optionally-blockable resource which is mixed content, then the user agent MUST NOT provide the user with that same indication. The user agent SHOULD instead give an indication that mixed content is present.

Any visible indicators of security state (for instance, a green lock icon) SHOULD also be made available through accessibility APIs for users of assistive technolgies.

Note: This requirement holds even in the context of an EV status [CAB]. An EV certificate’s indicator does not override the necessity to notify users of mixed content violations.

7.3. User Controls

A user agent MAY offer users the ability to directly decide whether or not to treat all mixed content as blockable (meaning that even optionally-blockable would be blocked in a mixed context).

Note: It is strongly recommended that users take advantage of such an option if provided.

A user agent MAY offer users the ability to override its decision to block blockable mixed content on a particular page.

Note: Practically, a user agent probably can’t get away with not offering such a back door. That said, allowing mixed script is in particular a very dangerous option, and each user agent REALLY SHOULD NOT [RFC6919] present such a choice to users without careful consideration and communication of the risk involved.

Any such controls offered by a user agent SHOULD also be offered through accessability APIs for users of assistive technologies.

7.4. Further Action

A user agent is encouraged to take further action above and beyond the requirements this document outlines in order to discourage developers from embedding mixed content.

For instance, a user agent could:

  1. Interpret the presence of a Strict-Transport-Security header field as forcing all content into the blockable category [RFC6797], or as a signal to enable strict mode for mixed content checking.
  2. Modify requests for optionally-blockable resources which are mixed content in order to reduce the risk to users: cookies and other authentication tokens could be stripped from the requests, automatic scheme upgrades could be attempted, and so on.
  3. Treat optionally-blockable resources inside nested browsing contexts as blockable, to allow sites to embed resources without fear of introducing mixed content.

8. Acknowledgements

In addition to the wonderful feedback gathered from the WebAppSec WG, the Chrome security team was invaluable in preparing this specification. In particular, Chris Palmer, Chris Evans, Ryan Sleevi, Michal Zalewski, Ken Buchanan, and Tom Sepez gave lots of early feedback. Anne van Kesteren explained Fetch and helped define the interface to this specification. Brian Smith helped keep the spec focused, trim, and sane.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words "for example" or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word "Note" and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Conformance Classes

A conformant user agent must implement all the requirements listed in this specification that are applicable to user agents.

A conformant server must implement all the requirements listed in this specification that are applicable to servers.

References

Normative References

[CAB]
???. CA/Browser Forum Baseline Requirements v1.1.8. URL: https://cabforum.org/baseline-requirements-documents/
[FETCH]
Anne van Kesteren. Fetch. Living Standard. URL: https://fetch.spec.whatwg.org/
[RFC6454]
Adam Barth. The Web Origin Concept. RFC. URL: http://www.ietf.org/rfc/rfc6454.txt
[RFC6455]
Ian Fette; Alexey Melnikov. The WebSocket Protocol. RFC. URL: http://www.ietf.org/rfc/rfc6455.txt
[html5]
Robin Berjon; et al. HTML5. 28 October 2014. REC. URL: http://www.w3.org/TR/html5/
[rfc2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt
[websockets]
Ian Hickson. The WebSocket API. 20 September 2012. CR. URL: http://www.w3.org/TR/websockets/

Informative References

[CSP]
Brandon Sterne; Adam Barth. Content Security Policy 1.0. 15 November 2012. CR. URL: http://www.w3.org/TR/CSP/
[RFC6797]
Jeff Hodges; Collin Jackson; Adam Barth. HTTP Strict Transport Security (HSTS). RFC. URL: http://www.ietf.org/rfc/rfc6797.txt
[URI]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. URL: http://www.ietf.org/rfc/rfc3986.txt
[rfc6919]
R. Barnes; S. Kent; E. Rescorla. Further Key Words for Use in RFCs to Indicate Requirement Levels. 1 April 2013. Experimental. URL: http://www.ietf.org/rfc/rfc6919.txt
[wsc-ui]
Thomas Roessler; Anil Saldhana. Web Security Context: User Interface Guidelines. 12 August 2010. REC. URL: http://www.w3.org/TR/wsc-ui/

Index