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. Secure pages can even initiate insecure downloads which escape the user agent’s sandbox entirely.
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 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 sandbox (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 priori authenticated, and the context responsible for
loading it prohibits mixed security contexts (see § 4.3 Does settings prohibit mixed security 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 security 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 ashttp://example.com/image.png, otherwise it will block the load.
Note: "Mixed content" was originally 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 security context across user agents for more than a decade, the practical risk of confusion seems low.
-
- a priori authenticated URL
-
We know a priori that a request to a particular URL
(url) will be delivered in a way that mitigates the risks of
interception and modifications if either of the following statements is
true:
-
url is a potentially trustworthy URL [SECURE-CONTEXTS].
-
url’s scheme is "
data".Note: We special case
dataURLs here, as we don’t consider them particularly trustworthy, but we also don’t wish to block them as mixed content, as they never hit the network.
-
- unauthenticated response
- We know a posteriori that a response (response) is unauthenticated if response’s url is not a priori authenticated.
- 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.
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
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 crossorigin ...> 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 request to an a priori authenticated URL as mixed content, 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 an a priori authenticated URL
- § 4.3 Does settings prohibit mixed security contexts? returns "
Does Not Restrict Mixed Security Contents" when applied to request’s client. - request’s mode is
CORS. - request’s destination is not "
image", "audio", or "video". - request’s destination is "
image" and request’s initiator is "imageset".
-
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. Existing Mixed Content Algorithms and Modifications
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 and Mixed Content §should-block-response are replaced by the versions below, while Mixed Content §categorize-settings-object is left unmodified (but included below since this will replace the [mixed-content] spec).
section>
4.3. Does settings prohibit mixed security 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 Security Contexts" or "Does Not Prohibit Mixed Security Contexts",
as appropriate.
Given an environment settings object (settings):
-
If settings’ origin is a priori authenticated., then return "
Prohibits Mixed Security Contexts". -
If settings has a responsible document document, then:
-
While document has an embedding document:
-
Set document to document’s embedding document.
-
Let embedder settings be document’s global object's relevant settings object.
-
If embedder settings’ origin is a priori authenticated, then return "
Prohibits Mixed Security Contexts".
-
-
-
Return "
Does Not Restrict Mixed Security 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 security contexts? returns "
Does Not Restrict Mixed Security Contexts" when applied to request’s client. - request’s url is a priori authenticated.
- 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 security 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 security contexts? returns
Does Not Restrict Mixed Contentwhen applied to request’s client. - response’s url is a priori authenticated
- 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 security contexts? returns
- Return blocked.
5. Integrations
5.1. Modifications to Fetch
Fetch Standard §4.1 Main fetch should be modified to call § 4.1 Upgrade request to an a priori authenticated URL as mixed content, 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 an a priori authenticated URLs and any URL in response’s URL list is not an a priori authenticated URLs.
A similar change should be made to downloads a hyperlink. In this algorithm, step 6.2 should be modified to return (aborting the download) if subject’s node document’s url is an a priori authenticated URLs and any URL in response’s URL list is not an a priori authenticated URLs (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
This specification renders the Mixed Content §strict-checking mode and
the 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 upgradeable content by default.
6.2. Mixed Content
This specification renders the [mixed-content] specification obsolete, and replaces it.
7. Security and Privacy Considerations
Overall, autoupgrading upgradeable 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 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 security 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 a priori authenticated URLs
A user agent MAY choose to warn users on submission of a form element with action attributes whose values are not a priori authenticated URLs and allow users to abort the submission.
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 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, 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.