Mixed Content

3.1. Optionally-blockable Content

A resource is considered 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, or because the resource is very clearly low-risk in and of itself. This category of content includes:

• Images loaded via img

  Note: This includes SVG documents loaded as images.

• 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: 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 on users.

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 considered blockable content. A non-exhaustive sample of content that falls into this category includes:

• Scripts (loaded, for example, via script elements, as well as scripts loaded as Workers and SharedWorkers [WORKERS], or ServiceWorkers [SERVICEWORKERS]) [ECMA-262]
• Stylesheets [CSS21]
• Plugin data (loaded, for example, through applet, embed, or object elements; or through a plugin document loaded into an iframe or frame element) [HTML5]
• SVG Documents [SVG2]
• XSL Transformations [XSLT]
• HTML Imports [HTML-IMPORTS]
• HTML Manifests [MANIFEST]
• Documents rendered in iframe elements
• Beacon [BEACON]
• Custom Filters [FILTER-EFFECTS]
• Data (loaded, for example, via XMLHttpRequest [XMLHTTPREQUEST], EventSource [EVENTSOURCE], or WebSockets [WEBSOCKETS])
• hyperlink auditing pings [HTML]
• Subtitles and captions loaded via track elements
• Web Fonts [CSS3-WEBFONTS]
• Images loaded via <picture>
• Resources which are not rendered directly in the browser, but downloaded to a user’s storage device (either as a result of a download attribute, or Content-Disposition headers)

These resource types map to the following Fetch request contexts: beacon, cspreport, download, embed, eventsource, favicon, fetch, font, form, frame, hyperlink, iframe, imageset, location, manifest, object, ping, plugin, script, serviceworker, sharedworker, subresource, style, track, worker, xmlhttprequest, and xslt. These contexts are the blockable request contexts.

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.

3.3. Future Contexts

This document exhaustively categorizes the request contexts currently defined in the Fetch specification. It is the intention of the Working Group that any new content types defined in the future be prevented from loading as mixed content. To that end, any request context which is not explicitly listed in the preceeding content categories MUST be considered a blockable request context.

4.1. Resource Fetching

User agents SHOULD reject weakly TLS-protected resources entirely by failing the TLS handshake, or by requiring explicit user acceptance of the risk (for instance, presenting the user with a confirmation screen she must click through).

If a Document's incumbent settings object restricts mixed content, or the relevant settings object for a script restricts mixed content, then fetching resource in response to requests (including not only requests for a Document's subresources, but also requests made from (Workers, SharedWorkers, Service Workers, and so on) will exhibit the following behavior:

1. Requests for blockable resources from an a priori insecure origin will not generate network traffic, but will instead return a synthetically generated network error response.
2. Responses to requests for blockable resources from an insecure origin will not be delivered to the request client, but instead will return a synthetically generated network error response.

§7 Integration with Fetch and §5 Insecure Content in Secure Contexts detail how these fetching requirements could be implemented.

User agents MAY take further action:

1. Requests for optionally-blockable resources which are mixed content SHOULD be treated as blockable (and therefore returned as a network error as described above), but user agents MAY allow them to load normally.

   Note: For instance, a user agent could interpret the presence of a Strict-Transport-Security header field as forcing all content into the blockable category. [RFC6797]

2. Requests for optionally-blockable resources which are mixed content MAY be modified to reduce the risk to users. For example, cookies and other authentication tokens could be stripped from the requests, or the user agent could automatically change the protocol of the requested URL to HTTPS in certain cases.

4.2. Script APIs

If the relevant settings object for a script script restricts mixed content, then user agents will model a mixed content failure as a network error. This means that:

1. An XMLHttpRequest rejected as mixed content will run the steps for a network error during execution of the send() method. [XMLHTTPREQUEST]
2. An EventSource connection rejected as mixed content will cause the user agent to fail the connection. [EVENTSOURCE]
3. When processing WebSocket’s constructor, for an a priori insecure origin, a SecurityError exception will be thrown. [WEBSOCKETS]

4.3. Form Submission

If a Document's incumbent settings object restricts mixed content, then user agents 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, user agents MAY optionally treat form submissions in the top-level browsing context from a Document whose incumbent settings object restricts mixed content as a request for blockable content to protect users from accidental data leakage.

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.

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 request’s client does not restrict mixed content, return allowed.
5. If request’s context frame type is top-level, return allowed.
6. If origin is a priori insecure:
   1. If request’s mode is CORS or CORS-with-forced-preflight, return blocked.
   2. If context is a blockable request context, return blocked.
   3. If the user agent is configured to block optionally-blockable mixed content, return blocked.
7. 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 server 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 request’s client does not restrict mixed content, return allowed.
2. Let context be the request context of request.
3. If context is an blockable request context or the user agent is configured to block optionally-blockable mixed content:
   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, and the resource exceeds the definition of weakly TLS-protected, 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.

4. Return allowed.

6.1. May Document use powerful features?

Given a Document document, this algorithm returns Allowed or Not Allowed as appropriate.

1. While document corresponds to an iframe srcdoc Document, let document be that Document’s browsing context’s browsing context container’s Document.
2. If document’s active sandboxing flag set has its sandboxed origin browsing context flag set:
   1. Set origin to the origin of document’s address.
3. If the result of executing the §6.3 Is origin potentially trusted? algorithm on origin is Potentially Trusted, return Allowed.
4. Return the result of executing the §6.2 May environment settings object use powerful features? algorithm on browsing context’s incumbent settings object.

Note: Sandboxed documents will have a unique origin. This algorithm uses the location of a sandboxed document to determine whether it should be considered authenticated. That is, the document inside <iframe src="https://example.com/" sandbox="allow-script"> would be considered to allow powerful features.

6.2. May environment settings object use powerful features?

Given an environment settings object settings, this algorithm returns Allowed if powerful features may be used in the object’s context, and Not Allowed otherwise.

1. If settings' TLS state is authenticated, return Allowed.
2. Otherwise:
   1. Let origin be settings' origin.
   2. If the result of executing the §6.3 Is origin potentially trusted? algorithm on origin is Potentially Trusted, return Allowed.
3. Return Not Allowed.

6.3. Is origin potentially trusted?

Certain origins are impossible for a user agent not to place trust in. In particular, file: URLs and the loopback interface both expose aspects of the machine on which the user agent is running. The user agent has no choice but to trust these origins.

Certain user agents extend this trust to other, vendor-specific URL schemes like app: or chrome-extension:.

Given an origin origin, the following algorithm returns Potentially Trusted or Not Trusted as appropriate.

1. If origin is a potentially secure origin, return Potentially Trusted.

   Note: The origin of blob: and filesystem: URLs is the origin of the context in which they were created. Therefore, blobs created in an potentially secure origin will themselves be potentially secure. The origin of data: and javascript: URLs is an opaque identifier, which will not be considered potentially secure.

2. If origin’s host component is localhost, return Potentially Trusted.
3. If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return Potentially Trusted.
4. If origin’s scheme component is file, return Potentially Trusted.
5. If origin’s scheme component is one which the user agent considers to be authenticated, return Potentially Trusted.

   Note: This is meant to cover vendor-specific URL schemes whose contents are authenticated by the user agent. For example, FirefoxOS application resources are referred to with an URL whose scheme component is app:. Likewise, Chrome’s extensions and apps live on chrome-extension: schemes. These could reasonably be considered trusted origins.

6. Return Not Trusted.