Secure contexts
A secure context is an environment such as a Window or Worker which meets a defined standard of authentication and confidentiality. Many Web APIs and features are accessible only in a secure context.
The canonical definition of a secure context, along with the rationale for restricting some web platform features to secure contexts, is given in the Secure Contexts specification.
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 such as user credentials.
If these APIs were available to content that was not delivered over a secure connection, then a manipulator in the middle (MITM) attacker would be able to access them.
When is a context considered secure?
To a first approximation:
-
Documents are secure contexts when their resources are delivered over an HTTPS connection, or are delivered from a loopback (local) address. Framed documents must also be embedded in a document which is itself a secure context.
-
Workers are secure contexts when they are created by a secure context.
Top-level documents
Top-level documents provide a secure context when their URL is a potentially trustworthy URL.
For example:
| URL | Secure |
|---|---|
https://example.com |
✅ Secure (https URL) |
http://localhost |
✅ Secure (localhost URL) |
file:///path/to/resource.html |
✅ Secure (file URL) |
https://example.com |
❌ Not secure (http URL) |
Framed documents
Documents in an <iframe> provide a secure context when they are delivered from a potentially trustworthy URL, and are themselves embedded in a secure context.
The means that if a top-level document from http://example.com embeds an <iframe> whose document is https://example.com, then the embedded document is not a secure context.
| iframe URL | Parent document URL | Secure context |
|---|---|---|
https://example.com |
https://example.com |
✅ Secure |
http://example.com |
https://example.com |
❌ Not secure |
https://example.com |
http://example.com |
❌ Not secure |
Workers
Dedicated workers
Dedicated workers provide a secure context when their owner is a secure context.
Shared workers
Shared workers follow the same rules as dedicated workers.
In addition:
- If a shared worker is a secure context, then only other secure contexts may attach to it.
- If a shared worker is a non-secure context, then only other non-secure contexts may attach to it.
Service workers and worklets
Only secure contexts are allowed to register service workers, so service workers are always secure contexts.
Potentially trustworthy URLs
A URL is potentially trustworthy if any of the following apply:
- Its value is
about:blankorabout:srcdoc - Its scheme is
data - Its origin is a potentially trustworthy origin.
Potentially trustworthy origins
An origin is potentially trustworthy if has:
- A scheme of
https,wss, orfile. - A host value of
127.0.0.0/8or::1/128 - A host value of
localhostorlocalhost. - A host value ending with
.localhostor.localhost. - A scheme that the browser considers to be authenticated
This is essentially intended to capture: origins that use a secure transport across the network, local origins, and origins that the browser considers authenticated for some other reason (for example, those used by browser extensions).
Feature detection
Pages can check whether they are in a secure context or not by using the Window.isSecureContext or WorkerGlobalScope.isSecureContext property.
if (window.isSecureContext) {
// Page is a secure context so service workers are now available
navigator.serviceWorker.register("/offline-worker.js").then(() => {
// …
});
}
See also
- Platform features restricted to secure contexts — a list of the features available only in secure contexts
Window.isSecureContextandWorkerGlobalScope.isSecureContext- https://permission.site — A site that allows you to check what API permission checks your browser employs, over HTTP and HTTPS