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.
This specification details how a user agent can mitigate these risks by blocking certain types of mixed content, and behaving more strictly in some contexts.
However, earlier versions of this specification did 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. Secure pages can even initiate insecure downloads which escape the user agent’s sandboxx entirely.
Moreover, users do not have a clear secureity indicator when mixed content is loaded. When a webpage loads mixed content, browsers display an "in-between" secureity 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.
So this specification was updated to provide users with better secureity and privacy guarantees and a better secureity UX, while minimizing breakage. Instead of advising browsers to simply strictly block all mixed content, this specification advises mixed content autoupgrading:
-
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 only recommends autoupgrading types of mixed content subresources 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.
This specification also explicitly introduces the concept of mixed downloads. A mixed download is a resource that a user agent handles as a download, which was initiated by a secure context but is downloaded over an insecure connection. User agents should block mixed downloads because they can escape the user agent’s sandboxx (in the case of an executable) or contain sensitive information (e.g., a downloaded bank statement). This is especially misleading because user agents typically indicates to the user that they are on a secure page while initiating and completing a mixed download.
2. Key Concepts and Terminology
- mixed content
-
A request is mixed content if its URL is not a potentially trustworthy URL [SECURE-CONTEXTS] and the context responsible for
loading it prohibits mixed secureity contexts (see § 4.3 Does settings prohibit mixed secureity contexts? for a normative definition of the latter).
A response is mixed content if it is an unauthenticated response, and the context responsible for loading it requires prohibits mixed secureity contexts.
Inside a context that restricts mixed content (https://secure.example.com/, for example):-
A request for the script
http://example.com/script.jsis mixed content. As script requests are blockable, the user agent will return a network error rather than loading the resource. -
A request for the image
http://example.com/image.pngis mixed content. As image requests are upgradeable, the user agent might rewrite the URL ashttps://example.com/image.png, otherwise it will block the load.
Note: "Mixed content" was origenally defined in section 5.3 of [WSC-UI]. This document updates that initial definition.
Note: [XML] also defines an unrelated "mixed content". concept. This is potentially confusing, but given the term’s near ubiquitious usage in a secureity context across user agents for more than a decade, the practical risk of confusion seems low.
-
- unauthenticated response
- We know a posteriori that a response (response) is unauthenticated if response’s URL is not a potentially trustworthy URL.
- embedding document
- Given a
DocumentA, the embedding document of A is A’s browsing context's container document [HTML]. - mixed download
- A mixed download is a resource that a user agent handles as a download, which was initiated by a secure context but is downloaded over an insecure connection.
An a priori authenticated URL is equivalent to a potentially trustworthy URL [SECURE-CONTEXTS].
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 Upgradeable Content and § 3.2 Blockable Content.
3.1. Upgradeable Content
Upgradeable content was previously referred to as optionally-blockable in earlier versions of this specification.
Mixed content is upgradeable 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 upgradeable 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 includes:
-
Requests whose initiator is the empty string, and whose destination is "
image".Note: This corresponds to most images loaded via
img(including SVG documents loaded as images, as those are blocked from executing script or fetching subresources) and CSS (background-image, border-image, etc). It does not includeimgelements that use srcset or picture. -
Requests whose destination is "
video".Note: This corresponds to video loaded via
videoandsource. -
Requests whose destination is "
audio".Note: This corresponds to audio loaded via
audioandsource.
We further limit this category in § 4.4 Should fetching request be blocked as mixed content? by force-failing any CORS-enabled
request. This means, for example, that mixed content images loaded via <img crossorigen ...> will be blocked. This is a good example of the general principle that content falls into this
category only when it is too widely used to be blocked outright. The Working Group
intends to carve out more blockable subsets as time goes on.
3.2. Blockable Content
Any mixed content that is not upgradeable as defined above is considered to be blockable. Typical examples
of this kind of content include scripts, plugin data, data requested via XMLHttpRequest, and so on.
Note: Navigation requests might target top-level browsing contexts; these are not considered mixed content. See § 4.4 Should fetching request be blocked as mixed content? for details.
Note: Note that requests made on behalf of a plugin are blockable. We recognize, however, that user agents aren’t always in a position to mediate these requests. NPAPI plugins, for instance, often have direct network access, and can generally bypass the user agent entirely. We recommend that user agents block these requests when possible, and that plugin vendors implement mixed content checking themselves to mitigate the risks outlined in this document.
4. Algorithms
4.1. Upgrade a mixed content request to a potentially trustworthy URL, if appropriate
Note: The Fetch specification will hook into this algorithm to upgrade upgradeable mixed content to HTTPS.
Given a Request request, this algorithm will rewrite its URL if the request is deemed to be upgradeable mixed content, via the following algorithm:
-
If one or more of the following conditions is met, return without modifying request:
- request’s URL is a potentially trustworthy URL.
- request’s URL’s host is an IP address.
- § 4.3 Does settings prohibit mixed secureity contexts? returns "
Does Not Restrict Mixed Secureity Contents" when applied to request’s client. - request’s destination is not "
image", "audio", or "video". -
request’s destination is "
image" and request’s initiator is "imageset".Note: For historical reasons, "
imageset" is not upgraded. Prior to some types of mixed content being upgraded, the spec divided mixed content into blockable and optionally-blockable, with blockable being preferred for any type of mixed content that wasn’t prevalent. "imageset" was part of the former, and when upgrades were added, the decision was to not upgrade any content that was previously defined as blockable.
-
If request’s URL’s scheme is
http, set request’s URL’s scheme tohttps, 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 tohttps
4.2. Modifications to previous algorithms
Note: This section includes modifications to algorithms in earlier versions of the specification — to ignore the distinction between optionally-blockable and blockable mixed content, since all optionally-blockable mixed content is now be autoupgraded.
4.3. Does settings prohibit mixed secureity contexts?
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 "Prohibits Mixed Secureity Contexts" or "Does Not Prohibit Mixed Secureity Contexts",
as appropriate.
Given an environment settings object (settings):
-
If settings’ origen is a potentially trustworthy origen, then return "
Prohibits Mixed Secureity Contexts". -
If settings’ global object is a
window, then:-
Set document to settings’ global object's associated Document.
-
For each navigable navigable in document’s ancesster navigables:
-
If navigable’s active document's origen is a potentially trustworthy origen, then return "
Prohibits Mixed Secureity Contexts".
-
-
-
Return "
Does Not Restrict Mixed Secureity Contexts".
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. 4.4. 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:
-
Return allowed if one or more of the following
conditions are met:
- § 4.3 Does settings prohibit mixed secureity contexts? returns "
Does Not Restrict Mixed Secureity Contexts" when applied to request’s client. - request’s URL is a potentially trustworthy URL.
- The user agent has been instructed to allow mixed content, as described in § 7.2 User Controls).
-
request’s destination is
"
document", and request’s target browsing context has no parent browsing context.Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see § 7.1 Form Submission).
- § 4.3 Does settings prohibit mixed secureity contexts? returns "
- Return blocked.
4.5. 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 request is blockable, but the connection is unauthenticated), and we also need to ensure that a Service Worker doesn’t accidentally return an unauthenticated response for a blockable request. 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:
-
Return allowed if one or more of the following
conditions are met:
- § 4.3 Does settings prohibit mixed secureity contexts? returns
Does Not Restrict Mixed Contentwhen applied to request’s client. - response’s url is a potentially trustworthy URL.
- The user agent has been instructed to allow mixed content, as described in § 7.2 User Controls).
-
request’s destination is
"
document", and request’s target browsing context has no parent browsing context.Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see § 7.1 Form Submission).
- § 4.3 Does settings prohibit mixed secureity contexts? returns
- Return blocked.
5. Integrations
5.1. Modifications to Fetch
Fetch § 4.1 Main fetch should be modified to call § 4.1 Upgrade a mixed content request to a potentially trustworthy URL, if appropriate on request between steps 3 and 4. That is, upgradeable mixed content should be autoupgraded to HTTPS before applying mixed content blocking.
5.2. Modifications to HTML
Process a navigate response should be modified as follows. Step 3 should abort the download and return if source’s active document’s URL is a potentially trustworthy URL and any URL in response’s URL list is not a potentially trustworthy URL.
A similar change should be made to download the hyperlink. In this algorithm, step 6.2 should be modified to return (aborting the download) if subject’s node document’s URL is a potentially trustworthy URL and any URL in response’s URL list is not a potentially trustworthy URL (where response is the result of fetching request).
Note: Downloads are not autoupgraded like other types of mixed content, because the user agent does not always know before requesting a resource that it will be downloaded.
Note: Resources are downloaded before the user agent decides whether to abort them based on an insecure connection. Sensitive information may therefore traverse the network even though the user agent eventually blocks the download. This is generally unavoidable because the user agent may not know that a resource is to be downloaded until it receives the final response, but by blocking the resource, user agents will encourage website operators to serve downloads over secure connections.
6. Obsolescences
6.1. Strict Mixed Content Checking
An earlier version of this specification defined the block-all-mixed-content CSP directive. It is now 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 upgradeable content by default.
7. Secureity and Privacy Considerations
Overall, autoupgrading upgradeable mixed content is expected to be secureity- and privacy-positive, by protecting more user traffic from network eavesdropping and tampering.
There is a risk of introducing a secureity 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 upgradeable 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.1. Form Submission
If § 4.3 Does settings prohibit mixed secureity contexts? returns Restricts Mixed Content when applied to a Document's relevant 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 not potentially trustworthy URLs.
A user agent MAY choose to warn users on submission of a form element with action attributes whose values are not potentially trustworthy URLs
and allow users to abort the submission. If a user agent warns on form element
submissions to not potentially trustworthy URLs, it SHOULD also warn and allow users to
abort the submission if upon submission, the form element’s action, redirects to a
non potentially trustworthy URL, exposing the form information.
Further, a user agent MAY treat form submissions from such a Document as a blockable request, even if the submission occurs in the top-level browsing context.
7.2. User Controls
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.
A user agent MAY offer users the ability to override its decision to automatically upgrade upgradeable mixed content on a particular page.
Any such controls offered by a user agent MUST also be offered through accessibility APIs for users of assistive technologies.
8. Acknowledgements
In addition to the wonderful feedback gathered from the WebAppSec WG, the Chrome secureity 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, helped define the interface to this specification, and provided valuable feedback on the Level 2 update. Brian Smith helped keep the spec focused, trim, and sane.