/admin/data/resource/1827362710289513.png

3.1 Active Content

Active content is content which can in some way directly manipulate the resource with which a user is interacting. Script and style are the clearest examples: if an attacker can manipulate either, she can completely control the activity on a webpage and exfiltrate data at will. Active content include the following resource types:

• 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

These resource types map to the following Fetch request contexts: script, worker, sharedworker, serviceworker, style, object, manifest and child. These contexts are active request contexts.

The contents of an iframe are considered active content because same-origin frames can reach up into their parent browsing context via script, and even cross-origin frames can initiate top-level navigations. User agents MAY decide to treat cross-origin frames as passive content if that capability is removed by applying a appropriate sandboxing flag set (e.g. one which does not include the allow-top-navigation flag).

Note: iframe elements, as currently implemented in user agents do come with risks beyond those mentioned above. For example, a downloaded file’s origin is often difficult to pinpoint, HTTP authentication prompts are sometimes allowed (after a HTTP 401 response, for instance), and modal prompts like window.prompt() can confuse users. These risks exist even with secure iframes, but attackers can more easily inject malicious code into innocent but insecure iframes.

Should form submissions to an insecure origin be considered active content? I suspect they should, though I’m not sure we can get away with it in a web-compatible way.

3.2 Passive Content

Passive content includes resources which cannot directly interact with or modify other resources on a page: images, fonts, audio, and video for example. The risk of rendering a manipulated passive resource is significantly lower than executing an active resource; passive content can confuse or deceive users, but cannot directly manipulate other resources on a page or exfiltrate data.

Active content is clearly dangerous in a mixed context, and must be blocked from executing in those contexts to protect both users and site authors, regardless of the risk of breaking insecurely composed websites. Passive mixed content is less directly dangerous to users: if an attacker manipulates an image resource, the worst case is that the attacker-controlled image is displayed to the user rather than the image a site’s author intended.

In a perfect world, user agents would be required to block all types of mixed content. Unfortunately, there exists a massive amount of passive mixed content on the Internet today: according to a survey in 2013 blocking passive mixed content would break around ~43% of secure websites in one way or another. Draconian blocking policies applied to passive mixed content are (for the moment) infeasible. User agents must be more nuanced in their restrictions.

With that in mind, we’ll split passive content into two categories: resources user agents can safely block without breaking the web, and resources whose usage in mixed contexts is simply too high to block by default.

Future versions of this specification will update these subcategories with the intent of moving towards a world where all mixed content is blocked; that is the end goal, but this is the best we can do for now.

Should the presence of a form with an action attribute representing an a priori insecure origin be considered passive mixed content?

{
  showLaunchButton: false
}

document.write("<script>" + xhr.responseText + "</script>");

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 an active request context when determining whether or not a request should be blocked as mixed content.

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 is a secure context, 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 active resources and blockable passive 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 active resources and blockable passive 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 passive resources which are mixed content SHOULD be treated as active (and therefore returned as a network error as described above).

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

4. Requests for optionally blockable passive resources which are mixed content, but which are not treated as active 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 is a secure context, 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 UI Requirements

If a request for optionally blockable passive resources which are mixed content is not treated as active content (per requirement #3 above), then the user agent MUST NOT provide the user with a visible indication that the top-level browsing context which loaded that resource is secure (for instance, via a green lock icon). The user agent SHOULD instead display a visible indication that mixed content is present.

This requirement explicitly includes any visible indication of the top-level browsing context’s EV status. [CAB]

4.4 User Controls

User agents MAY offer users the ability to directly decide whether or not to treat all mixed content as active (meaning that even optionally blockable passive content would be blocked in a mixed context).

Note: It is strongly recommended that users take advantage of such an option if provided.

User agents MAY offer users the ability to override its decision to block blockable passive mixed content on a particular page.

User agents MAY also offer users the ability to override its decision to block active mixed content on a page.

Note: Practically, user agents probably can’t get away with not offering such a back door. That said, allowing active mixed content is in particular a very dangerous option, and user agents REALLY SHOULD NOT present such a choice to users without careful consideration and communication of the risk involved.

5.1 Is environment a secure context?

Given a JavaScript global environment environment, the user agent determines whether environment is a secure context via the following algorithm, which returns true if environment is a secure context, and false otherwise.

1. If environment is TLS-protected, 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, 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 would be used as active 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 client be request’s client.
3. Let environment be the JavaScript global environment with which client is associated.
4. Let origin be the origin of request’s URL.
5. If origin is a private origin, and environment’s origin is a public origin, return blocked.
6. If environment is not a secure context, return allowed.
7. If origin is a priori insecure:
   1. If context is an active request context or blockable passive request context, return blocked.
   2. If the user agent is configured to block optionally blockable passive mixed content, return blocked.
8. 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 would be used as active 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 is not a secure context, return allowed.
4. Let context be the request context of request.
5. If context is an active request context or blockable passive request context, or the user agent is configured to block optionally blockable passive 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.

   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.