A secure context is a Window or Worker for which there is reasonable confidence that the content has been delivered securely (via TLS), and for which the potential for communication with contexts that are not secure is limited. Many Web APIs and features are only accessible in a secure context. The primary goal of secure contexts is to prevent Man in the Middle attackers from accessing powerful APIs that could further compromise the victim of an attack.

Why should some features be restricted? 

Some APIs on the web are very powerful giving an attacker the ability to do the following and more:

  • Invade a user's privacy.
  • Get low level access to a user's computer.
  • Get access to data like user credentials.

When is a context considered secure?

A context will be considered secure when it's delivered securely (or locally), and when it cannot be used to provide access to secure APIs to a context that is not secure. In practice this means that for a page to have a secure context, it and all the pages along its parent and opener chain must have been delivered securely.

For example, a page delivered securely over TLS is not considered a secure context if it has a parent or ancestor document that was not delivered securely, since otherwise the page would then be able to expose sensitive APIs to the non-securely delivered ancestor via postMessage messages. Similarly, if a TLS delivered document is opened in a new window by an insecure context without noopener being specified then the opened window is not considered to be a secure context (since the opener and opened window could communicate via postMessage).

Locally delivered files such as http://localhost and file:// paths are considered to have been delivered securely.

Contexts that are not local must be served over https:// or wss:// and where the protocols used should not be considered deprecated. 

Feature detection

Pages can use feature detection to check whether they are in a secure context or not by using the isSecureContext boolean which is exposed on the global scope.

if (window.isSecureContext) {
  // Page is a secure context so service workers are now available
  navigator.serviceWorker.register("/offline-worker.js").then(function () {

What APIs require secure contexts?

Draft proposals


Some browsers may decide to opt for certain APIs into being secure context only despite the spec not requiring such a measure.

  Chrome Safari Firefox


Removed from in Chrome 47


Only temporary access (users can not choose "Remember this decision" in the permission request dialog).



Removed in Chrome 50


Removed here

Removal in progress

Expected removal in Firefox 55

EME Deprecation warning    
Device motion / orientation Deprecation warning    
MIDI Disabled    
Web Cryptography API is restricted to HTTPS however predates the Secure Context check.    

To check for latest browser support check http://permission.site

Note: Safari and Chrome don't support the full secure contexts specification so APIs may work when using HTTPS iframes inside a HTTP page or pages that have an 'opener context' with an insecure page (this happens when a HTTP page uses window.open or target="_blank").


Specification Status Comment
Secure Contexts Working Draft Editor’s Draft


See also


Document Tags and Contributors

 Last updated by: Jonathan_Watt,