larlet-fr-david-cache/cache/e41a3e7efc9c3285a60057987e86f9cd/index.md

title: Secure Contexts Everywhere
url: https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
hash_url: e41a3e7efc9c3285a60057987e86f9cd

<p>Since <a href="https://letsencrypt.org/">Let’s Encrypt</a> launched, <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts">secure contexts</a> have become much more mature. We <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">have witnessed</a> the successful restriction of existing, as well as new features to secure contexts. The W3C TAG is about to <a href="https://github.com/w3ctag/design-principles/pull/75">drastically raise the bar to ship features on insecure contexts</a>. All the building blocks are now in place to quicken the adoption of HTTPS and secure contexts, and follow through on our intent to <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/">deprecate non-secure HTTP</a>.</p>
<h2>Requiring secure contexts for all new features</h2>
<p>Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts.</p>
<h2>Requiring secure contexts in standards development</h2>
<p>Everyone involved in standards development is strongly encouraged to advocate requiring secure contexts for all new features on behalf of Mozilla. Any resulting complication should be raised directly against the <a href="https://w3c.github.io/webappsec-secure-contexts/">Secure Contexts</a> specification.</p>
<h2>Exceptions to requiring secure contexts</h2>
<p>There is room for exceptions, provided justification is given to the <a href="https://lists.mozilla.org/listinfo/dev-platform">dev.platform mailing list</a>. This can either be inside the <a href="https://wiki.mozilla.org/WebAPI/ExposureGuidelines">“Intent to Implement/Ship” email</a> or a separate dedicated thread. It is up to Mozilla’s Distinguished Engineers to judge the outcome of that thread and ensure the dev.platform mailing list is notified. Expect to be granted an exception if:</p>
<ul>
<li>other browsers already ship the feature insecurely</li>
<li>it can be demonstrated that requiring secure contexts results in undue implementation complexity.</li>
</ul>
<h2>Secure contexts and legacy features</h2>
<p>Features that have already shipped in insecure contexts, but are deemed more problematic than others from a security, privacy, or UX perspective, will be considered on a case-by-case basis. Making those features available exclusively to secure contexts should follow the <a href="https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guidelines_for_removing_features">guidelines for removing features</a> as appropriate.</p>
<h2>Developer tools and support</h2>
<p>To determine whether features are available developers can rely on <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection">feature detection</a>. E.g., by using the <code><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/%40supports">@supports</a></code> at-rule in CSS. This is recommend over the <code><a href="https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/isSecureContext">self.isSecureContext</a></code> API as it is a more widely applicable pattern.</p>
<p>Mozilla <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1410365">will provide developer tools</a> to ease the transition to secure contexts and enable testing without an HTTPS server.</p>