From 569ddd969979e1e877e3a75082b5b50a8b095fa9 Mon Sep 17 00:00:00 2001 From: Lord Rupert Everton <83113194+lord-r3@users.noreply.github.com> Date: Fri, 8 Nov 2024 09:29:37 +0100 Subject: [PATCH] Update security.md Comments and text fixes for the security chapter --- src/content/en/2024/security.md | 209 +++++++++++++++++--------------- 1 file changed, 114 insertions(+), 95 deletions(-) diff --git a/src/content/en/2024/security.md b/src/content/en/2024/security.md index ac9f9277d55..7e14c6ae052 100644 --- a/src/content/en/2024/security.md +++ b/src/content/en/2024/security.md @@ -21,15 +21,17 @@ featured_stat_label_3: TODO ## Introduction -With how much of our lives happen online these days - whether it's staying in touch, following the news, buying, or even selling products online - web security has never been more important. Unfortunately, the more we rely on these online services, the more appealing they become to malicious actors. As we've seen time and time again, even a single weak spot in the systems we depend on can lead to disrupted services, stolen personal data, or worse. The past two years have been no exception, with a rise in Denial-of-Service (DoS) attacks, bad bots, and supply-chain attacks targeting the Web like never before. +With how much of our lives happen online these days - whether it's staying in touch, following the news, buying, or even selling products online - web security has never been more important. Unfortunately, the more we rely on these online services, the more appealing they become to malicious actors. As we've seen repeatedly, even a single weak spot in systems we depend on can lead to disrupted services, stolen personal data, or worse. The past two years have been no exception, with a rise in Denial-of-Service (DoS) attacks, bad bots, and supply-chain attacks targeting the Web like never before. -In this chapter, we take a closer look at the current state of web security by analyzing the protections and security practices used by websites today. We explore key areas like Transport Layer Security (TLS), cookie protection mechanisms, and safeguards against third-party content inclusion. We'll discuss how these security measures help prevent attacks, as well as highlight common misconfigurations that can undermine them. Additionally, we examine some of the harmful practices still present on the web, such as the widespread use of cryptominers. +Comment: Maybe explain what bad bots are. DoS and SUS-Attacks are well-known terms I would argue, however, "bad bots" is something I read for the first time. -We also investigate the factors driving security practices, analyzing whether elements like country, website category, or technology stack influence the security measures in place. By comparing this year's findings with those from the [2022 Web Almanac](../2022/security), we highlight key changes and assess long-term trends. This allows us to provide a broader perspective on the evolution of web security practices and the progress made over the years. +In this chapter, we take a closer look at the current state of web security by analyzing the protections and security practices used by websites today. We explore key areas like Transport Layer Security (TLS), cookie protection mechanisms, and safeguards against third-party content inclusion. We'll discuss how these security measures help prevent attacks and highlight common misconfigurations that can undermine them. Additionally, we examine some harmful practices on the web, such as the widespread use of cryptominers. -## Transport security +We also investigate the factors driving security practices, analyzing whether elements like country, website category, or technology stack influence the security measures. We highlight key changes and assess long-term trends by comparing this year's findings with those from the [2022 Web Almanac](../2022/security). This allows us to provide a broader perspective on the evolution of web security practices and the progress made over the years. -[HTTPS](https://developer.mozilla.org/docs/Glossary/https) uses Transport Layer Security (TLS) to secure the connection between client and server. Over the past years, the number of sites using TLS has increased tremendously. As in previous years, adoption of TLS continued to increase, but that increase is slowing down as it closes in to 100%. +## Transport Layer Security + +[HTTPS](https://developer.mozilla.org/docs/Glossary/https) uses Transport Layer Security (TLS) to secure the connection between client and server. Over the past years, the number of sites using TLS has increased tremendously. As in previous years, the adoption of TLS continued to increase, but that increase is slowing down as it closes in on 100%. {{ figure_markup( content="98%", @@ -51,11 +53,11 @@ The number of requests served using TLS climbed another 4% to 98.12% on mobile s ) }} -The number of homepages served over HTTPS on mobile increased from 89% to 95.6%. This percentage is lower than the number of requests served over HTTPS due to the high number of third-party resources websites load, which are more likely to be served over HTTPS. +The number of homepages served over HTTPS on mobile increased from 89% to 95.6%. This percentage is lower than the number of requests served over HTTPS due to the high number of third-party resource websites load, which are more likely to be served over HTTPS. ### Protocol versions -Over the years, multiple new versions of TLS have been created. In order to remain secure, it is important to use an up to date version of TLS. The latest version is TLS1.3, which has been the preferred version for a while. Compared to TLS1.2, version 1.3 deprecates some cryptographic protocols still included in 1.2 that were found to have certain flaws and it enforces perfect forward secrecy. Support for older versions of TLS have long been removed by major browser vendors. QUIC (Quick UDP Internet Connections), the protocol underlying HTTP/3 also uses TLS, providing similar security guarantees as TLS1.3. +Over the years, multiple new versions of TLS have been created. To remain secure, it is important to use an up-to-date version of TLS. The latest version is TLS1.3, which is the preferred option from a security point of view. Compared to TLS1.2, version 1.3 deprecates some cryptographic protocols still included in 1.2, like AES-CBC, that were found to have flaws under certain conditions. TLS1.3 also enforces perfect forward secrecy. Major browser vendors have long removed support for older versions of TLS. QUIC (Quick UDP Internet Connections), the protocol underlying HTTP/3 also uses TLS, providing similar security guarantees as TLS1.3. {{ figure_markup( image="tls-versions.png", @@ -67,13 +69,15 @@ Over the years, multiple new versions of TLS have been created. In order to rema ) }} -We find that TLS1.3 is supported and used by 73.03% of web pages. The use of TLS1.3 overall has grown, even though QUIC has gained significant use compared to 2022, moving from 0% to almost 10% of mobile pages. The use of TLS1.2 continues to decrease as expected. Compared to the last Almanac it decreased by more than 12% for mobile pages, while TLS1.3 has increased by a bit over 2%. It is expected that the adoption of QUIC will continue to rise, as the use of TLS1.2 will continue to decrease. +We find that TLS1.3 is supported and used by 73.03% of web pages. The use of TLS1.3 overall has grown, even though QUIC has gained significant use compared to 2022, moving from 0% to almost 10% of mobile pages. The use of TLS1.2 continues to decrease as expected. Compared to the last Almanac, it declined by more than 12% for mobile pages, while TLS1.3 has increased by over 2%. It is expected that the adoption of QUIC will continue to rise, as the use of TLS1.2 continues to decrease. + +We assume most websites don't move from TLS1.2 directly to QUIC, but rather that most sites using QUIC migrated from TLS1.3, and others moved from TLS1.2 to TLS1.3, thereby giving the appearance of limited growth of TLS1.3. -We assume most websites don't move from TLS1.2 directly to QUIC, but rather that most sites using QUIC migrated from TLS1.3 and others moved from TLS1.2 to TLS1.3, thereby giving the appearance of limited growth of TLS1.3. +Comment: Do we have data that supports this claim? ### Cipher suites -Before client and server can communicate, they have to agree upon the cryptographic algorithms, known as cipher suites, to use. Like last time, over 98% of requests are served using a Galois/Counter Mode (GCM) cipher, which is considered the most secure option, due to them not being vulnerable to padding attacks. Also unchanged is the almost 79% of requests using a 128-bit key, which is still considered a secure key-length for AES in GCM mode. There are only a handful of suites used on the visited pages. TLS1.3 only supports GCM and other modern block cipher modes, which also simplifies its cipher suite ordering. +Before client and server can communicate, they have to agree upon the cryptographic algorithms, known as cipher suites, to use. Like in the last version of the Almanac, over 98% of requests are served using a Galois/Counter Mode (GCM) cipher, which is considered the most secure option, due to this mode not being vulnerable to padding attacks. Also unchanged is the fact that almost 79% of requests using a 128-bit key, which is still considered a secure key length for AES in GCM mode. There are only a handful of suites used on the visited pages. TLS1.3 only supports GCM and other modern block cipher modes, which also simplifies its cipher suite ordering. {{ figure_markup( image="cipher-suites.png", @@ -85,7 +89,9 @@ Before client and server can communicate, they have to agree upon the cryptograp ) }} -TLS1.3 makes forward secrecy required, which means it is highly supported on the web. Forward Secrecy is a feature that assures that in case a key in use is leaked, it cannot be used to decrypt future or past messages sent over a connection. This is important to ensure that adversaries storing long-term traffic cannot decrypt the entire conversation as soon as they are able to leak a key. Interestingly, the use of forward secrecy dropped by almost 2% this year, to 95.38%. +TLS1.3 makes forward secrecy required, which means it is highly supported on the web. Forward Secrecy is a feature that assures that if a key in use is leaked, it cannot be used to decrypt future or past messages sent over a connection. This is important to ensure that adversaries storing long-term traffic cannot decrypt the entire conversation as soon as they can leak a key. Interestingly, the use of forward secrecy dropped by almost 2% this year, to 95.38%. + +Comment: Before we say that TLS enforces perfect forward secrecy here we only describe forward secrecy. Maybe clarify this? {{ figure_markup( image="forward-secrecy.png", @@ -99,7 +105,7 @@ TLS1.3 makes Certificate Authority (CA). By retrieving a certificate from one of the trusted CAs, the certificate will be recognized by the browser, thus allowing the user to use the certificate and therefore TLS for their secure communication. +To use TLS, servers must first get a certificate they can host, which is created by a Certificate Authority (CA). By retrieving a certificate from one of the trusted CAs, the certificate will be recognized by the browser, thus allowing the user to use the certificate and, therefore, TLS for their secure communication.
@@ -166,11 +172,11 @@ In order to use TLS, servers must first get a certificate they can host, which i
{{ figure_link(caption="The percentage of sites using a certificate issued by a specific issuer", sheets_gid="1458082974", sql_file="tls_ca_issuers_pages.sql") }}
-R3 (an intermediate certificate from Let's Encrypt) still leads the charts, although usage dropped compared to last year. Also from Let's Encrypt are the E1, R10 and R11 intermediary certificates that are rising in percentage of websites using them. +R3 (an intermediate certificate from Let's Encrypt) still leads the charts, although usage dropped compared to last year. Also from Let's Encrypt are the E1, R10, and R11 intermediary certificates that are rising in the percentage of websites using them. -R3 and E1 were issued in 2020 and are only valid for 5 years, which means it will expire in September 2025. Around a year before the expiry of intermediate certificates, Let's Encrypt issues new intermediates that will gradually take over from the older ones. This March, Let's Encrypt issued their new intermediates, which include R10 and R11 that are only valid for 3 years. These latter two certificates will take over from R3 directly, which should be reflected in next year's Almanac. - -Along with the rise in the number of Let's Encrypt issued certificates, other current top 10 providers have seen a decrease in their share of certificates issued, except for GTS CA 1P5 that rose from close to 0% to over 6.5% on mobile. Of course it is possible that at the time of our analysis a CA was in the process of switching intermediate certificates, which could mean they serve a larger percentage of sites than reflected. +R3 and E1 were issued in 2020 and are only valid for 5 years, which means it will expire in September 2025. Around a year before the expiry of intermediate certificates, Let's Encrypt issues new intermediates that will gradually take over from the older ones. This March, Let's Encrypt issued their new intermediates, which include R10 and R11 that are only valid for 3 years. These two certificates will take over from R3 directly, which should be reflected in next year's Almanac. + +Along with the rise in the number of Let's Encrypt-issued certificates, other current top 10 providers have seen a decrease in their share of certificates issued, except for GTS CA 1P5, which rose from close to 0% to over 6.5% on mobile. Of course, it is possible that at the time of our analysis, a CA was in the process of switching intermediate certificates, which could mean they serve a larger percentage of sites than reflected. {{ figure_markup( content="56%", @@ -180,7 +186,7 @@ Along with the rise in the number of Let's Encrypt issued certificates, other cu sql_file="TODO.sql", ) }} -When we sum together the use of all certificates of Let's Encrypt, we find that they issue over 56% of the certificates currently in use. +When we sum up the use of all Let's Encrypt certificates, we find that they issue over 56% of the certificates currently in use. ### HTTP Strict Transport Security @@ -194,7 +200,7 @@ When we sum together the use of all certificates of Let's Encrypt, we find that sql_file="TODO.sql", ) }} -Currently, 30% of responses on mobile have a HSTS header, which is a 5% increase compared to 2022. Users of the header can communicate directives to the browser by adding them to the header value. The `max-age` directive is obligated. It indicates to the browser the time it should continue to only visit the page over HTTPS in seconds. +Currently, 30% of mobile responses have an HSTS header, a 5% increase compared to 2022. Users of the header can communicate directives to the browser by adding them to the header value. The `max-age` directive is obligated. It indicates to the browser the time it should continue to visit the page only over HTTPS in seconds. {{ figure_markup( image="hsts-directives.png", @@ -206,7 +212,7 @@ Currently, 30% of responses on mobile have a HSTS header, which is a 5% increase ) }} -The share of requests with a valid `max-age` has remained unchanged at 95%. The other , optional, directives (`includeSubdomains` and `preload`) both see a slight increase of 1% compared to 2022 to 35% and 18% on mobile respectively. The `preload` directive, which [is not part of the HSTS specification](https://developer.mozilla.org/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security), requires the `includeSubdomains` to be set and also requires a `max-age` larger than 1 year (or 31,536,000 seconds). +The share of requests with a valid `max-age` has remained unchanged at 95%. The other optional directives (`includeSubdomains` and `preload`) both see a slight increase of 1% compared to 2022 to 35% and 18% on mobile, respectively. The `preload` directive, which [is not part of the HSTS specification](https://developer.mozilla.org/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security), requires the `includeSubdomains` to be set and also requires a `max-age` larger than 1 year (or 31,536,000 seconds). {{ figure_markup( image="hsts-max-age.png", @@ -218,13 +224,13 @@ The share of requests with a valid `max-age` has remained unchanged at 95%. The ) }} -The distribution of valid `max-age` values has remained almost the same as in 2022, with the exception that the 10th percentile on mobile has decreased from 72 to 30 days. The median value of `max-age` remains at 1 year. +The distribution of valid `max-age` values has remained almost the same as in 2022, except that the 10th percentile on mobile has decreased from 72 to 30 days. The median value of `max-age` remains at 1 year. ## Cookies -Websites can store small pieces of data in a user's browser by setting an HTTP cookie. Depending on the cookie's attributes, it will be sent with every subsequent request to that website. As such, cookies can be used for purposes of implicit authentication, tracking or storing user preferences. +Websites can store small amounts of data in a user's browser by setting an HTTP cookie. Depending on the cookie's attributes, it will be sent with every subsequent request to that website. Cookies can be used for implicit authentication, tracking the user, or storing user preferences. -When cookies are used for authenticating users, it is paramount to protect them from abuse. For instance, if an adversary gets ahold of a user's session cookie, they could potentially log into the victim's account. +When cookies are used to authenticate users, it is paramount to protect these cookies from abuse. For instance, if an adversary gets ahold of a user's session cookie, they could log into the victim's account. To protect their user's from attacks like Cross-Site Request Forgery (CSRF), session hi-jacking, Cross-Site Script Inclusion (XSSI) and Cross-Site Leaks, websites are expected to securely configure authentication cookies. @@ -244,19 +250,19 @@ The three cookie attributes outlined below enhance the security of authenticatio #### `HttpOnly` -By setting this attribute, the cookie is not allowed to be accessed or manipulated through the JavaScript `document.cookie` API. This prevents a Cross-Site Scripting (XSS) attack from gaining access to cookies containing secret session tokens. +The cookie cannot be accessed or manipulated by setting this attribute through the JavaScript `document.cookie` API. This prevents a Cross-Site Scripting (XSS) attack from gaining access to cookies containing secret session tokens. -With 42% of cookies having the `HttpOnly` attribute in a first-party context on desktop, the usage has risen by 6% compared to 2022. As for third-party requests, the usage has decreased by 1%. +42% of cookies on a desktop have the `HttpOnly` attribute in a first-party context, which has risen by 6% compared to 2022. As for third-party requests, the usage has decreased by 1%. #### `Secure` Browsers only transmit cookies with the `Secure` attribute over secure, encrypted channels, such as HTTPS, and not over HTTP. This ensures that man-in-the-middle attackers cannot intercept and read sensitive values stored in cookies. -The use of the `Secure` attribute has been steadily increasing over the years. Since 2022, an additional 7% of cookies in first-party contexts and 6% in third-party contexts have been configured with this attribute. As discussed in previous editions of the Security chapter, the significant difference in adoption between the two contexts is largely due to the requirement that third-party cookies with `SameSite=None` must also be marked as `Secure`. This highlights that additional security prerequisites for enabling desired non-default functionality are an effective driver for the adoption of security features. +The use of the `Secure` attribute has steadily increased over the years. Since 2022, an additional 7% of cookies in first-party contexts and 6% in third-party contexts have been configured with this attribute. As discussed in previous editions of the Security chapter, the significant difference in adoption between the two contexts is primarily due to the requirement that third-party cookies with `SameSite=None` must also be marked as `Secure`. This highlights that additional security prerequisites for enabling desired non-default functionality are an effective driver for adopting security features. #### `SameSite` -The most recently introduced cookie attribute, `SameSite`, allows developers to control whether a cookie is allowed to be included in third-party requests. It is intended as an additional layer of defense against attacks like CSRF. +The most recently introduced cookie attribute, `SameSite`, allows developers to control whether a cookie can be included in third-party requests. It is intended as an additional layer of defense against attacks like CSRF. The attribute can be set to one of three values: `Strict`, `Lax`, or `None`. Cookies with the `Strict` value are completely excluded from cross-site requests. When set to `Lax`, cookies are only included in third-party requests under specific conditions, such as navigational GET requests, but not POST requests. By setting `SameSite=none`, the cookie bypasses the same-site policy and is included in all requests, making it accessible in cross-site contexts. @@ -270,9 +276,9 @@ The attribute can be set to one of three values: `Strict`, `Lax`, or `None`. Coo ) }} -While the relative number of cookies with a `SameSite` attribute has increased compared to 2022, this rise is largely attributable to cookies being explicitly excluded from the same-site policy by setting `SameSite=None`. +While the relative number of cookies with a `SameSite` attribute has increased compared to 2022, this rise is mainly attributable to cookies being explicitly excluded from the same-site policy by setting `SameSite=None`. -It's important to note that all cookies without a `SameSite` attribute are treated as `SameSite=Lax` by default. Consequently, a total of 75% of cookies set in a first-party context are effectively treated as if they were set to `Lax`. +It's important to note that all cookies without a `SameSite` attribute are treated as `SameSite=Lax` by default. Consequently, 75% of cookies set in a first-party context are effectively treated as if they were set to `Lax`. ### Prefixes @@ -303,7 +309,7 @@ It's important to note that all cookies without a `SameSite` attribute are treat
{{ figure_link(caption="`__Secure-` and `__Host-` prefixes (desktop)", sheets_gid="1849762871", sql_file="cookie_attributes.sql") }}
-The adoption of cookie prefixes remains low, with less than 1% of cookies using these prefixes on both desktop and mobile platforms. This is particularly surprising given the high adoption rate of cookies with the `Secure` attribute, the only prerequisite for cookies prefixed with `__Secure-`. However, changing a cookie's name can require significant refactoring, which is presumably a reason why developers tend to avoid this. +The adoption of cookie prefixes remains low, with less than 1% of cookies using these prefixes on desktop and mobile platforms. This is particularly surprising given the high adoption rate of cookies with the `Secure` attribute, the only prerequisite for cookies prefixed with `__Secure-`. However, changing a cookie's name can require significant refactoring, presumably a reason developers tend to avoid this. ### Cookie age @@ -319,7 +325,7 @@ Websites can control how long browsers store a cookie by setting its lifespan. B ) }} -The distribution of cookie ages has remained largely unchanged compared to [lat year](../2022/security#cookie-age). However, since then, the cookie standard working draft has been updated, capping the maximum cookie age to 400 days. This change has already been implemented in Chrome and Safari. Based on the percentiles shown above, in these browsers, more than 10% of all observed cookies have their age capped to this 400-day limit. +The distribution of cookie ages has mainly remained unchanged compared to [last year](../2022/security#cookie-age). However, since then, the cookie standard working draft has been updated, capping the maximum cookie age to 400 days. This change has already been implemented in Chrome and Safari. Based on the percentiles shown above, more than 10% of all observed cookies have their age capped to this 400-day limit in these browsers. ## Content inclusion @@ -329,7 +335,7 @@ Content inclusion is a foundational aspect of the Web, allowing resources like C Websites can exert greater control over their embedded content by deploying a [Content Security Policy (CSP)](https://developer.mozilla.org/docs/Web/HTTP/CSP) through either the `Content-Security-Policy` response header or by defining the policy in a `` html tag. The wide range of directives available in CSP allows websites to specify, in a fine-grained manner, which resources can be fetched and from which origins. -In addition to vetting included content, CSP can serve other purposes as well, such as enforcing the use of encrypted channels with the `upgrade-insecure-requests` directive and controlling where the site can be embedded to protect against clickjacking attacks using the `frame-ancestors` directive. +In addition to vetting included content, CSP can serve other purposes, such as enforcing the use of encrypted channels with the `upgrade-insecure-requests` directive and controlling where the site can be embedded to protect against clickjacking attacks using the `frame-ancestors` directive. {{ figure_markup( content="+27%", @@ -339,9 +345,9 @@ In addition to vetting included content, CSP can serve other purposes as well, s sql_file="security_headers_prevalence.sql", ) }} -The adoption rate of CSP headers increased from 15% of all hosts in 2022 to 19% this year. This amounts to a relative increase of 27%. Over these two years, the relative increase was 12% between 2022 and 2023, and 14% between 2023 and 2024. +The adoption rate of CSP headers increased from 15% of all hosts in 2022 to 19% this year, a relative increase of 27%. Over these two years, the relative increase was 12% between 2022 and 2023 and 14% between 2023 and 2024. -Looking back, overall CSP adoption was only at 12% of hosts in 2021, so it's encouraging to see that growth has remained steady. If this trend continues, projections suggest that CSP adoption will surpass the 20% mark in next year's Web Almanac. +Looking back, CSP adoption was only at 12% of hosts in 2021, so it's encouraging to see that growth has remained steady. If this trend continues, projections suggest that CSP adoption will surpass 20% in next year's Web Almanac. #### Directives @@ -357,7 +363,7 @@ Most websites utilize CSP for purposes beyond controlling embedded resources, wi ) }} -The `block-all-mixed-content` directive, which has been deprecated in favor of `upgrade-insecure-requests`, is the third most used directive. Although we observed a relative decrease of 12.5% and 13.8% in its usage between 2020 and 2021, the decline has since slowed to an average yearly decrease of 4.4% for desktop and 6.4% for mobile since 2022. +The `block-all-mixed-content` directive, which has been deprecated in favor of `upgrade-insecure-requests`, is the third most used directive. Although we observed a relative decrease of 12.5% and 13.8% in usage between 2020 and 2021, the decline has slowed to an average yearly decrease of 4.4% for desktop and 6.4% for mobile since 2022.
@@ -389,7 +395,7 @@ The `block-all-mixed-content` directive, which has been deprecated in favor of `
{{ figure_link(caption="Most prevalent CSP headers", sheets_gid="176994530", sql_file="csp_most_common_header.sql") }}
-The top three directives also make up the building blocks of the most prevalent CSP definitions. The second most commonly used CSP definition includes both `block-all-mixed-content` and `upgrade-insecure-requests`. This suggests that many websites use `block-all-mixed-content` for backward compatibility, as newer browsers will ignore this directive if `upgrade-insecure-requests` is present. +The top three directives also comprise the building blocks of the most prevalent CSP definitions. The second most commonly used CSP definition includes `block-all-mixed-content` and `upgrade-insecure-requests`. This suggests that many websites use `block-all-mixed-content` for backward compatibility, as newer browsers will ignore this directive if `upgrade-insecure-requests` is present.
@@ -463,11 +469,11 @@ The top three directives also make up the building blocks of the most prevalent All other directives shown in the graph above are used for content inclusion control. Overall, usage has remained relatively stable. However, a notable change is the increased use of the `object-src` directive, which has surpassed `connect-src` and `frame-src`. Since 2022, the usage of `object-src` has risen by 15.9% for desktop and 16.8% for mobile. -Among the most notable decreases in usage is `default-src`, the catch-all directive. This decline could be explained by the increasing use of CSP for purposes beyond content inclusion, such as enforcing HTTP upgrades to HTTPS or controlling the embedding of the current page – situations where `default-src` is not applicable, as these directives don't fallback to it. This change in CSP purpose is confirmed by the most prevalent CSP headers listed in Table [TODO 1], which all have seen an increase in usage since 2022. However, directives like `upgrade-insecure-requests` and `block-all-mixed-content`, while part of these most common CSP headers, are being used less overall, as seen in Table [TODO 2]. +Among the most notable decreases in usage is `default-src`, the catch-all directive. This decline could be explained by the increasing use of CSP for purposes beyond content inclusion, such as enforcing HTTP upgrades to HTTPS or controlling the embedding of the current page – situations where `default-src` is not applicable, as these directives don't fallback to it. This change in CSP purpose is confirmed by the most prevalent CSP headers listed in Table [TODO 1], which all have increased usage since 2022. However, directives like `upgrade-insecure-requests` and `block-all-mixed-content`, while part of these most common CSP headers, are used less overall, as seen in Table [TODO 2]. #### Keywords for `script-src` -One of the most important directives of CSP is `script-src`, as curbing the scripts that can be embedded in the website hinders potential adversaries greatly. This directive can be used with several attribute keywords. +One of the most important directives of CSP is `script-src`, as curbing the scripts that can be embedded in the website greatly hinders potential adversaries. This directive can be used with several attribute keywords. {{ figure_markup( image="csp-script-src-keywords.png", @@ -479,7 +485,7 @@ One of the most important directives of CSP is `script-src`, as curbing the scri ) }} -The `unsafe-inline` and `unsafe-eval` directives can significantly reduce the security benefits provided by CSP. The `unsafe-inline` directive permits the execution of inline scripts, while `unsafe-eval` allows the use of the eval JavaScript function. Unfortunately, the use of these insecure practices remains widespread, demonstrating the challenges of avoiding use of inline scripts and use of the `eval` function. +The `unsafe-inline` and `unsafe-eval` directives can significantly reduce the security benefits CSP provides. The `unsafe-inline` directive permits the execution of inline scripts, while `unsafe-eval` allows using the eval JavaScript function. Unfortunately, the use of these insecure practices remains widespread, demonstrating the challenges of avoiding use of inline scripts and use of the `eval` function.
@@ -516,11 +522,11 @@ The `unsafe-inline` and `unsafe-eval` directives can significantly reduce the se
{{ figure_link(caption="Relative usage change of CSP `script-src` keywords", sheets_gid="2075772620", sql_file="csp_script_source_list_keywords.sql") }}
-However, the increasing adoption of the `nonce-` and `strict-dynamic` keywords is a positive development. By using the `nonce-` keyword, a secret nonce can be defined, allowing only inline scripts with the correct nonce to execute. This approach is a secure alternative to the unsafe-inline directive for permitting inline scripts. When used in combination with the `strict-dynamic` keyword, nonced scripts are permitted to import additional scripts from any origin. This approach simplifies secure script loading for developers, as it allows them to trust a single nonced script, which can then securely load other necessary resources. +However, the increasing adoption of the `nonce-` and `strict-dynamic` keywords is a positive development. Using the `nonce-` keyword can define a secret nonce, allowing only inline scripts with the correct nonce to execute. This approach is a secure alternative to the unsafe-inline directive for permitting inline scripts. Nonced scripts can import additional scripts from any origin when combined with the `strict-dynamic` keyword. This approach simplifies secure script loading for developers, allowing them to trust a single nonced script, which can then securely load other necessary resources. #### Allowed hosts -CSP is often regarded as one of the more complex security policies, partly due to the detailed policy language, providing fine-grained control over resource inclusion. +CSP is often regarded as one of the more complex security policies, partly because its detailed policy language provides fine-grained control over resource inclusion. {{ figure_markup( image="csp-header-length.png", @@ -532,17 +538,17 @@ CSP is often regarded as one of the more complex security policies, partly due t ) }} -Reviewing the observed CSP header lengths, we find that 75% of all headers are 75 bytes or shorter. For context, the longest policy among the [Most Prevalent CSP Definitions] Table is also 75 bytes. At the 90th percentile, desktop policies reach 504 bytes and mobile policies 368 bytes, indicating that many websites find it necessary to implement relatively lengthy Content Security Policies. However, when analyzing the distribution of unique allowed hosts across all policies, the 90th percentile shows just 2 unique hosts. +Reviewing the observed CSP header lengths, we find that 75% of all headers are 75 bytes or shorter. For context, the longest policy among the [Most Prevalent CSP Definitions] Table is also 75 bytes. At the 90th percentile, desktop policies reach 504 bytes and mobile policies 368 bytes, indicating that many websites must implement relatively lengthy Content Security Policies. However, when analyzing the distribution of unique allowed hosts across all policies, the 90th percentile shows just two unique hosts. -The highest number of unique allowed hosts in a policy was 1,020, while the longest Content Security Policy header reached 65,535 bytes. However, this latter header is inflated by a large number of repeated `,` characters for unknown reasons. The second longest CSP header, which is valid, spans 33,123 bytes. This unusually large size is due to hundreds of occurrences of the `adservice.google` domain, each with variations in the top-level domain. Excerpt: +The most unique allowed hosts in a policy was 1,020, while the longest Content Security Policy header reached 65,535 bytes. However, this latter header is inflated by many repeated `,` characters for unknown reasons. The second longest CSP header, which is valid, spans 33,123 bytes. This unusually large size is due to hundreds of occurrences of the `adservice.google` domain, each with variations in the top-level domain. Excerpt: ``` adservice.google.com adservice.google.ad adservice.google.ae … ``` -This suggests that the long tail of excessively large CSP headers is likely caused by computer-generated exhaustive lists of origins. Although this may seem like a specific edge case, it highlights a limitation of CSP: the lack of regex functionality, which could otherwise provide a more efficient and elegant solution to handle such cases. However, depending on the websites implementation, this issue could also be solved by employing the `strict-dynamic`and `nonce-` keyword in the `script-src` directive, which enables the allowed script with nonce to load additional scripts. +This suggests that the long tail of excessively large CSP headers is likely caused by computer-generated exhaustive lists of origins. Although this may seem like a specific edge case, it highlights a limitation of CSP: the lack of regex functionality, which could otherwise provide a more efficient and elegant solution to handle such cases. However, depending on the websites implementation, this issue could also be solved by employing the `strict-dynamic` and `nonce-` keyword in the `script-src` directive, which enables the allowed script with nonce to load additional scripts. -The most common HTTPS origins included in CSP headers are used for loading fonts, ads and other media fetched from CDNs: +The most common HTTPS origins included in CSP headers are used for loading fonts, ads, and other media fetched from CDNs:
@@ -651,13 +657,13 @@ As for WSS origins, used for allowing WebSockets connections to certain origins,
{{ figure_link(caption="Most frequently allowed WS(S) hosts in CSP policies", sheets_gid="1790517281", sql_file="csp_allowed_host_frequency_wss.sql") }}
-Two of these origins are related to customer service and ticketing (`intercom.io`, `zopim.com`), one is used for website analytics (`hotjar.com`), and two are associated with social media (`www.livejournal.com`, `quora.com`). For four out of the five websites, we found specific instructions on how to add the origin to the website's content security policy. This is considered good practice, as it discourages website administrators from using wildcards to allow third-party resources, which would reduce security by allowing broader access than necessary. +Two of these origins are related to customer service and ticketing (`intercom.io`, `zopim.com`), one is used for website analytics (`hotjar.com`), and two are associated with social media (`www.livejournal.com`, `quora.com`). For four of the five websites, we found specific instructions on how to add the origin to the website's content security policy. This is considered good practice, as it discourages website administrators from using wildcards to allow third-party resources, which would reduce security by allowing broader access than necessary. ### Subresource Integrity While CSP is a powerful tool for ensuring that resources are only loaded from trusted origins, there remains a risk that those resources could be tampered with. For instance, a script might be loaded from a trusted CDN, but if that CDN suffers a security breach and its scripts are compromised, any website using one of those scripts could become vulnerable as well. -[Subresource Integrity (SRI)](https://developer.mozilla.org/docs/Web/Security/Subresource_Integrity) provides a safeguard against this risk. By using the `integrity` attribute in `