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 global environment restricts mixed content, then user agents MUST adhere to the following requirements when fetching resources in response to its requests (including not only requests for a Document’s subresources, but also requests made from Workers, SharedWorkers, ServiceWorkers and so on):

1. Requests for blockable resources from an a priori insecure origin MUST not generate network traffic, and MUST instead return a synthetically generated network error response.
2. Responses to requests for blockable resources from an insecure origin MUST not be delivered to the requesting global environment, but instead MUST return a synthetically generated network error response.
3. 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]

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

If a global environment’s origin is a public origin, then user agents MUST adhere to the following requirements when fetching resources in response to the environment’s requests:

1. Requests to private origins from public origins MUST not generate network traffic (including traffic on loopback interfaces), and MUST instead return a synthetically generated network error response.

§6 Integration with Fetch and §5 Algorithms detail how these fetching requirements could be implemented.

4.2 Script APIs

If a global environment restricts mixed content, then user agents MUST adhere to the following requirements when executing the following APIs:

1. When processing XMLHttpRequest’s open() method, throw a SecurityError exception and terminate the method’s execution if the request URL provided points to an a priori insecure origin. [XMLHTTPREQUEST]
2. When processing EventSource’s constructor, throw a SecurityError exception and terminate the constructor’s execution if the url provided points to an a priori insecure origin. [EVENTSOURCE]
3. When processing WebSocket’s constructor, throw a SecurityError exception and terminate the constructor’s execution if the url provided points to an a priori insecure origin. [WEBSOCKETS]

4.3 Form Submission

If a global environment restricts mixed content, then user agents MAY optionally 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 global environment which restricts mixed content as a request for blockable content to protect users from accidental data leakage.

5.1 Does environment restrict mixed content?

Given a JavaScript global environment environment, the user agent determines whether environment restricts mixed content via the following algorithm, which returns true if environment restricts mixed content, and false otherwise.

1. If environment is TLS-protected, and that TLS-protection is neither weak nor deprecated, then return true.
2. If environment is a nested browsing context, then:
   1. Let ancestorList be the list of all ancestors of environment’s browsing context.
   2. For each ancestorContext in ancestorList:
      1. Let ancestorEnvironment be the JavaScript global environment associated with ancestorContext
      2. If ancestorEnvironment is TLS-protected, and that TLS-protection is neither weak nor deprecated, then return true.
3. Return false.

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 client be request’s client.
4. Let environment be the JavaScript global environment with which client is associated.
5. Let origin be the origin of request’s URL.
6. If origin is a private origin, and environment’s origin is a public origin, return blocked.
7. If environment does not restrict mixed content, return allowed.
8. If request’s context frame type is top-level, return allowed.
9. 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.
10. 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. Let client be request’s client.
2. Let environment be the JavaScript global environment with which client is associated.
3. If environment does not restrict mixed content, return allowed.
4. Let context be the request context of request.
5. If context is an blockable request context or the user agent is configured to block optionally-blockable mixed content:
   1. If the response is not TLS-protected, return blocked.

      This is intended to cover cases in which a ServiceWorker responds to a request with an insecure resource. It’s not clear that this is the correct place to do that, however, as the integration with Fetch isn’t fully specified. It’s also not really clear what "insecure" should mean in a ServiceWorker context. We accept blob resources, for instance: should we accept responses synthesized by the service worker?

   2. If the response is only weakly TLS-protected, return blocked.

      Note: If a user agent is configured to reject weakly TLS-protected resources, we’ll never hit this condition, as step 6 of the Fetch algorithm would have returned a network error. [FETCH]

   3. If the response’s TLS-protection is deprecated, return blocked.

      Note: This covers 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.

6. Return allowed.

5.4 Is origin an authenticated origin?

Given an origin origin, this algorithm returns authenticated if the origin is an authenticated origin, and unauthenticated otherwise.

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

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

Note: Step #5 above 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 authenticated origins.

5.5 Is environment an authenticated environment?

Given a JavaScript global environment environment, this algorithm returns authenticated if the environment is an authenticated environment, and unauthenticated otherwise.

1. Let origin be the origin specified by environment’s entry settings object.
2. If environment is a document environment:
   1. Let document be the Document object of the active document of the browsing context of environment’s global object.
   2. While document corresponds to an iframe srcdoc Document, let document be that Document’s browsing context’s browsing context container’s Document.
   3. 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. Return the result of executing the §5.4 Is origin an authenticated origin? algorithm on origin.