diff --git a/src/content/en/2025/security.md b/src/content/en/2025/security.md index a766db1ba55..d041d8ed8ab 100644 --- a/src/content/en/2025/security.md +++ b/src/content/en/2025/security.md @@ -11,7 +11,7 @@ translators: [] GJFR_bio: Gertjan Franken is a postdoctoral researcher with the DistriNet Research Group at KU Leuven. His research spans various aspects of web security and privacy, with a primary focus on the automated analysis of browser security policies. As part of this research, he maintains the open-source tool BugHog for pinpointing bug lifecycles. vikvanderlinden_bio: Vik Vanderlinden is a PhD candidate in Computer Science at the DistriNet Research Group at KU Leuven. His research focuses on web and network security, primarily focusing on timing leaks in web applications and protocols. results: https://docs.google.com/spreadsheets/d/1TLYRfNRbFu4fWwWvG4zhcRXkQ8-aZTxszgsEWjYATpA/edit -featured_quote: This security chapter shows positive trends in the adoption of web security policies. Despite these positive trends, developers must remain vigilant when adoption security mechanisms. Due to the growing complexity of the many available security mechanisms, we saw growth in the number of misconfigurations on the web. Policy makers will have to focus on reducing complexity in these new mechanisms to avoid developer confusion. +featured_quote: This security chapter shows positive trends in the adoption of web security policies. Despite these positive trends, developers must remain vigilant when leveraging these security mechanisms. Due to the growing complexity of the many available security mechanisms, we saw growth in the number of misconfigurations on the web. Policy makers will have to focus on reducing complexity in these new mechanisms to avoid developer confusion. featured_stat_1: 98.8% featured_stat_label_1: Percentage of requests that use HTTPS featured_stat_2: 84% @@ -22,7 +22,7 @@ featured_stat_label_3: Increase in the adoption of the Permissions Policy ## Introduction -While more and more parts of many people's lives have moved online, so does their private data, which makes web security ever more important. Many systems we use on a daily basis remain appealing to attackers trying to steal data or cause disruptions. This year has once more demonstrated the scale complexity of modern threats. The number of DDoS attacks have continued to increase in size and frequency, with the largest attack recorded reaching 31.4 Tbps in November. Supply chain vulnerability grew to unprecedented sizes, with the Shai-Hulud 2.0 attack reportedly compromising over 1,000 npm packages and infecting over 27,000 GitHub repositories. And a critical vulnerability in React known as React2Shell had developers working hard to quickly update their applications. +While more and more parts of many people's lives have moved online, so does their private data, which makes web security ever more important. Many systems we use on a daily basis remain appealing to attackers trying to steal data or cause disruptions. This year has once more demonstrated the scale and complexity of modern threats. The number of DDoS attacks have continued to increase in size and frequency, with the largest attack recorded reaching 31.4 Tbps in November. Supply chain vulnerability grew to unprecedented sizes, with the Shai-Hulud 2.0 attack reportedly compromising over 1,000 npm packages and infecting over 27,000 GitHub repositories. And a critical vulnerability in React known as React2Shell had developers working hard to quickly update their applications. In this chapter, we analyze the mechanisms that aim to protect the web, and how in some cases they fail to protect the web due to a variety of reasons. We explore core elements of web security such as Transport Layer Security (TLS) and protections against third-party content inclusions. We discuss how the adoption of these security measures evolves, how they help prevent attacks and how misconfigurations can prevent their proper functioning. We further analyze some well-known URIs relating to security. @@ -102,7 +102,7 @@ Contrary to our expectations, we see a relatively low number of requests that ar ### Certificate Authorities -In order to use TLS, sites must request a certificate from a Certificate (CA)Authority. Because the browser trusts a number of CAs, site's certificate can be identified by the browser as a valid certificate. The certificate can then be used for secure communication between the browser and the site's server going forward. +In order to use TLS, sites must request a certificate from a Certificate Authority (CA). Because the browser trusts a number of CAs, a site's certificate can be identified by the browser as a valid certificate. The certificate can then be used for secure communication between the browser and the site's server going forward.
@@ -179,7 +179,7 @@ Compared to last year, we can see that the then popular R3 intermediate certific sql_file="tls_ca_issuers_pages.sql", ) }} -The total share of sites using a certificate of Let's Encrypt has gone down slightly to 52.6% from 56% in the last edition. One of the contributing factors as can be seen in the data is the larger share of certificates issued by the WE1 certificate from GTS, although the total share by GTS-issued certificates (WE1 and others) has not been calculated. +The total share of sites using a certificate from Let's Encrypt has gone down slightly to 52.6% from 56% in the last edition. One of the contributing factors, as can be seen in the data, is the larger share of certificates issued by the WE1 certificate from GTS. However, the total share by GTS-issued certificates (WE1 and others) has not been calculated. ### HTTP Strict Transport Security @@ -193,9 +193,9 @@ The total share of sites using a certificate of Let's Encrypt has gone down slig sql_file="hsts_attributes.sql", ) }} -We see a continuing increase in the number of pages using a HSTS header, with a rise of 6 percentage points [compared to last edition](../2024/security#fig-8), up to 36% of all pages visited on mobile. +We see a continuing increase in the number of pages using an HSTS header, with a rise of 6 percentage points [compared to last edition](../2024/security#fig-8), up to 36% of all pages visited on mobile. -Servers can include a number of directives in the header to communicate additional preferences to the browser. The `max-age` directive that tells the browser for how long to continue only using HTTPS is required, the others are optional. +Servers can include a number of directives in the header to communicate additional preferences to the browser. For example, the `max-age` directive tells the browser how long it is required to continue using only HTTPS. The other directives, `includeSubDomains` and `preload`, are optional. {{ figure_markup( image="hsts-directives.png", @@ -207,7 +207,7 @@ Servers can include a number of directives in the header to communicate addition ) }} -The share of responses with a valid `max-age` has increased slightly to 96%. The `includeSubdomains` and `preload` directives saw an increase of about 4% each, possibly indicating that certain sites started setting both directives together. The [unofficial](https://developer.mozilla.org/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security) `preload` directive requires the `includeSubdirectories` to be set and the `max-age` to have a value of at least 1 year. Using the preload, a site can make sure that a browser will always visit the domain and its subdomains, even when connecting for the first time (which is not necessarily the case when using HSTS without preload). +The share of responses with a valid `max-age` has increased slightly to 96%. The `includeSubdomains` and `preload` directives saw an increase of about 4% each, possibly indicating that certain sites started setting both directives together. The [unofficial](https://developer.mozilla.org/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security) `preload` directive requires the `includeSubdirectories` to be set and the `max-age` to have a value of at least 1 year. When using the `preload` directive, a site can make sure that a browser will always visit the domain and its subdomains over HTTPS, even when connecting for the first time (which is not necessarily the case when using HSTS without preload). {{ figure_markup( image="hsts-max-age.png", @@ -223,17 +223,17 @@ The distribution of valid `max-age` values remains largely the same with the exc ## Cookies -Cookies are a vital part of the web. They allow websites to save information for use over multiple stateless requests. In order to secure sites' cookies, there are many features built into browsers that (among much more) are reported on in the [Cookies chapter](./cookies). We specifically refer to the [Cookie attributes](./cookies#cookie-attributes), [Cookie prefixes](./cookies#cookie-prefixes) and [Persistence (expiration)](./cookies#persistence-expiration) sections. +Cookies are a vital part of the web. They allow websites to save information for use over multiple stateless requests. In order to secure sites' cookies, there are many features built into browsers that are further reported on in the [Cookies](./cookies) chapter. We specifically refer to the [Cookie attributes](./cookies#cookie-attributes), [Cookie prefixes](./cookies#cookie-prefixes) and [Persistence (expiration)](./cookies#persistence-expiration) sections in this chapter. ## Content inclusion -Content inclusion is a core component of the web. Being able to include other pages, CSS or JavaScript from a [Content Distribution Network (CDN)](./cdn) or images from shared sources is one of the building blocks on which the web was built. It does however introduce certain risks: whenever sites include content from third parties, it places trust in those third-party resources. Of course, there is no guarantee that said resource is not malicious or compromised by a malicious actor which can lead to a number of serious attacks such as for instance supply chain attacks. To reduce this risk, it is important to use security policies to control content inclusion. +Content inclusion is a core component of the web. Being able to include other pages, CSS or JavaScript from a [Content Distribution Network (CDN)](./cdn) or images from shared sources is one of the building blocks on which the web was built. It does however introduce certain risks such as sites including content from third parties which places significant trust in those third-party resources. Of course, there is no guarantee that said resource is not malicious or compromised by a malicious actor which can lead to a number of serious attacks such as supply chain attacks. To reduce this risk, it is important to use security policies to control content inclusion. ### Content Security Policy -The [Content Security Policy (CSP)](https://developer.mozilla.org/docs/Web/HTTP/CSP) allows websites to have a fine-grained control over the content that will be loaded on its page. By setting the `Content-Security-Policy` response header or defining it in a `` html tag, websites can communicate the policy in use to the browser, which will enforce it. The policy has many defined directives that allow a website to define from which sources content can be loaded or not. +The [Content Security Policy (CSP)](https://developer.mozilla.org/docs/Web/HTTP/CSP) allows websites to have fine-grained control over the content that will be loaded on its page. By setting the `Content-Security-Policy` response header or defining it in a `` html tag, websites can communicate the policy in use to the browser, which will enforce it. The policy has many available directives that allow a website to define from which sources content can be loaded or not. -CSP can be used to block specific resources from being loaded, which can help reduce the impact of potential XSS attacks. In addition CSP can also serve other purposes, such as enforcing the use of encrypted communication channels by means of the `update-insecure-requests` directive or controlling on which pages the current page can be loaded as a subresource using the `frame-ancestors` directive. This allows websites to defend against clickjacking attacks. +CSP can be used to block specific resources from being loaded, which can help reduce the impact of potential cross-site scripting (XSS) attacks. In addition CSP can also serve other purposes, such as enforcing the use of encrypted communication channels by means of the `update-insecure-requests` directive or controlling on which pages the current page can load as a subresource using the `frame-ancestors` directive. This allows websites to defend against clickjacking attacks. {{ figure_markup( content="+18%", @@ -257,7 +257,7 @@ The adoption of CSP continued increasing [from 18.5% last year](../2024/security ) }} -Once again, most websites use CSP for the `upgrade-insecure-requests` and `frame-ancestors` directives. The relative share of mobile sites using these directives has decreased slightly, which can be attributed to the higher number of CSP headers scanned, as the absolute number has risen by 400,000 and 800,000 CSP headers on desktop and mobile respectively. +Once again, most websites use CSP for the `upgrade-insecure-requests` and `frame-ancestors` directives. The relative share of mobile sites using these directives has decreased slightly, which can be attributed to the higher number of CSP headers scanned. The absolute number has risen by 400,000 and 800,000 CSP headers on desktop and mobile respectively. The `block-all-mixed-content` directive which has been replaced by `upgrade-insecure-requests` has continued to slightly decrease like it has been over the last few years. This is good news because the directive is [deprecated](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/block-all-mixed-content). @@ -340,7 +340,7 @@ Compared to [last year](../2024/security#keywords-for-script-src) we barely see ) }} -We also check the use of keywords per header instead of per page. In CSP, multiple CSP headers can be present in one response and may define different directives. If a directive is defined multiple times, the policies will be combined to create the the most restrictive policy will be used by the browser. +We also check the use of keywords per header instead of per page. In CSP, multiple CSP headers can be present in one response and may define different directives. If a directive is defined multiple times, the policies will be combined to create the the most restrictive policy to be used by the browser. We see a very similar distribution compared to the values per request, indicating that either most pages only use one CSP header or only use `script-src` in one of the CSP headers that they set, meaning there are no conflicting `script-src` directives on most pages. @@ -358,7 +358,7 @@ CSP is a complex security policy to thoroughly understand and correctly use. Whe ) }} -Out of all observed headers, 75% are 86 bytes or less in length. This is slightly more than last year where this was 75 bytes or less. We can see that there are more longer policies in use and in the 90th percentile, the desktop policies have gotten longer while the mobile policies have gotten slightly shorter, increasing the difference between the policy lengths. +Out of all observed headers, 75% are 86 bytes or less in length. This is slightly more than last year where this was 75 bytes or less. We can see that there are more longer policies in use and in the 90th percentile. The desktop policies have gotten longer while the mobile policies have gotten slightly shorter, increasing the difference between the policy lengths.
@@ -495,7 +495,7 @@ The most commonly loaded HTTPS origins included in CSP headers are those used fo For the secure websocket (`wss://`) origins, we see Hotjar take the first position, doubling in occurrences. Other origins remain low in occurrence. -Hotjar is used for website analytics, indicating a continuing interest in analytical information of websites. Intercom is used for customer services. We also see AI-first companies entering these statistics with karakuri, a Japanese AI company that is closing the top three. +Hotjar is used for website analytics, indicating a continuing interest in analytical information of websites while Intercom is used for customer services. We also see AI-first companies entering these statistics with karakuri, a Japanese AI company that is closing the top three. ### Subresource Integrity @@ -588,7 +588,7 @@ The risk of including a script that is hosted on a server not under your own con ### Permissions Policy -The [Permissions Policy](https://developer.mozilla.org/docs/Web/HTTP/Permissions_Policy) (formerly Feature Policy) is a policy that allows websites to allow or disallow the use of specific features in the browser, such as the camera, microphone, sensors like the accelerometer or geolocation data. Through the `Permissions-Policy` response header, developers can allow or disallow specific feature use by the main page and its embedded content. A specific policy for one embedded resource can be set through the `allow` attribute of the ` ``` -We see the use of the sandbox attribute rise compared to the 2024 edition: The percentage of iframes with a sandbox attribute rose from 20.0% to 22.7%, showing that more and more developers want to protect their users against potential misuse by embedded content. +We see the use of the sandbox attribute rise compared to the 2024 edition from 20.0% to 22.7%, showing that more and more developers want to protect their users against potential misuse by embedded content. {{ figure_markup( image="iframe-sandbox-directives.png", @@ -774,7 +774,7 @@ In general we see a rise in most of the existing security features such as TLS, Document Policy is a draft community group report last updated in 2022. It was originally created as a response to proposed additions to Permissions Policy that did not fit the Permissions Policy model or added too much complexity. -Document Policy has several advantages over related mechanisms such as Permissions Policy, CSP and sandboxing: It is more fine-grained than Permissions Policy and has a different inheritance model: child resources can overwrite certain parent-chosen policies if they are compatible. It is more general than CSP: It has directives related to the permissions of a resource once it has been loaded instead of only determining from which origins resources can be loaded and it is easier to extend than sandboxing because features that are not mentioned in sandboxing are blocked by default, which makes it very difficult to add new ones. +Document Policy has several advantages over related mechanisms such as Permissions Policy, CSP and sandboxing. It is more fine-grained than Permissions Policy and has a different inheritance model: child resources can overwrite certain parent-chosen policies if they are compatible. It is more general than CSP as it has directives related to the permissions of a resource once it has been loaded instead of only determining from which origins resources can be loaded. It is easier to extend than sandboxing because features that are not mentioned in sandboxing are blocked by default, which makes it very difficult to add new ones.
@@ -816,13 +816,13 @@ Document Policy has several advantages over related mechanisms such as Permissio
{{ figure_link(caption="Most common document policy header values", sheets_gid="1931592953", sql_file="documentpolicy_most_common_header.sql") }}
-We can see that of the Document Policy headers in use, more than two thirds of them are used to include call stacks in crash reports. Combined with the `js-profiling` directive these two features make up the vast majority of current use-cases. Currently in total we find policy values containing 19 different directives, in general there may be more defined but as of now we are not aware of the total number of directives that are defined. +We can see that of the Document Policy headers in use, more than two thirds of them are used to include call stacks in crash reports. Combined with the `js-profiling` directive these two features make up the vast majority of current use-cases. Currently in total we find policy values containing 19 different directives. In general there may be more directives defined but as of now we are not aware of the total number them. -While we currently only find just over 24,000 and 29,500 pages for desktop and mobile respectively which is 0.10% of the total number of pages visited for both. We expect to see a rise in adoption of Document Policy headers going forward, although future adoption may not happen quickly. +We currently only find just over 24,000 and 29,500 pages for desktop and mobile respectively which is 0.10% of the total number of pages visited for both. We expect to see a rise in adoption of Document Policy headers going forward, although future adoption may not happen quickly. ## Attack preventions -While there are many defenses for websites implemented by many browsers, it can be challenging to keep an overview of all the possibilities and best-practices. In addition, when protections are opt-in and therefore not enabled by default, it becomes even more of a challenge. Developers have to remain up to speed with modern attacks and the defenses that exist to protect users against these attacks. This section assesses which attack prevention measures are in use across the web. +While there are many defenses for websites implemented by many browsers, it can be challenging to keep an overview of all the possibilities and best practices. In addition, when protections are opt-in and therefore not enabled by default, it becomes even more of a challenge. Developers have to remain up to speed with modern attacks and the defenses that exist to protect users against these attacks. This section assesses which attack prevention measures are in use across the web. ### Security header adoption @@ -844,7 +844,7 @@ The strongest risers since the 2024 edition are `Strict-Transport-Security` (+4. #### `Origin-Agent-Cluster` -The [`Origin-Agent-Cluster`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Origin-Agent-Cluster), when correctly set, communicates to the browser a request to share the resources used for the document (like the operating system process) with documents of the same origin. the browser may or may not honor the request and the client can verify using JavaScript whether the request was in fact honored. +The [`Origin-Agent-Cluster`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Origin-Agent-Cluster), when correctly set, communicates to the browser a request to share the resources used for the document (like the operating system process) with documents of the same origin. The browser may or may not honor the request and the client can verify using JavaScript whether the request was in fact honored. Usage remains low with only 0.47% of mobile sites, and 0.38% desktop sites using this, but let's dig into what they are using it for: @@ -887,7 +887,7 @@ A boolean is -We see that less than 0.5% of websites on desktop and mobile are using the `document.domain` setter to change the origin of a page and even less sites do so with a non-default port. This is a positive trend but still represents a few tens of thousand website, which should update their code. +We see that less than 0.5% of websites on desktop and mobile are using the `document.domain` setter to change the origin of a page and even less sites do so with a non-default port. This is a positive trend but still represents a few tens of thousands of websites that should update their code. ### Preventing clickjacking with CSP and X-Frame-Options As previously mentioned, a Content Security Policy (CSP) can be effective against Clickjacking attacks through the use of the `frame-ancestors` directive. Some of the top CSP header values include a `frame-ancestors` directive with a `'none'` or `'self'` value, thereby blocking embedding of the page overall or restricting the embeddings to pages of the same origin. -Another way of defending against clickjacking attacks is through the [`X-Frame-Options` (XFO)](https://developer.mozilla.org/docs/Web/HTTP/Headers/X-Frame-Options) header. By setting the XFO developers can communicate that a document cannot be embedded in other documents ('DENY') or can only be embedded in documents of the same origin (`SAMEORIGIN`). +Another way of defending against clickjacking attacks is through the [`X-Frame-Options` (XFO)](https://developer.mozilla.org/docs/Web/HTTP/Headers/X-Frame-Options) header. By setting the XFO header, developers can communicate that a document cannot be embedded in other documents ('DENY') or can only be embedded in documents of the same origin (`SAMEORIGIN`).
@@ -983,7 +983,7 @@ Examples of other values we observe are shown in the third to fifth row of the t ### Preventing attacks using Cross-Origin policies -Because of the emergence of microarchitectural side-channel attacks like Spectre and Meltdown and Cross-Site Leaks (XS-Leaks), our security perspective relating to use and embeddings of cross-origin resources has changed. In response to these upcoming threats, new mechanisms to control the rendering of resources on other websites and thereby protect against these new threats were created. +Because of the emergence of microarchitectural side-channel attacks like Spectre and Meltdown and Cross-Site Leaks (XS-Leaks), our security perspective relating to use and embeddings of cross-origin resources has changed. In response to these threats, new mechanisms were created to control the rendering of resources on other websites and thereby protect against these new threats. Multiple new security headers, known as the cross-origin policies, were created as a response to these challenges: Cross-Origin-Resource-Policy (CORP), Cross-Origin-Embedder-Policy (COEP) and Cross-Origin-Opener-Policy (COOP). These headers provide mechanisms that protect against side-channel attacks by allowing developers to control how their resources are embedded across different origins. We observe that the adoption of all of these headers keeps growing year after year, with both CORP and COOP reaching over 2% adoption this year. @@ -1041,7 +1041,7 @@ For `credentialless`, the browser will allow cross-origin requests in `no-cors` Related to COEP, the [Cross-Origin-Resource-Policy (CORP)](https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy) does not enforce which content can be embedded in the current document, but rather from which documents the current content can be accessed. -The only three possible values are `cross-origin`, `same-origin` and `same-site`. The `cross-origin` value allows any document to access the resource., while the `same-origin` and `same-site` restrict which documents can access the resource to the documents in the same origin or site respectively. Developers should be aware of the [difference between the origin (scheme, host, port) and site (registerable domain)](https://web.dev/articles/url-parts). If the header is present, requests with a mode of `no-cors` will be blocked by the browser. +The only three possible values are `cross-origin`, `same-origin` and `same-site`. The `cross-origin` value allows any document to access the resource, while the `same-origin` and `same-site` values restrict which documents can access the resource to the documents in the same origin or site respectively. Developers should be aware of the [difference between the origin (scheme, host, port) and site (registerable domain)](https://web.dev/articles/url-parts). If the header is present, requests with a mode of `no-cors` will be blocked by the browser.
@@ -1077,7 +1077,7 @@ In most cases, the header is used to allow access to any cross-origin resource. #### Cross Origin Opener Policy -The final cross-origin policy header, [Cross-Origin-Opener-Policy (COOP)](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) allows a developer to control how other pages can reference their page when opening it through for instance the `window.open` API. +The final cross-origin policy header, [Cross-Origin-Opener-Policy (COOP)](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) allows a developer to control how other pages can reference their page when opening it through browser APIs such as `window.open`. The default value of `unsafe-none` allows the COOP protection to be disabled, which is also what happens when the header is absent. If a developer uses `window.open` to open a page which uses `unsafe-none`, they can use the returned value to access certain properties of the opened page, which can lead to Cross-Site Leaks. @@ -1130,7 +1130,7 @@ In order to access certain sensitive APIs like `SharedArrayBuffer` or `Performan Using the [`Clear-Site-Data`](https://developer.mozilla.org/docs/Web/HTTP/Headers/Clear-Site-Data) HTTP response header, developers are able to instruct the client to clear browsing data. The value of the header specifies which type or types of data should be cleared. This can be useful when a user logs out of the website, so the developer can be sure that any authentication cookies are most assuredly cleared. -It is difficult to estimate the adoption of `Clear-Site-Data` correctly as its use is usually most valuable when logging out users. The crawler does not log in onto websites and therefore can also not log out to check how many sites use the header after logout. For now, we see 2,024 mobile hosts using the `Clear-Site-Data` header, which is only 0.01% of the total number of hosts crawled. +It is difficult to estimate the adoption of `Clear-Site-Data` correctly as its use is usually most valuable when logging out users. The crawler we use does not log into websites and therefore can also not log out to check how many sites use the header after logout. For now, we see 2,024 mobile hosts using the `Clear-Site-Data` header, which is only 0.01% of the total number of hosts crawled.
@@ -1203,7 +1203,7 @@ We see these numbers jump quite a lot year after year, which can likely be expla ### Preventing attacks using `` -Besides as a response header, some of the security mechanisms of the web can be configured directly within the html document through the use of the `` tag. Two examples of this are the `Content-Security-Policy` and the `Referrer-Policy`. The use of a meta tag for these mechanisms has remained largely stable from [last year](../2024/security#preventing-attacks-using-meta), at around 0.60% and around 2.50% for the CSP and Referrer-Policy respectively. A very small decrease in CSP and very small increase in Referrer-Policy could be observed, just like last year. +Besides being set via response headers, some of the security mechanisms of the web can be configured directly within the html document through the use of the `` tag. Two examples of this are the `Content-Security-Policy` and the `Referrer-Policy`. The use of a meta tag for these mechanisms has remained largely stable from [last year](../2024/security#preventing-attacks-using-meta), at around 0.60% and around 2.50% for the CSP and Referrer-Policy respectively. A very small decrease in CSP and very small increase in Referrer-Policy could be observed, just like last year.
@@ -1235,7 +1235,7 @@ Besides as a response header, some of the security mechanisms of the web can be
{{ figure_link(caption="The percentage of hosts enabling different policies using a meta tag", sheets_gid="1717430289", sql_file="meta_policies_allowed_vs_disallowed.sql") }}
-Other security mechanisms can not be configured through the use of the `` tag, however every year we see developers still attempt this. This year we even see a rise in policies that are not allowed to be configured using a meta tag from 0.07% to 0.11% on mobile. These values are ignored by the browser, thus potentially leaving users vulnerable if the correct header is not configured. Keeping up with our running example, this year we found 5,564 meta tags that included the `X-Frame-Options` policy. This is almost 600 pages more than last year, which is a worrying evolution. +Other security mechanisms cannot be configured through the use of the `` tag, however every year we see developers still attempt this. This year we even see a rise in policies that are not allowed to be configured using a meta tag from 0.07% to 0.11% on mobile. These values are ignored by the browser, thus potentially leaving users vulnerable if the correct header is not configured. Keeping up with our running example, this year we found 5,564 meta tags that included the `X-Frame-Options` policy. This is almost 600 pages more than last year, which is a worrying trend. ### Web Cryptography API @@ -1311,7 +1311,7 @@ The Web Cryptography
{{ figure_link(caption="The usages of features of the Web Cryptography API", sheets_gid="433834892", sql_file="web_cryptography_api.sql") }}
-The `CryptoGetRandomValues` remains the most widely used feature of this API, however it is still declining in use, [just like it was last year](../2024/security#web-cryptography-api). Its use on mobile dropped by more than 12% this year, landing just under 41%. The other features continue to rise, with the second most popular feature `SubtleCryptoDigest` growing by 1.2% to just under 3%. +The `CryptoGetRandomValues` function remains the most widely used feature of this API, however it is still declining in use, [just like it was last year](../2024/security#web-cryptography-api). Its use on mobile dropped by more than 12% this year, landing just under 41%. The other features continue to rise, with the second most popular feature `SubtleCryptoDigest` growing by 1.2% to just under 3%. ### Bot protection services @@ -1372,7 +1372,7 @@ As the name implies, the developer is responsible for making sure that only safe
{{ figure_link(caption="The number of pages using HTML sanitization APIs", sheets_gid="1789171380", sql_file="html_sanitization_usage.sql") }}
-Since [last year](../2024/security#html-sanitization), we see a big rise in the use of these APIs. On mobile, the number of pages using `SetHTMLUnsafe` rose from 2 to 449 pages and the number using `ParseHTMLUnsafe` rose from 6 to 17,147 this year. The latter still only accounts for 0.06% of the crawled pages, but it is an interesting change and we can expect the adoption to keep rising in the following year, although it is not expected that these APIs will gain widespread adoption anytime soon. +Since [last year](../2024/security#html-sanitization), we see a big rise in the use of these APIs. On mobile, the number of pages using `SetHTMLUnsafe` rose from 2 to 449 pages and the number using `ParseHTMLUnsafe` rose from 6 to 17,147 this year. The latter still only accounts for 0.06% of the crawled pages, but it is an interesting change and we can expect the adoption to keep rising in the following year. However, it is not expected that these APIs will gain widespread adoption anytime soon. ## Drivers of security mechanism adoption @@ -1456,7 +1456,7 @@ We see that a number of blogging websites and website builders have some importa ### Website popularity -Popular websites with a large user base often have a good reason to protect their users to the best of their abilities so they will not lose users and their trust. Protecting the often sensitive data they store while they likely are the target of more directed attacks requires significant investments in securing their website, but will likely also lead to a more generally security website as a trade-off. +Popular websites with a large user base often have a good reason to protect their users to the best of their abilities so they will not lose users and their trust. Protecting the often sensitive data they store while they likely are the target of more directed attacks requires significant investments in securing their website, but will also lead to a more generally secure website as a trade-off. {{ figure_markup( image="security-headers-by-rank.png", @@ -1484,13 +1484,13 @@ Depending on the industry, more importance may be attributed to keeping a websit ) }} -We see a big difference occurring in the average number of security headers since last year. Sites in the _Internet & Telecom_ and _Computers & Electronics_ categories use significantly more security headers. Especially on mobile clients the difference with following categories is clearly visible. While these two categories seem to be outliers in the good sense, the average number of security headers over other industries has remained largely the same, with here or there a very minor change of about 0.1 header per site on average. +We see a big difference occurring in the average number of security headers since last year. Sites in the _Internet & Telecom_ and _Computers & Electronics_ categories use significantly more security headers. Especially on mobile clients the difference with these categories is clearly visible. While these two categories seem to be outliers in the good sense, the average number of security headers over other industries has remained largely the same, with a very minor change of about 0.1 header per site on average. The two leading industries in terms of security headers happen to be industries related to the field of internet and computer security. It is possible that due to the relevance of security in these industries, developers of these sites are more aware of the potential risk and therefore more willing to use certain security mechanisms. ## Malpractices on the web -Cryptocurrencies are more popular than they have ever been. Cryptomining has been a large business for a number of years and adversaries have been known to install cryptominers as a form of malware on victim websites. Over the past years, the use of cryptominers on the web has been steadily declining, just like it has been over the past year. +Cryptocurrencies are more popular than they have ever been. Cryptomining has been a large business for a number of years and adversaries have been known to install cryptominers as a form of malware on victim websites. Over the past years, the use of cryptominers on the web has been steadily declining. {{ figure_markup( image="cryptominers-trend.png", @@ -1502,7 +1502,7 @@ Cryptocurrencies are more popular than they have ever been. Cryptomining has bee ) }} -We see the number of pages with cryptominers decrease to only 37 pages on mobile, a 42% decline [since last year](../2024/security#fig-47). It is also a 83% decline since September 2022, only three years earlier. +We see the number of pages with cryptominers decreased to only 37 pages on mobile, a 42% decline [since last year](../2024/security#fig-47). It is also a 83% decline since September 2022, only three years earlier. {{ figure_markup( image="cryptominers-market-share.png", @@ -1522,7 +1522,7 @@ While there are many security mechanisms available on the web and in browsers, i ### Unsupported policies in `` -When configuring security policies, it is important that developers understand how they have to define the policy. Some policies can be defined through both a header and the HTML `` tag. However, many policies can not be defined through ``. Developers sometimes make the mistake of trying to configure these policies through the `` tag anyway. Unfortunately browsers will ignore these policies, resulting in inactive security policies. +When configuring security policies, it is important that developers understand how they have to define the policy. Some policies can be defined through both a header and the HTML `` tag. However, many policies cannot be defined through ``. Developers sometimes make the mistake of trying to configure these policies through the `` tag anyway. Unfortunately browsers will ignore these policies, resulting in inactive security policies.
@@ -1568,7 +1568,7 @@ We find that around 0.11% of mobile sites attempt to set security headers that b ### Unsupported CSP directives in `` -While CSP *can* be configured via `` tags and this behaviour has been observed on 0.59% of mobile pages, certain CSP directives are explicitly disallowed in meta implementations and will be ignored by browsers. These directives can only be set by using the `Content-Security-Policy` response header. +While CSP *can* be configured via `` tags and this behaviour has been observed on 0.59% of mobile pages, certain CSP directives are explicitly disallowed in `` tag implementations and will be ignored by browsers. These directives can only be set by using the `Content-Security-Policy` response header.
@@ -1595,7 +1595,7 @@ While CSP *can* be configured via `` tags and this behaviour has been obse
{{ figure_link(caption="Percentage of CSP policies defined in `` with disallowed directives", sheets_gid="1969221363", sql_file="meta_csp_disallowed_directives.sql") }}
-We find that over 2% of mobile pages setting a CSP policy via a `` tag include the `frame-ancestors` directive and 0.003% include the `sandbox` directive. The latter boils down to only three pages out of the entire crawled dataset. Compared to last edition the misconfiguration of `frame-ancestors` shows up on 600 more pages, thereby rising by over 0.8%. This represents a slow but negative evolution for these types of misconfigurations. +We find that over 2% of mobile pages setting a CSP policy via a `` tag include the `frame-ancestors` directive and 0.003% include the `sandbox` directive. The latter boils down to only three pages out of the entire crawled dataset. Compared to last edition, the misconfiguration of `frame-ancestors` shows up on 600 more pages, thereby rising by over 0.8%. This represents a slow but negative evolution for these types of misconfigurations. ### COOP/COEP/CORP confusion @@ -1760,7 +1760,7 @@ The `Server-Timing` HTTP header is a response header defined in a