Verifying HTTPS Support

How To Determine the Browser Has Established a Secure Connection

Most browsers present a lock icon   (green in some browsers) to the left of the URL in the browser's address bar if a secure connection has been established. You should be able to click on the lock to view additional information. While the information provided appears to vary significantly at this time, most will at least tell you whether an encrypted/secure connection has been established and give you an option to get additional information about the certificate used to verify the site.

The behavior under other conditions is a little less consistent. In Firefox, an HTTP connection will simply not display the lock icon. An information icon   (which is also displayed to the left of the lock icon when the connection is secure) can still be clicked to provide additional information about the connection, at which time it will state the "Connection is not secure", but otherwise the only indication of this is the lack of the lock icon. Most other browsers will include the words "Not Secure" to the left of the URL.

If HTTPS is used but some content is served over HTTP, most browsers will still state "Not Secure" in the address bar, but Firefox will display a lock icon with a triangular warning sign superimposed over it, and the lock will be gray rather than green. Another possibility in Firefox would be a lock with a red line over it, which would indicate that there is potentially dangerous content on the page loaded via HTTP (this usually requires a configuration change, as the browser will refuse to load the page by default).

Content Requirements for a Secure Connection

In order for a connection to be considered secure, all of the content, scripts, and stylesheets used by the page must also be loaded over a secure connection. While the user experiences a webpage as a single piece of content possibly containing text, images, and interactive content, the browser experiences the page as a series of commands telling it where the content resides and providing it hints regarding how to present the content to the user. Each piece of content which resides at another location has to be requested by the browser, and each piece of content must be available over a secure connection in order for the browser to consider the connection secure for the webpage as a whole.

Most browsers split handling of external resources into two types of content: passive and active. Most of these elements use the src attribute to specify the external resource to be loaded (the link and object elements are the exceptions, using the href and data attributes, respectively). Most browsers will refuse to load some content over HTTP when included in a page loaded via HTTPS (the browser may be configured to omit all HTTP content when a page is loaded via HTTPS). The browser may take a more drastic approach (preventing the user from visiting the page, for instance) with some forms of active content.

Older browser versions may be less likely to block content under these conditions, or may not make it as obvious that the connection is not secure.

Passive content includes:

• Images
• Audio
• Video
• Object subresources (an object element loaded via HTTPS which attempts to make requests for additional resources via HTTP)

The browser can be configured to omit passive content, allowing the page to load and labelling the connection secure. The omitted content may be indicated in the browser's JavaScript console, but otherwise only a side-by-side comparison may indicate that content was not loaded.

If the browser is configured not to omit passive content, it may display the content but indicate that the connection is not secure.

Active content includes:

• JavaScript (including URLs called via XMLHttpRequest or fetch() request)
• Stylesheets (link elements and URL references via @font-face, cursor, background-image, etc.)
• IFrames
• Object elements with a data attribute using HTTP

Most active content will be blocked by default and browsers will present more significant warnings to users attempting to force the browser to load the content. If a script or stylesheet is blocked, it may drastically alter the appearance or contents of the page (depending on what that script or stylesheet was supposed to do on the page).

Permitted HTTP URLs

When a URL is not used to load content into the current page, it does not have to be an HTTPS URL for the page to be loaded over a secure connection. For example, a link/anchor (<a href="http://example.com">Example Link</a>) should use HTTPS if the destination page supports it, but the destination isn't loaded until the user follows the link, so it is not considered when determining whether the current page can be loaded over a secure connection.

URLs used in most contexts other than those listed above can be HTTP URLs, but once you have verified HTTPS support for your own site, you should always use HTTPS URLs when referencing your site's content. In Omni CMS, the best way to ensure this is to use dependency tags wherever possible to refer to pages/content on your own site and other sites within your account.