Mixed Content Level 2

Editor’s Draft,

This version:
Version History:
public-webappsec@w3.org with subject line “[mixed-content-2] … message topic …” (archives)
File an issue (open issues)
(Google Inc.)
(Google Inc.)
File an issue (open issues)


This specification describes how a user agent should handle fetching of content 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 “mixed-content-2” in the subject, preferably like this: “[mixed-content-2] …summary of comment…

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

This document was produced by a group operating under the 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 March 2019 W3C Process Document.

1. Introduction

This section is not normative.

When a user successfully loads a webpage from example.com over a secure channel (HTTPS, for example), the user is guaranteed that no entity between the user agent and example.com eavesdropped on or tampered with the data transmitted between them. However, this guarantee is weakened if the webpage loads subresources such as script or images over an insecure connection. For example, an insecurely-loaded script can allow an attacker to read or modify data on behalf of the user. An insecurely-loaded image can allow an attacker to communicate incorrect information to the user (e.g., a fabricated stock chart), mutate client-side state (e.g., set a cookie), or induce the user to take an unintended action (e.g., changing the label on a button). These requests are known as mixed content.

[MIXED-CONTENT] details how a user agent can mitigate these risks by blocking certain types of mixed content, and behaving more strictly in some contexts.

However, as implemented in today’s web browsers, [MIXED-CONTENT] does not fully protect the confidentiality and integrity of users' data. Insecure content such as images, audio, and video can currently be loaded by default in secure contexts.

Moreover, users do not have a clear security indicator when mixed content is loaded. When a webpage loads mixed content, browsers display an "in-between" security indicator (such as removing the padlock icon), which does not give users a clear indication of whether they should trust the page. This UX has also not proved a sufficient incentive for developers to avoid mixed content, since it is still common for webpages to load mixed content. Blocking all mixed content would provide the user with a simpler mental model -- the webpage is either loaded over a secure transport or it isn’t -- and encourage developers to securely load any mixed content that is necessary for their webpage to function properly.

Mixed Content Level 2 therefore updates and extends [MIXED-CONTENT] to provide users with better security and privacy guarantees and a better security UX, while minimizing breakage. Instead of advising browsers to simply strictly block all mixed content, the core idea of Level 2 is mixed content autoupgrading. That is, mixed content that user agents are not already blocking should be autoupgraded to a secure transport. If the request cannot be autoupgraded, it will be blocked. Autoupgrading avoids loading insecure resources on secure webpages, while minimizing the amount of developer effort needed to avoid breakage.

This specification (Level 2) only recommends autoupgrading types of mixed content that are not currently blocked by default, and does not recommend autougprading types of content that are already blocked. This is to minimize the amount of web-visible change; we only want to autoupgrade content if it advances us towards the goal of blocking all mixed content by default.

2. Key Concepts and Terminology


3. Algorithms

3.1. Upgrade request to an a priori authenticated URL as mixed content, if appropriate

Note: The Fetch specification will hook into this algorithm to upgrade optionally-blockable mixed content to HTTPS.

Given a Request request, this algorithm will rewrite its url if the request is deemed to be optionally-blockable mixed content, via the following algorithm:

  1. If one or more of the following conditions is met, return without modifying request:
    1. request’s url is an Mixed Content §a-priori-authenticated-url.
    2. Mixed Content §categorize-settings-object returns "Does Not Restrict Mixed Security Contents" when applied to request’s client.
    3. request’s mode is CORS.
    4. request’s destination is not "image", "audio", or "video".
    5. request’s destination is "image" and request’s initiator is "imageset".
  2. If request’s url’s scheme is http, set request’s url’s scheme to https, and return.

    Note: Per [url], we do not modify the port because it will be set to null when the scheme is http, and interpreted as 443 once the scheme is changed to https

3.2. Modifications to existing algorithms

Note: This section specifies modifications to existing mixed content algorithms to ignore the distinction between optionally-blockable and blockable mixed content, since all optionally-blockable mixed content will now be autoupgraded.

Mixed Content §should-block-fetch should be modified to remove Steps 3, 4, and 5, replacing them with a single step "Return blocked".

Mixed Content §should-block-response should be modified to remove Steps 2, 3, and 4, replacing them with a single step "Return blocked".

4. Integrations

4.1. Modifications to Fetch

Fetch Standard §4.1 Main fetch should be modified to call § 3.1 Upgrade request to an a priori authenticated URL as mixed content, if appropriate on request between steps 3 and 4. That is, optionally-blockable mixed content should be autoupgraded to HTTPS before applying mixed content blocking.

5. Obsolescences

5.1. block-all-mixed-content

This specification renders the Mixed Content §block-all-mixed-content CSP directive obsolete, because all mixed content is now blocked if it can’t be autoupgraded.

Note: The upgrade-insecure-requests ([upgrade-insecure-requests]) directive is not obsolete because it allows developers to upgrade blockable content. This specification only upgrades optionally-blockable content by default.

6. Security and Privacy Considerations

Overall, autoupgrading optionally-blockable mixed content is expected to be security- and privacy-positive, by protecting more user traffic from network eavesdropping and tampering.

There is a risk of introducing a security or privacy issue in a webpage by loading a resource that the developer did not intend. For example, suppose that a website includes an innocuous image from http://www.example.com/image.jpg, and for some reason https://www.example.com/image.jpg redirects to a tracking site. The browser will now have introduced a privacy issue without the developer’s or user’s explicit consent. However, these cases are expected to be exceedingly rare. The risk is mitigated by autoupgrading only optionally-blockable content, not blockable content as well. Blockable content could present more risk, for example the risk of loading an out-of-date and vulnerable JavaScript library.

7. Acknowledgements


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.


Terms defined by reference


Normative References

Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
Mike West. Mixed Content. 2 August 2016. CR. URL: https://www.w3.org/TR/mixed-content/
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/

Informative References

Mike West. Upgrade Insecure Requests. 8 October 2015. CR. URL: https://www.w3.org/TR/upgrade-insecure-requests/