Mixed Content

3.1. Optionally-blockable Content

A resource or request is optionally-blockable 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 or request that isn’t optionally-blockable is blockable. 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.

Note: The plugin request context is used for requests made on behalf of a plugin. We categorize these requests as blockable, but recognize 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 plugin vendors implement mixed content checking themselves to mitigate the risks outlined in this document.

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' HTTPS 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' HTTPS state is not unauthenticated, then return Restricts mixed content.
3. Return Does Not Restrict Mixed Content.

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.4 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 window is no-window, return blocked.
   2. If request’s mode is CORS or CORS-with-forced-preflight, return blocked.
   3. If context is fetch:
      1. If request’s client’s global object is a Window object, return blocked.
      2. If request’s mode is not no-cors, return blocked.
   4. Otherwise, if context is a blockable request context, return blocked.
   5. If the user agent is configured to block optionally-blockable mixed content, return blocked.
   6. If request’s client’s strict mixed content checking flag is true, return blocked.
8. Return allowed.

Note: We special-case fetch to allow it as optionally-blockable in the event that a Service Worker is making a no-cors request in response to a Fetch event generated from a Document. In that case, the request’s client property will be an environment settings object whose global object is a Window object (the Service Worker’s request’s client, on the other hand, will be a WorkerGlobalScope object.

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 request is blockable, 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.4 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 HTTPS state is not authenticated, return blocked.

      Note: This covers both cases in which unauthenticated resources are returned (by a Service Worker, for example), as well as cases in which the TLS handshake succeeds, but the user agent chooses to hold it to a higher standard.

5. Return allowed.

7.1. Limitations

Blocking mixed content allows us to ensure that the guarantees discussed in §1 Introduction are upheld. Note, however, that those guarantees only protect developers and users against active network attackers who would otherwise be able to replace critical bits of code or content on the wire as it flows past. They do not protect against a compromised server that itself is coerced into sending corrupted resources.

Mechanisms such as Subresource Integrity [SRI] are designed to deal with this kind of threat, and we recommend that web developers make use of them whenever possible.

7.2. 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 blockable request, even if the submission occurs in the top-level browsing context.

7.3. 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 downgrades a context to a mixed security context by returning a resource in response to a mixed content request (either because the request is optionally-blockable, or because the user agent is configured to allow blockable requests), 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.

If a mixed content indication is present, it MUST be made available through accessibility APIs for users of assistive technologies.

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.4. 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 mixed content would be blocked).

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 MUST also be offered through accessibility APIs for users of assistive technologies.

7.5. Service Workers

The fact that Service Workers sit inbetween a document and the network means that we need to special-case requests made in those contexts. In particular, they should be able to cache the results of insecure requests, provided that those requests were triggered from a document (which, presumably, ensures that they’ll be used in an optionally-blockable context). Those insecure results, however, cannot be exposed to the Service Worker, nor should the Service Worker be allowed to launder responses to optionally-blockable requests into responses to blockable requests.

To that end:

1. §5.2 Should fetching request be blocked as mixed content? has some carve-outs for the fetch request context, with the intent of allowing a Service Worker to copy a request as part of its response to a Fetch event (e.g. fetch(event.response) should be executable inside the event handler.

   The fetch request context will continue to be treated as blockable when executed outside the context of a Fetch event, which of course includes document contexts.

2. §5.3 Should response to request be blocked as mixed content? verifies that the incoming response has the same security characteristics that were allowed for the request. That is, a Service Worker will not be able to replace a request for a secure script with a cached response for an insecure resource.

7.6. 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.