httphttpsmixed-contentsecure-context

Links to insecure pages from a secure page

I know that mixed content occurs when the initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, scripts) are loaded over an insecure HTTP connection. This is called mixed content because both HTTP and HTTPS content is being loaded to display the same page, and the initial request was secure over HTTPS.

Is it permissible for a secure page to contain links to external pages that are not secure? I am talking about links that navigate the user away from the secure page to a new but unsecured page. Content isn't being retrieved on the secure page so this is OK, right?

Solution

  • Yes, per the Mixed Content specification, which is the spec that defines the normative requirements for browsers with regard to potential mixed content, it is permissible for a secure page to contain links to external pages that are not secure.

    The specific relevant requirement is stated in step 4 of the first part of the “Should fetching request be blocked as mixed content?” section of the spec, which reads:

    Given a Request request, a user agent determines whether the Request request should proceed or not via the following algorithm:

    1. Return allowed if one or more of the following conditions are met:

      1. §5.1 Does settings prohibit mixed security contexts? returns "Does Not Restrict Mixed Security Contexts" when applied to request’s client.
      2. request’s url is a priori authenticated.
      3. The user agent has been instructed to allow mixed content, as described in §7.4 User Controls).
      4. 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.5 Further Action).

    To put it in other words, when a user follows a link to an external page, that action initiates a top-level navigation request, and per step 4 above, the algorithm returns allowed for that case, which means the request is permitted. (In cases that the spec defines as mixed content, the algorithm instead returns blocked, which means the request is not permitted.)

    Or to put it less-normative but more informative terms, browsers block requests for any of a page’s embedded subresources that are not served from a secure context, but they do not block navigations to other documents that are insecure.

    The relevant part of the Mixed Content specification that implicitly states behavior in those terms is in the Introduction:

    …when the encrypted and authenticated resource requests subresources (scripts, images, etc) over an insecure channel… Those resource requests result in a resource whose status is mixed