From ef86090e3708fe87e8e58b6f73aa74a946f99b77 Mon Sep 17 00:00:00 2001 From: Levix Date: Sun, 13 Nov 2022 17:28:21 +0800 Subject: [PATCH 01/14] feat: add security chapter to 2022/zh-CN directory --- src/content/zh-CN/2022/security.md | 1282 ++++++++++++++++++++++++++++ 1 file changed, 1282 insertions(+) create mode 100644 src/content/zh-CN/2022/security.md diff --git a/src/content/zh-CN/2022/security.md b/src/content/zh-CN/2022/security.md new file mode 100644 index 00000000000..fba1387aded --- /dev/null +++ b/src/content/zh-CN/2022/security.md @@ -0,0 +1,1282 @@ +--- +#See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters +title: Security +description: Security chapter of the 2022 Web Almanac covering Transport Layer Security, content inclusion (CSP, Feature Policy, SRI), web defense mechanisms (tackling XSS, XS-Leaks), and drivers of security mechanism adoptions. +authors: [SaptakS, lirantal, clarkio] +reviewers: [kushaldas, tunetheweb] +analysts: [VictorLeP, vikvanderlinden, GJFR] +editors: [tunetheweb] +translators: [] +SaptakS_bio: Saptak S is a human rights centered web developer, focusing on usability, security, privacy and accessibility topics in web development. He is a contributor and maintainer of various different open source projects like The A11Y Project, OnionShare and Wagtail. You can find him blogging at saptaks.blog. +lirantal_bio: Known for his open source and JavaScript security initiatives, Liran Tal is an award-winning software developer, security researcher, and open source champion in the JavaScript community. He's an internationally recognized GitHub Star, acknowledged for his open source advocacy, and has received the OpenJS Foundation's Pathfinder for Security for his work on Node.js security. His contributions to developer security education include leading OWASP projects, building supply chain security tools, participation in CNCF and OpenSSF initiatives, and authoring books such as O'Reilly's Serverless Security. He leads the developer advocacy team at Snyk.io and is on a mission to empower developers with better application security skills. +clarkio_bio: Brian is a web developer with in-depth experience in application security. He helps developers build secure web applications through his work as a Developer Advocate at Snyk.io. While he has experience working across full stack projects, his focus is on backend services, API's and developer tools. Brian loves to teach developers what he's learned from the successes and failures he's had throughout his career. You can find him doing just that on his weekly livestreams or in one of his Pluralsight courses. +results: https://docs.google.com/spreadsheets/d/1cwJ43NL2IN2PxJa5oiOoJCRkSh566XE_k9uHnGJdWeg/ +featured_quote: People's personal details and various aspects of life are becoming more and more digital everyday, making security and privacy extremely crucial. It is the responsibility of the websites to ensure that it's users are protected by adopting the security best practices. +featured_stat_1: +14% +featured_stat_label_1: Increase in adoption for Content Security Policy +featured_stat_2: 428 +featured_stat_label_2: Websites using the `Clear-Site-Data` header +featured_stat_3: +85% +featured_stat_label_3: Increase in adoption of Permissions Policy +--- + +## Introduction + +As people's personal details continue to become more digital, security and privacy are becoming extremely crucial across the internet. It's the website owner's responsibility that they can secure the data they are taking from the user. Hence, it is essential for them to adopt all the security best practices to ensure protection of the user against vulnerabilities that malwares can exploit to get sensitive information. + +Like [previous years](../2021/security), we have analyzed the adoption and usage of security methods and best practices by the web community. We have analyzed metrics related to the bare essential security measures that every website should adopt such as [transport security](#transport-security) and [proper cookie management](#cookies). We have also discussed the data related to the adoption of different security headers and how they help in [content inclusion](#content-inclusion) and [preventing various malicious attacks](#attack-preventions). + +We looked at correlations for [adoption of security measures](#drivers-of-security-mechanism-adoption) with the location, technological stack and website popularity. We hope that such correlations encourage all technological stacks to aim for better security measures by default. We also discuss some [well-known URIs](#well-known-uris) that help towards vulnerability disclosure and other security related settings based on Web Application Security Working Group's standards and drafts. + +## Transport security + +Transport Layer Security ensures secure communication of data and resources between the user and the websites. [HTTPS](https://developer.mozilla.org/en-US/docs/Glossary/https) uses TLS to encrypt all communication between the client and the server. + +{{ figure_markup( + content="94%", + caption="Requests that use HTTPS on desktop.", + classes="big-number", + sheets_gid="1093490384", + sql_file="https_request_over_time.sql", +) }} + +94% of total requests in desktop and 93% of total requests in mobile are made over HTTPS. All major browsers now have an HTTPS-only mode to show warning if a website uses HTTP instead of HTTPS. + +{{ figure_markup( + image="https-usage-by-site.png", + caption="HTTPS usage for sites.", + description="Bar chart showing 89% of desktop sites are using HTTPS, with the remaining 11% using HTTP, while 85% of mobile sites are using HTTPS and the remaining 15% using HTTP.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1343950152&format=interactive", + sheets_gid="1806760937", + sql_file="home_page_https_usage.sql" + ) +}} + +The percentage of homepages that are served over HTTPS continues to be lower compared to the total requests because a lot of the requests to a website are dominated by [third-party](./third-parties) services like fonts, CDN, etc. which have a higher HTTPS adoption. We do see a slight increase from last year in the percentage. 89.3% of homepages are now served over HTTPS on desktop compared to 84.3% last year. Similarly, in our mobile dataset, 85.5% of homepages are served over HTTPS compared to 81.2% last year. + +### Protocol versions + +It's important, not only to use HTTPS, but also to use an up-to-date TLS version. The TLS working group has deprecated TLS v1.0 and v1.1 since they had multiple weaknesses. Since the last year's chapter, Firefox has now updated it's UI and the option to enable TLS 1.0 and 1.1 has been removed from the error page in Firefox version 97. Chrome has also stopped allowing bypassing the error page which is shown for TLS 1.0 and 1.1 since version 98. + +TLS v1.3 is the latest and was released in August 2018 by IETF. It's much faster and is more secure than TLS v1.2. Many of the major vulnerabilities in TLS v1.2 had to do with older cryptographic algorithms which TLS v1.3 removes. + +{{ figure_markup( + image="tls-version-by-site.png", + caption="TLS versions usage for sites.", + description="Bar chart showing that on desktop 67% of sites use TLSv1.3, while 33% use TLSv1.2. On mobile the figures are 70% and 30% respectively.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1390978067&format=interactive", + sheets_gid="1385583211", + sql_file="tls_versions_pages.sql" + ) +}} + +In the above graph, we see that 70% of homepages in mobile and 67% of homepages in desktop are served over TLSv1.3 which is approximately 7% more than last year. So, we are seeing some constant shift from use of TLS v1.2 to TLS v1.3 + +### Cipher suites + +A cipher suite is a set of cryptographic algorithms that the client and server must agree on before they can begin communicating securely using TLS. + +{{ figure_markup( + image="distribution-of-cipher-suites.png", + caption="Distribution of cipher suites.", + description="Stacked bar chart showing the cipher suites used by device, with `AES_128_GCM` being the most common and used by 79% of desktop and 79% of mobile sites, `AES_256_GCM` is used by 19% of desktop and 18% of mobile sites, `AES_256_CBC` used by 2% of desktop sites and 1% of mobile sites, CHACHA20_POLY1305 is used by 1% and 1% of sites respectively, `AES_128_CBC` is used by 0% and 0% respectively.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1789949340&format=interactive", + sheets_gid="711514835", + sql_file="tls_cipher_suite.sql" + ) +}} + +Modern [Galois/Counter Mode (GCM)](https://en.wikipedia.org/wiki/Galois/Counter_Mode) cipher modes are considered to be much more secure since they are not vulnerable to padding attacks. TLS v1.3 only supports GCM and other modern block cipher modes making it more secure. It also removes the trouble of cipher suite ordering. Another factor that determines the usage of a cipher suite is the key size for the encryption and decryption. We still see 128-bit key size being widely used. Hence, we don't see much difference from last year's graph with `AES_128_GCM` continuing to be the most used cipher suite with 79% usage. + +{{ figure_markup( + image="forward-secrecy-support.png", + caption="Forward secrecy usage.", + description="Bar chart showing forward secrecy being used by 97% requests in both mobile and desktop.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=298331860&format=interactive", + sheets_gid="1454804483", + sql_file="tls_forward_secrecy.sql" + ) +}} + +TLS v1.3 also makes [forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy) compulsory. We see 97% of requests in both mobile and desktop using forward secrecy. + +### Certificate Authority + +A Certificate Authority or CA is a company or organization that issues the TLS certificate to the websites that can be recognized by browsers and then establish a secure communication channel with the website. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IssuerDesktopMobile
R348%52%
Cloudflare Inc ECC CA-313%12%
Sectigo RSA Domain Validation Secure Server CA7%8%
cPanel, Inc. Certification Authority5%5%
Amazon3%3%
Go Daddy Secure Certificate Authority - G23%2%
DigiCert SHA2 Secure Server CA2%1%
RapidSSL TLS DV RSA Mixed SHA256 2020 CA-11%1%
E11%1%
+
{{ figure_link(caption="Top 10 certificate issuers for websites.", sheets_gid="1306037372", sql_file="tls_ca_issuers_pages.sql") }}
+
+ +Let's Encrypt (or R3) continues to lead the charts with 48% of websites in desktop and 52% of websites in mobile using certificates issued by them. Let's Encrypt being a non-profit organization has played an important role in the adoption of HTTPS and they continue to issue an increasing number of certificates. We would also like to take a moment to recognize one of its founders, Peter Eckersly, who unfortunately passed away recently. + +Cloudflare continues to be in second position with its similarly free certificates for its customers. Cloudflare CDNs increase the usage of Elliptic Curve Cryptography (ECC) certificates which are smaller and more efficient than RSA certificates but are often difficult to deploy, due to the need to also continue to serve non-ECC certificates to older clients. We see as Let's Encrypt and Cloudflare's percentage continues to increase, the percentage for usage of other CAs are decreasing a little. + +### HTTP Strict Transport Security + +[HTTP Strict Transport Security (HSTS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) is a response header that informs the browser to automatically convert all attempts to access a site using HTTP to HTTPS requests instead. + +{{ figure_markup( + content="25%", + caption="Mobile requests that have an HSTS header.", + classes="big-number", + sheets_gid="822440544", + sql_file="hsts_attributes.sql", +) }} + +25% of the mobile responses and 28% of desktop responses have an HSTS header. + +HSTS is set using the `Strict-Transport-Security` header that can have three different directives: `max-age`, `includeSubDomains`, and `preload`. `max-age` helps denote the time, in seconds, that the browser should remember to access the site only using HTTPS. `max-age` is a compulsory directive for the header. + +{{ figure_markup( + image="hsts-directives-usage.png", + caption="Usage of different HSTS directives.", + description="Bar chart of percentage usage of different HSTS directives. `preload` is used in 19% of websites in both mobile and desktop. `includeSubdomain` is used in 37% of websites in desktop and 34% of websites in mobile. zero `max-age` is used in 6% of websites in desktop and 5% of websites in mobile. Valid `max-age` is used in 94% of websites in desktop and 95% of websites in mobile.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=683864207&format=interactive", + sheets_gid="822440544", + sql_file="hsts_attributes.sql" +) }} + +We see 94% of sites in desktop and 95% of sites in mobile have a non-zero, non-empty `max-age`. + +34% of request responses for mobile, and 37% for desktop include `includeSubdomain` in the HSTS settings. The number of responses with the `preload` directive, which is [not part of the HSTS specification](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security) is lower. It needs a minimum `max-age` of 31,536,000 seconds (or 1 year) and also the `includeSubdomain` directive to be present. + +{{ figure_markup( + image="hsts-max-age-values-in-days.png", + caption="HSTS `max-age` values for all requests (in days).", + description="Bar chart of percentiles of values in the `max-age` attribute, converted to days. In the 10th percentile desktop are 30 days and mobile are 73 days, in the 25th percentile both are 180 days, in the 50th percentile both are 365 days, the 75th percentile is the same at 365 days for both and the 90th percentile has 730 days for both.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=154290094&format=interactive", + sheets_gid="1179482269", + sql_file="hsts_max_age_percentiles.sql" +) }} + +The median value for `max-age` attribute in HSTS headers over all requests is 365 days in both mobile and desktop. https://hstspreload.org/ recommends a `max-age` of 2 years once the HSTS header is set up properly and verified to not cause any issues. + +## Cookies + +An [HTTP cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies) is a set of data about the user that the server sends to the browser. A cookie can be used for things like session management, personalization, tracking and other stateful information related to the user over different requests. + +If a cookie is not set properly, it can be susceptible to many different forms of attacks such as session hijacking, Cross-Site Request Forgery (CSRF), Cross-Site Script Inclusion (XSSI) and various other Cross-Site Leak vulnerabilities. + +### Cookie attributes + +To defend against the above mentioned threats, developers can use 3 different attributes in a cookie: `HttpOnly`, `Secure` and `SameSite`. The `Secure` attribute is similar to the `HSTS` header as it also ensures that the cookies are always sent over HTTPS, preventing Manipulator in the Middle attacks. `HttpOnly` ensures that a cookie is not accessible from any JavaScript code, preventing Cross-Site Scripting Attacks. + +{{ figure_markup( + image="httponly-secure-samesite-cookie-usage.png", + caption="Cookie attributes (desktop).", + description="Bar chart of cookie attributes used on desktop sites divided by first and third-party cookies. For first-party `HttpOnly` is used by 36%, `Secure` by 37%, and `SameSite` by 45%, while for third-party `HttpOnly` is used by 21%, `Secure` by 90%, and `SameSite` by 88%.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=528777115&format=interactive", + sheets_gid="168091712", + sql_file="cookie_attributes.sql" +) }} + +There are 2 different kinds of cookies: first-party and third-party. First-party cookies are usually set by the direct server that you are visiting. Third-party cookies are created by third-party services and are often used for tracking and ad-serving. 37% of the first-party cookies on the desktop have `Secure` and 36% of them have `HttpOnly`. However, in the third party cookies we see that 90% of cookies have `Secure` and 21% of cookies have `HttpOnly`. The percentage of `HttpOnly` is less in third party cookies, because they mostly do want to allow access to them by JavaScript code. + +{{ figure_markup( + image="samesite-cookie-attributes.png", + caption="Same site cookie attributes.", + description="Bar chart of SameSite cookie attributes divided by first and third-party. For first-party `SameSite=lax` is used by 61%, `SameSite=strict` by 2%, and `SameSite=none` by 37%, while for third-party `SameSite=lax` is used by 1%, `SameSite=strict` by 1%, and `SameSite=none` by 98%.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1714102327&format=interactive", + sheets_gid="168091712", + sql_file="cookie_attributes.sql" +) }} + +The `SameSite` attribute can be used to prevent CSRF attacks by telling the browser whether to send the cookie to cross-site requests. `Strict` value allows the cookie to be sent only to the site where it originated while `Lax` value allows cookies to be sent to cross-site requests only if a user is navigating to the origin site by following a link. For `None` value, cookies are sent to both originating and cross-site requests. If `SameSite=None` is set, the cookie's `Secure` attribute must also be set (or the cookie will be blocked). We see that 61% of first-party cookies with the `SameSite` attribute have the value `Lax`. Most browsers default to `SameSite=Lax` if no `SameSite` attribute is present for the cookie hence we see that it continues to dominate the charts. In third party cookies, `SameSite=None` still continues to be super high with 98% cookies in desktop, because third-party cookies do want to be sent across cross-site requests. + +### Cookie age + +There are two different ways to set the time when a cookie is deleted: `Max-Age` and `Expires`. `Expires` uses a specific date (relative to the client) to determine when the cookie is deleted whereas `Max-Age` uses a duration in seconds. + +{{ figure_markup( + image="cookie-age-usage-by-site-in-desktop-in-days.png", + caption="Cookie age usage in days (desktop).", + description="Bar chart showing the use of cookie ages in days at various percentiles. At the 10th percentile, a `Max-Age` of 1, and an `Expires` of 10, the real max age is 7. At the 25th percentile a value of 90 days and 60 days for `Max-Age` and `Expires`, the real age is 60 days. At the 50th percentile a value of 365 days for `Max-Age`, `Expires` and the real age. At the 75th percentile a value of 365 days for `Max-Age`, `Expires` and the real age. At the 90th percentile a value of 730 days for `Max-Age`, `Expires` and the real age.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=2015811517&format=interactive", + sheets_gid="1811539513", + sql_file="cookie_age_percentiles.sql" + ) +}} + +Unlike last year, where we saw that the median for `Max-Age` was 365 days but the median for `Expires` was 180 days, this year it's around 365 days for both. Hence the median for real maximum age has gone up from 180 days to 365 days this year. Even though the `Max-Age` is 729 days and `Expires` is 730 days in the 90th percentile, Chrome has been planning to put a cap of 400 days for both `Max-Age` and `Expires`. + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
%Expires
1.8%"Thu, 01-Jan-1970 00:00:00 GMT"
1.2%"Fri, 01-Aug-2008 22:45:55 GMT"
0.7%"Mon, 01-Mar-2004 00:00:00 GMT"
0.7%"Thu, 01-Jan-1970 00:00:01 GMT"
0.3%"Thu, 01 Jan 1970 00:00:00 GMT"
+
+ {{ figure_link( + caption="Most common cookie expiry values on desktop.", + sheets_gid="707972861", + sql_file="cookie_max_age_expires_top_values.sql", + ) }} +
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
%Expires
1.2%"Fri, 01-Aug-2008 22:45:55 GMT"
0.9%"Thu, 01-Jan-1970 00:00:00 GMT"
0.7%"Mon, 01-Mar-2004 00:00:00 GMT"
0.6%"Thu, 01-Jan-1970 00:00:01 GMT"
0.2%"Thu, 31-Dec-37 23:55:55 GMT"
+
+ {{ figure_link( + caption="Most common cookie expiry values on mobile.", + sheets_gid="707972861", + sql_file="cookie_max_age_expires_top_values.sql", + ) }} +
+
+ +The most prevalent `Expires` has some interesting values. We see that the most used `Expires` value in Desktop is `January 1, 1970 00:00:00 GMT`. When cookies `Expires` value is set to a past date, they are deleted from the browser. January 1, 1970 00:00:00 GMT is the Unix epoch time and hence it's often commonly used to expire or delete a cookie. + +## Content inclusion + +A website's content often takes many shapes and requires resources such as CSS, JavaScript, or other media assets like fonts and images. These are frequently loaded from external service providers of the likes of remote storage services of cloud-native infrastructure, or from content delivery networks (CDNs) with the aim of reducing worldwide networking round-trips just to serve the content. + +However, ensuring that the content we include on the website hasn't been tampered with is of high stakes, and the impact of which can be devastating. Content inclusion is of even higher importance these days given the recent rise of awareness to supply chain security, and growing incidents of Magecart attacks that target website content systems to inject persistent malware through means of cross-site scripting (XSS) vulnerabilities and others. + +### Content Security Policy + +One effective measure you can deploy to mitigate security risks around content inclusion is by employing a Content Security Policy (CSP). It is a security standard that adds a defense-in-depth layer in order to mitigate attacks such as code injection via cross-site scripting, or clickjacking, to name a few. + +It works by ensuring that a predefined trusted set of content rules is upheld and any attempts to bypass or include restricted content are rejected. For example, a content security policy that would allow JavaScript code to run in the browser only from the same origin it was served, and from that of Google Analytics would be defined as `script-src 'self' www.google-analytics.com;`. Any attempts of cross-site scripting injections that add inline JavaScript code such as `` would be rejected by the browser enforcing the set policy. + +{{ figure_markup( + caption="Relative increase in adoption for Content-Security-Policy header from 2021.", + content="+14%", + classes="big-number", + sheets_gid="1799124531", + sql_file="security_headers_prevalence.sql" +) +}} + +We're seeing a 14% relative increase in adoption for `Content-Security-Policy` header from 2021's data of 12.8% to 2022's data of 14.6% which demonstrates a growing trend of adoption across developers and the web security community. This is positive, though it's still a minority of sites using this more advanced feature. + +CSP is most useful, when served on the HTML response itself and here we're seeing consistent growing adoption in mobile requests serving a CSP header with 7.2% two years ago, 9.3% last year, and this year a total of 11.2% of mobile homepages. + +{{ figure_markup( + image="csp-directives-usage.png", + caption="Most common directives used in CSP.", + description="Bar chart showing usage of most common CSP directives. `upgrade-insecure-requests` is the most common with 54% in desktop and 56% in mobile, followed by `frame-ancestors` which is 54% in desktop and 53% in mobile. `block-all-mixed-content` is 26% in desktop and 38% in mobile, `default-src` is 19% in desktop and 16% in mobile, `script-src` is 17% in desktop and 15% in mobile, `style-src` is 14% in desktop and 12% in mobile, `img-src` is 13% in desktop and 11% in mobile, `font-src` is 1% in desktop and 9% in desktop, `connect-src` is 10% in desktop and 8% in mobile, `frame-src` is 10% in desktop and 7% in mobile", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=417279434&format=interactive", + sheets_gid="1303493233", + sql_file="csp_directives_usage.sql" + ) +}} + +The top three CSP directives that we're seeing serving more than a quarter of the HTTP requests for both desktop and mobile are `upgrade-insecure-requests` at a 54%, `frame-ancestors` at 54%, and the `block-all-mixed-content` policy at 27%. Trailing policies are `default-src`, `script-src`, `style-src`, and `img-src` to name a few. + +The `upgrade-insecure-requests` policy's high adoption rate could perhaps be attributed to the high adoption of TLS requests as a de-facto standard. However, despite `block-all-mixed-content` being considered deprecated as of this date, it's showing a high adoption rate. This perhaps speaks to the fast rate at which the CSP specification is advancing and users having a hard time keeping up to date. + +More to do with mitigating cross-site scripting attacks is Google's security initiative for [Trusted Types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types), which requires native browser API support to employ a technique which helps prevent DOM-injection class of vulnerabilities. It is actively advocated by Google engineers yet is still in draft proposal mode for the W3C. Nonetheless, we record its CSP related security headers `require-trusted-types-for` and `trusted-types` at 0.1% of requests which is not a lot, but perhaps speaks to a growing trend of adoption. + +To assess whether a CSP violation from the pre-defined set of rules is occurring, websites can set the `report-uri` directive that the browser will send JSON formatted data as an HTTP POST request. Although `report-uri` requests account for 4.3% of all desktop traffic with a CSP header, it is to date a deprecated directive and has been replaced with `report-to` which accounts for 1.8% of desktop requests. + +One of the biggest contributors to the challenge of implementing a tight content security policy is the existence of inline JavaScript code that's commonly set as event handlers or at other parts of the DOM. To allow teams a progressive adoption of the CSP security standard, a policy may set `unsafe-inline` or `unsafe-eval` as keyword values for its `script-src` directive. Doing so, fails to prevent some cross-site scripting attack vectors and is counter-productive to the preventative measure of a policy. + +Teams can utilize a more secure posture of inline JavaScript code by signing them with a nonce or a SHA256 hash. This would look like something along the lines of: + +``` +Content-Security-Policy: script-src 'nonce-4891cc7b20c' +``` + +And then referencing that in the HTML: + +```html + +``` + +{{ figure_markup( + image="csp-script-src-attribute-usage.png", + caption="CSP `script-src` attribute usage.", + description="Column chart showing usage of nonce, `unsafe-inline` and `unsafe-eval` in CSP `script-src` directive. `nonce-` is used in 12% of websites in mobile with a CSP header and 14% of such websites in desktop. `unsafe-inline` is used 94% of such websites in mobile and 95% in desktop. `unsafe-eval` is used 80% of such websites in mobile and 78% in desktop.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=310998764&format=interactive", + sheets_gid="323360740", + sql_file="csp_script_source_list_keywords.sql" + ) +}} + +The statistics collected for all desktop HTTP requests show that `unsafe-inline` is present on for 94%, and `unsafe-eval`on 80% of all `script-src` values. This demonstrates the real challenges in locking down a website's application code to avoid inline JavaScript code. Furthermore, Only 14% of all above described requests employ a `nonce-` directive which assists in securing the use of unsafe inline JavaScript code. + +Perhaps speaking to the high complexity of defining a content security policy is the statistics we observe for CSP header length. + +{{ figure_markup( + image="csp-header-length.png", + caption="CSP header length.", + description="Column chart showing percentiles of the length of the CSP header in bytes. At 10th percentile both desktop and mobile are 22 bytes, at 25th percentile both are 25 bytes, at 50th percentile desktop is 64 bytes and mobile is 70 bytes, at 75th percentile both are 75 bytes and at 90th percentile desktop is 494 bytes and mobile is 334 bytes.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=311379301&format=interactive", + sheets_gid="54898794", + sql_file="csp_number_of_allowed_hosts.sql" +) }} + +At a median ranking, 50% of requests are only up to 70 bytes in size for desktop requests. This is a slight drop from last year's report which showed both desktop and mobile requests at 75 bytes in size. The 90th percentile of requests and above has grown from last year's 389 bytes for desktop requests, to 494 bytes this year. This demonstrates a slight progress towards more complex and complete security policies. + +Observing the complete definitions for a content security policy, we can see that single directives still make up a large proportion of all requests. 19% of all desktop requests are set only to `upgrade-insecure-requests`. 8% of all desktop requests are set to `frame-ancestors 'self'` and 23% of all desktop requests are set to the value of `block-all-mixed-content; frame-ancestors 'none'; upgrade-insecure-requests;` which mixes together the top 3 most common CSP directives. + +The content security policy often has to allow content from other origins than its own in order to support loading of media such as fonts, ad related scripts, and general content delivery network usage. As such, the top 10 origins across requests are as follows: + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OriginDesktopMobile
https://www.google-analytics.com0.39%0.26%
https://www.googletagmanager.com0.37%0.25%
https://fonts.gstatic.com0.27%0.19%
https://fonts.googleapis.com0.27%0.18%
https://www.google.com0.24%0.17%
https://www.youtube.com0.21%0.15%
https://stats.g.doubleclick.net0.19%0.13%
https://connect.facebook.net0.18%0.13%
https://www.gstatic.com0.17%0.12%
https://cdnjs.cloudflare.com0.16%0.11%
+
+ {{ figure_link( + caption="Most frequently allowed hosts in CSP policies.", + sheets_gid="106248959", + sql_file="csp_allowed_host_frequency.sql" + ) }} +
+
+ +The above hosts account for roughly the same positioning in rank as was reported last year, but the usage is up slightly. + +The CSP security standard is widely supported both by web browsers, as well as content delivery networks and content management systems and is a highly recommended tool for websites and web applications in defense of web security vulnerabilities. + +### Subresource Integrity + +Another defense-in-depth tool is Subresource Integrity which provides a web security defensive layer against content tampering. Whereas a Content Security Policy defines which types and source of content are allowed, a Subresource Integrity mechanism ensures that said content hasn't been modified for malicious intents. + +A reference use-case for using Subresource Integrity is when loading JavaScript content from third-party package managers which also act as a CDN. Some examples of these are unpkg.com or cdnjs.com, both of which serve the content source for JavaScript libraries. + +If a third-party library could be compromised due to a hosting issue by the CDN provider, or by one of the project's contributors or maintainers then you are effectively loading someone else's code into your website. + +Similar to CSP's use of a `nonce-`, Subresource Integrity (also known as SRI) allows browsers to validate the content that is served matches a cryptographically signed hash and prevents tampering with the content, whether over the wire or at its source. + +{{ figure_markup( + content="20%", + caption="Desktop sites using SRI.", + classes="big-number", + sheets_gid="953586778", + sql_file="sri_usage.sql", +) }} + +Just about one of every fifth website (20%) adopts a subresource integrity in one of its web page elements on desktop. Out of these, 83% were specifically used in ` +``` + +{{ figure_markup( + image="sri-hash-function-usage.png", + caption="SRI hash functions.", + description="Bar chart showing percent of SRI elements using various hash functions. SHA-384 is used in 58.4% of SRI elements in desktop websites and 60.7% of SRI elements in mobile websites. SHA-256 is used in 32.4% of SRI elements in desktop websites and 30.8% of SRI elements in mobile websites. SHA-512 is used in 10.9% of SRI elements in desktop websites and 9.9% of SRI elements in mobile websites.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=699960446&format=interactive", + sheets_gid="1419400151", + sql_file="sri_hash_functions.sql" +) }} + +Consistent with last year's report, SHA384 continues to demonstrate the majority of SRI hash types observed between all available hash functions. + + +CDNs are no strangers to Subresource Integrity and provide secure defaults to their consumers by including a Subresource Integrity value as part of their URL references for content to be served on the page. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HostDesktopMobile
www.gstatic.com39%40%
cdn.shopify.com22%23%
cdnjs.cloudflare.com8%7%
code.jquery.com7%7%
static.cloudflareinsights.com5%4%
cdn.jsdelivr.net3%3%
t1.daumcdn.net3%1%
stackpath.bootstrapcdn.com2.7%2.7%
maxcdn.bootstrapcdn.com2.2%2.3%
+
{{ figure_link(caption="Most common hosts from which SRI-protected scripts are included.", sheets_gid="998292064", sql_file="sri_popular_hosts.sql") }}
+
+ +The above list shows the top 10 most common hosts for which a subresource integrity value has been observed. Notable changes from last year are the Cloudflare hosts jumping from position 4 to position 3, and jsDelivr jumping from position 7 to position 6 in ranking, surpassing Bootstrap's hosts rankings. + +### Permissions Policy + +Browsers are becoming more and more powerful with time, adding more native APIs to access and control different sorts of hardware and feature sets that are made available to websites. These also introduce potential security risks to users through misuse of said features, such as malicious scripts turning on a microphone and collecting data, or fingerprinting geolocation of a device to collect location information. + +Previously known as `Feature-Policy`, and now named `Permissions-Policy`, this is an experimental browser API that enables control to an allowlist and a denylist of a wide array of capabilities a browser is able to access. + +We've noticed a high correlation of usage for the `Permissions-Policy` with HTTPS-enabled connections (97%), with `X-Content-Type-Options` (82%), and `X-Frame-Options` (78%). All correlations are across desktop requests. Another high correlation is within the specific technology intersection, observed for Google My Business mobile pages (99%), and the next closest is Acquia's Cloud Platform (67%). All correlations are across mobile requests. + +{{ figure_markup( + caption="Relative increase in adoption of `Permissions-Policy` from 2021.", + content="+85%", + classes="big-number", + sheets_gid="1799124531", + sql_file="security_headers_prevalence.sql" +) +}} + +We're seeing an 85% relative increase in adoption for `Permissions-Policy` from 2021's data (1.3%) to 2022's data (2.4%) for mobile requests and similar trend for desktop requests too. The deprecated `Feature-Policy` shows a minuscule increase of 1 percentage point between last year's data and this year's which demonstrates that users are keeping pace with web browsers' specification changes. + +Besides being used as an HTTP header, this feature can be used within ` +``` + +18.9% of 11.5 million frames in mobile contained the `allow` attribute to enable permission or feature policies. + +The following is a list of the top 10 `allow` directives that were detected in frames: + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DirectiveDesktopMobile
`encrypted-media`75%75%
`autoplay`48%49%
`picture-in-picture`31%31%
`accelerometer`26%27%
`gyroscope`26%27%
`clipboard-write`21%21%
`microphone`9%9%
`fullscreen`8%7%
`camera`6%7%
`geolocation`5%6%
+
+ {{ figure_link( + caption="Prevalence of `allow` directives on iframes.", + sheets_gid="1848560369", + sql_file="iframe_allow_directives.sql" + ) }} +
+
+ +Interesting to point out are places 11th, 12th and 13th allow directives for mobile that didn't make it into the above list and they are `vr` with 6%, `payment` with 2%, and `web-share` with 1%. They perhaps speak of growing trends we're seeing in the industry around virtual reality (and the metaverse, if you will), online payments and the fintech industry. Lastly, it seems to indicate better support for web-based sharing which is presumably due to the rise of work-from-home habits in the last couple of years. + +### Iframe Sandbox + +Using iframe elements in websites has been a long-time practice for developers in order to easily embed third-party content such as rich media, cross-application components, or even ads. Some may even assume that iframe elements form a security boundary between the website embedding them to the sourced website, however that's not exactly the case. + +HTML ` ``` -18.9% of 11.5 million frames in mobile contained the `allow` attribute to enable permission or feature policies. +在移动端的 1150 万个框架中，有 18.9% 包含 `allow` 属性，以启用权限或特性策略。 -The following is a list of the top 10 `allow` directives that were detected in frames: +以下是在框架中检测到的前 10 条 `allow` 指令列表：
- - - + + + @@ -701,20 +699,20 @@ The following is a list of the top 10 `allow` directives that were detected in f
DirectiveDesktopMobile指令桌面端移动端
{{ figure_link( - caption="Prevalence of `allow` directives on iframes.", + caption="iframes 上 `allow` 指令的普遍性", sheets_gid="1848560369", sql_file="iframe_allow_directives.sql" ) }}
-Interesting to point out are places 11th, 12th and 13th allow directives for mobile that didn't make it into the above list and they are `vr` with 6%, `payment` with 2%, and `web-share` with 1%. They perhaps speak of growing trends we're seeing in the industry around virtual reality (and the metaverse, if you will), online payments and the fintech industry. Lastly, it seems to indicate better support for web-based sharing which is presumably due to the rise of work-from-home habits in the last couple of years. +有趣的是，第 11、12 和 13 位的移动端指令没有进入到上述名单，它们是 `vr`（占 6%），`payment`（占 2%），`web-share`（占 1%），它们也许说明了我们在虚拟现实（如果你愿意，也可以称之为元宇宙）、在线支付和金融科技行业中看到的日益增长的趋势。最后，这似乎表明了基于 web 共享得到了更好的支持，这可能是由于过去几年在家办公（指新冠疫情期间）的兴起。 -### Iframe Sandbox +### Iframe 沙盒（Iframe Sandbox） -Using iframe elements in websites has been a long-time practice for developers in order to easily embed third-party content such as rich media, cross-application components, or even ads. Some may even assume that iframe elements form a security boundary between the website embedding them to the sourced website, however that's not exactly the case. +在网站中使用 iframe 元素是开发人员长期以来的做法，以便轻松嵌入第三方内容，如富媒体、跨应用组件，甚至是广告，有些人甚至会认为 iframe 元素在嵌入它们的网站和源网站之间形成了一个安全边界，但事实并非如此。 -HTML ` ``` -18.9% of 11.5 million frames in mobile contained the `allow` attribute to enable permission or feature policies. +在移动端的 1150 万个框架中，有 18.9% 包含 `allow` 属性，以启用权限或特性策略。 -The following is a list of the top 10 `allow` directives that were detected in frames: +以下是在框架中检测到的前 10 条 `allow` 指令列表：
- - - + + + @@ -701,20 +701,20 @@ The following is a list of the top 10 `allow` directives that were detected in f
DirectiveDesktopMobile指令桌面端移动端
{{ figure_link( - caption="Prevalence of `allow` directives on iframes.", + caption="iframes 上 `allow` 指令的普遍性", sheets_gid="1848560369", sql_file="iframe_allow_directives.sql" ) }}
-Interesting to point out are places 11th, 12th and 13th allow directives for mobile that didn't make it into the above list and they are `vr` with 6%, `payment` with 2%, and `web-share` with 1%. They perhaps speak of growing trends we're seeing in the industry around virtual reality (and the metaverse, if you will), online payments and the fintech industry. Lastly, it seems to indicate better support for web-based sharing which is presumably due to the rise of work-from-home habits in the last couple of years. +有趣的是，第 11、12 和 13 位的移动端指令没有进入到上述名单，它们是 `vr`（占 6%），`payment`（占 2%），`web-share`（占 1%），它们也许说明了我们在虚拟现实（如果你愿意，也可以称之为元宇宙）、在线支付和金融科技行业中看到的日益增长的趋势。最后，这似乎表明了基于 web 共享得到了更好的支持，这可能是由于过去几年在家办公（指新冠疫情期间）的兴起。 -### Iframe Sandbox +### Iframe 沙盒（Iframe Sandbox） -Using iframe elements in websites has been a long-time practice for developers in order to easily embed third-party content such as rich media, cross-application components, or even ads. Some may even assume that iframe elements form a security boundary between the website embedding them to the sourced website, however that's not exactly the case. +在网站中使用 iframe 元素是开发人员长期以来的做法，以便轻松嵌入第三方内容，如富媒体、跨应用组件，甚至是广告，有些人甚至会认为 iframe 元素在嵌入它们的网站和源网站之间形成了一个安全边界，但事实并非如此。 -HTML `