Blocking FTP subresource loads within non-FTP documents in Firefox 61

Firefox 61 will block subresource loads that rely on the insecure FTP protocol unless the document itself is an FTP document. For example, Firefox will block FTP subresource loads within HTTP(S) pages.

The File Transfer Protocol (FTP) enables file exchange between computers on a network. While this standard protocol is supported by all major browsers and allows convenient file sharing within a network, it’s one of the oldest protocols in use today and has a number of security issues.

The fundamental underlying problem with FTP is that any data transferred will be unencrypted and hence sent across networks in plain text, allowing attackers to steal, spoof and even modify the data transmitted. To date, many malware distribution campaigns rely on compromising FTP servers, downloading malware on an end users device using the FTP protocol. Further, FTP makes HSTS protection somewhat useless, because the automated upgrading from an unencrypted to an encrypted connection that HSTS promises does not apply to FTP.

Following through to our intent to deprecate non-secure HTTP and aligning with Mozilla’s effort to improve adoption of HTTPS Firefox will block subresource loads, like images, scripts and iframes, relying on the insecure FTP protocol. Starting with Firefox 61, loading an FTP subresource within a non-FTP document will be blocked and the following message will be logged to the console:

For the Mozilla Security Team:
Tom Schuster and Christoph Kerschbaumer


Supporting Same-Site Cookies in Firefox 60

Firefox 60 will introduce support for the same-site cookie attribute, which allows developers to gain more control over cookies. Since browsers will include cookies with every request to a website, most sites rely on this mechanism to determine whether users are logged in.

Attackers can abuse the fact that cookies are automatically sent with every request to force a user to perform unwanted actions on the site where they are currently logged in. Such attacks, known as cross-site request forgeries (CSRF), allow attackers who control third-party code to perform fraudulent actions on the user’s behalf. Unfortunately current web architecture does not allow web applications to reliably distinguish between actions initiated by the user and those that are initiated by any of the third-party gadgets or scripts that they rely on.

To compensate, the same-site cookie attribute allows a web application to advise the browser that cookies should only be sent if the request originates from the website the cookie came from. Requests triggered from a URL different than the one that appears in the URL bar will not include any of the cookies tagged with this new attribute.

The same-site attribute can take one of two values: ‘strict’ or ‘lax’. In strict mode, same-site cookies will be withheld for any kind of cross-site usage. This includes all inbound links from external sites to the application. Visitors clicking on such a link will initially be treated as ‘not being logged in’ whether or not they have an active session with the site.

The lax mode caters to applications which are incompatible with these restrictions. In this mode, same-site cookies will be withheld on cross-domain subrequests (e.g. images or frames), but will be sent whenever a user navigates safely from an external site, for example by following a link.

For the Mozilla Security Team:
Christoph Kerschbaumer, Mark Goodwin, Francois Marier

Distrust of Symantec TLS Certificates

A Certification Authority (CA) is an organization that browser vendors (like Mozilla) trust to issue certificates to websites. Last year, Mozilla published and discussed a set of issues with one of the oldest and largest CAs run by Symantec. The discussion resulted in the adoption of a consensus proposal to gradually remove trust in all Symantec TLS/SSL certificates from Firefox. The proposal includes a number of phases designed to minimize the impact of the change to Firefox users:

  • January 2018 (Firefox 58): Notices in the Browser Console warn about Symantec certificates issued before 2016-06-01, to encourage site owners to replace their TLS certificates.
  • May 2018 (Firefox 60): Websites will show an untrusted connection error if they use a TLS certificate issued before 2016-06-01 that chains up to a Symantec root certificate.
  • October 2018 (Firefox 63): Distrust of Symantec root certificates for website server TLS authentication.

After the consensus proposal was adopted, the Symantec CA was acquired by DigiCert; however, that fact has not changed Mozilla’s commitment to implement the proposal.

Firefox 60 is expected to enter Beta on March 13th carrying with it the removal of trust for Symantec certificates issued prior to June 1st, 2016, with the exception of certificates issued by a few subordinate CAs that are controlled by Apple and Google. This change affects all Symantec brands including GeoTrust, RapidSSL, Thawte, and VeriSign. The change is already in effect in Firefox Nightly.

Mozilla telemetry currently shows that a significant number of sites – roughly 1% of the top one million – are still using TLS certificates that are no longer trusted in Firefox 60. While the number of affected sites has been declining steadily, we do not expect every website to be updated prior to the Beta release of Firefox 60. We strongly encourage operators of affected sites to take immediate action to replace these certificates.

If you attempt to visit a site that is using a TLS certificate that is no longer trusted in Firefox 60, you will encounter the following error:

Clicking on the “Advanced” button will allow you to bypass the error and reach the site:

These changes are expected to be included in the final version of Firefox 60 that is planned to be release on May 9th, 2018.

In Firefox 63, trust will be removed for all Symantec TLS certificates regardless of the date issued (with the exception of certificates issued by Apple and Google subordinate CAs as described above).

Wayne Thayer
Kathleen Wilson

Analysis of the Alexa Top 1M Sites

Prior to the release of the Mozilla Observatory in June of 2016, I ran a scan of the Alexa Top 1M websites. Despite being available for years, the usage rates of modern defensive security technologies was frustratingly low. A lack of tooling combined with poor and scattered documentation had led to minimal awareness around countermeasures such as Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), and Subresource Integrity (SRI).

Since then, a number of additional assessments have done, including in October 2016 and June 2017. Both of those surveys demonstrated clear and continual improvement in the state of internet security. But now that tools like the Mozilla Observatory, and Hardenize have become more commonplace, has the excitement for improvement been tempered?

February 2018 Scan

Technology June 2017 February 2018 % Change
(June 2017)
% Change
Content Security Policy (CSP) .018%2
Cookies (Secure/HttpOnly)4 6.50% 8.97% +38% +139%
Cross-origin Resource Sharing (CORS)5 96.55% 96.89% +.35% +3.3%
HTTPS 45.80% 54.31% +19% +83%
HTTP → HTTPS Redirection 14.38%6
Public Key Pinning (HPKP) 0.71% 1.07% +51% +148%
   — HPKP Preloaded8 0.43% 0.70% +63% +71%
Strict Transport Security (HSTS)9 4.37% 6.03% +38% +245%
   — HSTS Preloaded8 .337% .631% +87% +299%
Subresource Integrity (SRI) 0.113%10 0.182%11 +61% +1113%
X-Content-Type-Options (XCTO) 9.41% 11.72% +21% +89%
X-Frame-Options (XFO)12 10.98% 12.55% +14% +84%
X-XSS-Protection (XXSSP)13 8.12% 10.36% +28% +106%

Improvement across the web appears to be continuing at a steady rate. Although a 19% increase in the number of sites that support HTTPS might seem small, the absolute numbers are quite large — it represents over 83,000 websites, a slight slowdown from the previous survey’s 119,000 jump, but still a great sign of progress in encrypting the web’s long tail.

Not only that, but an additional 97,000 of the top websites have chosen to be HTTPS by default, with another 16,000 of them forbidding any HTTP access at all through the use of HTTP Strict Transport Security (HSTS). Also notable is the jump in websites that have chosen to opt into being preloaded in major web browsers, via a process known as HSTS preloading. Until browsers switch to HTTPS by default, HSTS preloading is the best method for solving the trust-on-first-use problem in HSTS.

Content Security Policy (CSP) — one of the most important recent advances due to its ability to prevent cross-site scripting (XSS) attacks — continues to see strong growth. Growth is faster in policies that ignore inline stylesheets (CSS), perhaps reflecting the difficulties that many sites have with separating their presentation from their content. Nevertheless, improvements brought about by specification additions such as 'strict-dynamic' and policy generators such as the Mozilla Laboratory continue to push forward CSP adoption.

Mozilla Observatory Grading

Despite this progress, the vast majority of top websites around the web continue not to use Content Security Policy, Strict Transport Security, or Subresource Integrity. As these technologies — when properly used — can nearly eliminate huge classes of attacks against sites and their users, they are given a significant amount of weight in Observatory scans.

As a result of their low usage rates amongst top websites, they typically receive failing grades from the Observatory:

Grade April 2016 October 2016 June 2017 February 2018 % Change
  A+ .003% .008% .013% .018% +38%
A .006% .012% .029% .011% -62%
B .202% .347% .622% 1.08% +74%
C .321% .727% 1.38% 2.04% +48%
D 1.87% 2.82% 4.51% 6.12% +36%
F 97.60% 96.09% 93.45% 90.73% -2.9%

We do see some significant improvements. As 976,930 scans were successfully completed in the last survey, a decrease in failing grades by 2.9% implies that over 27,000 of the top sites in the world have improved from a failing grade in the last eight months alone. Note that the drop in A grades is due to a recent change where extra credit points can no longer be used to move up to an A grade..

Thus far, over 140,000 websites around the web have directly used the Mozilla Observatory to improve their grades, indicated by making an improvement to their website after an initial scan. Of these 140,000 websites, over 2,800 have improved all the way from a failing grade to an A or A+ grade.

When I first built the Observatory at Mozilla, I had never imagined that it would see such widespread use. 6.6M scans across 2.3M unique domains later, it seems to have made a significant difference across the internet. I couldn’t have done it without the support of Mozilla and the security researchers who have helped to improve it.

Please share the Mozilla Observatory so that the web can continue to see improvements over the years to come!


  1. Since April 2016
  2. Allows 'unsafe-inline' in neither script-src nor style-src
  3. Allows 'unsafe-inline' in style-src only
  4. Amongst sites that set cookies
  5. Disallows foreign origins from reading the domain’s contents within user’s context
  6. Redirects from HTTP to HTTPS on the same domain, which allows HSTS to be set
  7. Redirects from HTTP to HTTPS, regardless of the final domain
  8. As listed in the Chromium preload list
  9. max-age set to at least six months
  10. Percentage is of sites that load scripts from a foreign origin
  11. Percentage is of sites that load scripts
  12. CSP frame-ancestors directive is allowed in lieu of an XFO header
  13. Strong CSP policy forbidding 'unsafe-inline' is allowed in lieu of an XXSSP header

Restricting AppCache to Secure Contexts

The Application Cache (AppCache) interface provides a caching mechanism that allows websites to run offline. Using this API, developers can specify resources that the browser should cache and make available to users offline. Unfortunately, AppCache has limitations in revalidating its cache, which allows attackers to trick the browser into never revalidate the cache by setting a manifest to a malformed cache file. Removing AppCache over HTTP connections removes the risk that users could see stale cached content that came from a malicious connection indefinitely.

Consider the following attack scenario: A user logs onto a coffee shop WiFi where an attacker can manipulate the WiFi that is served over HTTP. Even if the user only visits one HTTP page over the WiFi, the attacker can plant many insecure iframes using AppCache which allows the attacker to rig the cache with malicious content manipulating all of those sites indefinitely. Even a cautious user who decides only to login to their websites at home is at risk due to this stale cache.

In line with our previous stated intents of deprecating HTTP and requiring HTTPS for all new APIs, we are continuing to remove features from sites served over insecure connections. This means that websites wishing to preserve all their functionality should transition their sites to using TLS encryption as soon as possible.

In Firefox 60+ Beta and Nightly, Application Cache access from HTTP pages is denied. Starting with Firefox 62 Release, Application Cache over HTTP will be fully removed for all release channels. All other browsers have also stated their intent to remove: Chrome, Edge, WebKit. This change will also be reflected in the HTML standard.

Going forward, Firefox will deprecate more APIs over insecure connections in an attempt to increase adoption of HTTPS and improve the safety of the internet as a whole.

Preventing data leaks by stripping path information in HTTP Referrers

To help prevent third party data leakage while browsing privately, Firefox Private Browsing Mode will remove path information from referrers sent to third parties starting in Firefox 59.

Referrers can leak sensitive data

Screenshot of requests. Source: EFF

An example of personal health data being sent to third parties from Source: EFF

When you click a link in your browser to navigate to a new site, the new site you visit receives the exact address of the site you came from through the so-called “Referrer value”. For example, if you came to this Mozilla Security Blog from, the browser would send this:


This leaks user data to websites, telling websites the exact page you were looking at when you clicked the link. To make things worse, browsers also send a referrer value when requesting sub-resources, like ads, or other social media snippets integrated in a modern web site. In other words, embedded content also knows exactly what page you are visiting

Most sites log this data for operational and statistical purposes. Many sites also log this data to collect as much information about their users as possible.  They can then use that data for a variety of purposes, or even sell that data – e.g., for re-targeting.

While the data above may not be a problem, consider this example:

Referer: https://www.

EFF researchers discovered this leak of personal health data from to DoubleClick. As indicated, the referrer in this case leaks information about your age, your zip code, whether you are a smoker or not, and potentially even your income. Other companies (link1, link2) have disclosed similar vulnerabilities and leaks.

Private Browsing will strip paths in HTTP referrers

Screenshot: Firefox Private Browsing window

To prevent this type of data leakage when Firefox users are browsing privately, we are changing the way Firefox sends referrers in Private Browsing Mode.

Starting with Firefox 59, Private Browsing will remove path information from referrer values sent to third parties (i.e. technically, setting a Referrer Policy of strict-origin-when-cross-origin).

In the previous examples, this setting would remove the path and query string data from the referrer values so that they are stripped down to:




This change prevents site authors from accidentally leaking user data to third parties when their users choose Private Browsing Mode.  We made this change only after first ensuring that this would have minimal to no effect on web usability.

Other ways of controlling referrers

Vendors and authors continue to propose changes to Referrers to improve web privacy, security, and functionality.

In 2014, the W3C Web Application Security Working Group started its Referrer Policy Recommendation. This Policy lets vendors and authors control referrer values. For example, it defines a secure-by-default no-referrer-when-downgrade policy for user agents, which does not send referrers to HTTP resources from an HTTPS page. In Firefox Regular and Private Browsing Mode, if a site specifically sets a more restrictive or more liberal Referrer Policy than the browser default, the browser will honor the websites request since the site author is intentionally changing the value.

Users can also change their default referrer options in Firefox.  These will override the browser’s default Referrer Policy and override the site author’s Referrer Policy, putting the users choice first.


January 2018 CA Communication

Mozilla has sent a CA Communication to inform Certificate Authorities (CAs) who have root certificates included in Mozilla’s program about current events related to domain validation for SSL certificates and to remind them of a number of upcoming deadlines. This CA Communication has been emailed to the Primary Point of Contact (POC) and an email alias for each CA in Mozilla’s program, and they have been asked to respond to the following 6 action items:

  1. Disclose Use of Baseline Requirements Methods or for Domain Validation – Recently discovered vulnerabilities in these methods of domain validation have led Mozilla to require CAs to disclose their use of these methods and to describe how they have mitigated these vulnerabilities.
  2. Disclose Use of Methods or for Domain Validation – Significant concerns were recently raised about the reliability of these methods that are defined in the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.
  3. Disclose All Non-Technically-Constrained Subordinate CA Certificates – CAs have until April 15, 2018 to disclose all non-technically constrained subordinate CA certificates – including subordinate CA certificates that are constrained via EKU to S/MIME but do not have Name Constraints – as required by version 2.5 of Mozilla’s Root Store Policy.
  4. Complete BR Self Assessment – Mozilla has asked all CAs to complete a Baseline Requirements Self-Assessment by January 31, 2018, or by April 15, 2018 if an extension was requested.
  5. Update CP/CPS to Comply with version 2.5 of Mozilla’s Root Store Policy – In the November 2017 CA Communication, a number of CAs indicated that their CP/CPS does not yet comply with version 2.5 of the Mozilla Root Store Policy. The deadline for compliance has been extended to April 15, 2018.
  6. Reduce SSL Certificate Validity Periods to 825 Days or Less by March 1, 2018 – On March 17, 2017, in ballot 193, the CA/Browser Forum set a deadline of March 1, 2018 after which newly-issued SSL certificates must not have a validity period greater than 825 days, and the re-use of validation information must be limited to 825 days.

The full action items can be read here. Responses to the survey will be automatically and immediately published by the CCADB.

With this CA Communication, we reiterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve.

Mozilla Security Team

Secure Contexts Everywhere

Since Let’s Encrypt launched, secure contexts have become much more mature. We have witnessed the successful restriction of existing, as well as new features to secure contexts. The W3C TAG is about to drastically raise the bar to ship features on insecure contexts. All the building blocks are now in place to quicken the adoption of HTTPS and secure contexts, and follow through on our intent to deprecate non-secure HTTP.

Requiring secure contexts for all new features

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.

Requiring secure contexts in standards development

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 Secure Contexts specification.

Exceptions to requiring secure contexts

There is room for exceptions, provided justification is given to the dev.platform mailing list. This can either be inside the “Intent to Implement/Ship” email 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:

  • other browsers already ship the feature insecurely
  • it can be demonstrated that requiring secure contexts results in undue implementation complexity.

Secure contexts and legacy features

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 guidelines for removing features as appropriate.

Developer tools and support

To determine whether features are available developers can rely on feature detection. E.g., by using the @supports at-rule in CSS. This is recommend over the self.isSecureContext API as it is a more widely applicable pattern.

Mozilla will provide developer tools to ease the transition to secure contexts and enable testing without an HTTPS server.

Mitigations landing for new class of timing attack

Several recently-published research articles have demonstrated a new class of timing attacks (Meltdown and Spectre) that work on modern CPUs.  Our internal experiments confirm that it is possible to use similar techniques from Web content to read private information between different origins.  The full extent of this class of attack is still under investigation and we are working with security researchers and other browser vendors to fully understand the threat and fixes.  Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox.  This includes both explicit sources, like, and implicit sources that allow building high-resolution timers, viz., SharedArrayBuffer.

Specifically, in all release channels, starting with 57:

  • The resolution of will be reduced to 20µs. (UPDATE: see the MDN documentation for for up-to-date precision information.)
  • The SharedArrayBuffer feature is being disabled by default.

Furthermore, other timing sources and time-fuzzing techniques are being worked on.

In the longer term, we have started experimenting with techniques to remove the information leak closer to the source, instead of just hiding the leak by disabling timers.  This project requires time to understand, implement and test, but might allow us to consider reenabling SharedArrayBuffer and the other high-resolution timers as these features provide important capabilities to the Web platform.

Update [January 4, 2018]: We have released the two timing-related mitigations described above with Firefox 57.0.4, Beta and Developers Edition 58.0b14, and Nightly 59.0a1 dated “2018-01-04” and later. Firefox 52 ESR does not support SharedArrayBuffer and is less at risk; the mitigations will be included in the regularly scheduled Firefox 52.6 ESR release on January 23, 2018.

Blocking Top-Level Navigations to data URLs for Firefox 59

End users rely on the address bar of a web browser to identify what web page they are on. However, most end users are not aware of the concept of a data URL which can contain a legitimate address string making the end user believe they are browsing a particular web page. In reality, attacker provided data URLs can show disguised content tricking end users into providing their credentials. The fact that the majority of end users are not aware that data URLs can encode untrusted content makes them popular amongst scammers for spoofing and particularly for phishing attacks.

To mitigate the risk that Firefox users are tricked into phishing attacks by malicious actors encoding legitimate address strings in a data URL, Firefox 59 will prevent web pages from navigating the top-level window to a data URL and hence will prevent stealing an end user’s credentials. At the same time, Firefox will allow navigations to data URLs that truly result because of any end user action.

In more detail, the following cases will be blocked:

  • Web page navigating to a new top-level data URL document using:
    • window.location = “data:…”
    • clicking <a href=”data:…”> (including ctrl+click, ‘open-link-in-*’, etc).
  • Web page redirecting to a new top-level data URL document using:
    • 302 redirects to “data:…”
    • meta refresh to “data:…”
  • External applications (e.g., ThunderBird) opening a data URL in the browser

Whereas the following cases will be allowed:

  • User explicitly entering/pasting “data:…” into the address bar
  • Opening all plain text data files
  • Opening “data:image/*” in top-level window, unless it’s “data:image/svg+xml”
  • Opening “data:application/pdf” and “data:application/json”
  • Downloading a data: URL, e.g. ‘save-link-as’ of “data:…”

Starting with Firefox 59, web pages attempting to navigate the top-level window to a data URL will be blocked and the following message will be logged to the console:

For the Mozilla Security Team:
Christoph Kerschbaumer