本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com

点击上方 程序员成长指北，关注公众号

回复1，加入高级Node交流群

今天我们一起来看 2024 年的 Web Almanac - 安全篇

---

太长不看版（以后的文章我都会加入这个部分，基于 AI 总结，方便没空了解细节的同学快速阅读。）：

2024 年的 Web Almanac Security 主要讨论了网络安全的各个方面，包括传输层安全（TLS）的广泛采用和升级、加密套件的选择、HTTP 严格传输安全（HSTS）的使用、Cookie 的安全配置、内容安全策略（CSP）、子资源完整性（SRI）、权限策略、以及防止点击劫持和跨站攻击的措施。此外，还探讨了安全配置错误和忽视的问题，如不支持的政策定义、跨域策略混淆、以及敏感端点在 robots.txt 中的暴露。

学习要点：

1. 传输层安全（TLS）：TLS 的采用率接近 100%，最新版本 TLS1.3 提供更高的安全性和前向保密。

2. 加密套件：GCM 加密套件和 128-bit 密钥广泛使用，TLS1.3 强制前向保密。

3. HTTP 严格传输安全（HSTS）：HSTS 头的使用增加，确保浏览器仅通过 HTTPS 访问页面。

4. Cookie 安全属性：HttpOnly、Secure 和 SameSite 属性增强了 cookies 的安全性，防止 XSS 和 CSRF 攻击。

5. 内容安全策略（CSP）：CSP 控制资源加载，防止点击劫持和其他攻击，采用率稳步增长。

6. 子资源完整性（SRI）：SRI 确保从第三方加载的资源未被篡改，采用率有所停滞。

7. 权限策略和 iframe sandbox：限制网页和嵌入内容的功能访问，增强安全性。

8. 安全头的采用：包括 Strict-Transport-Security、X-Content-Type-Options 和 Content-Security-Policy 头的使用增加。

9. 跨域策略：Cross-Origin-Resource-Policy、Cross-Origin-Embedder-Policy 和 Cross-Origin-Opener-Policy 提供对侧信道攻击的防护。

10. Clear-Site-Data 头：用于清除浏览数据，确保认证令牌和其他敏感信息被移除。

11. Web Cryptography API：用于执行基本的加密操作，CryptoGetRandomValues 的使用量下降。

12. 机器人防护服务：如 reCAPTCHA 和 Cloudflare Bot Management 的采用率增加。

13. 安全配置错误：包括不支持的政策通过 <meta> 定义、跨域策略混淆、和 Timing-Allow-Origin 通配符的使用。

14. .well-known URIs：如 security.txt 和 change-password URI 的采用率仍然较低，但具有提升安全性的潜力。

---

正文如下：

传输层安全

HTTPS 使用传输层安全（Transport Layer Security, TLS）来保护客户端和服务器之间的连接。近年来，使用 TLS 的网站数量显著增加。虽然 TLS 的采用率继续上升，但随着接近 100% 的覆盖率，这一增长速度有所放缓。

自 2022 年以来，使用 TLS 提供的请求占比增加了 4%，移动端达到了 98%。

移动端通过 HTTPS 提供的主页数量从 89% 增加到 95.6%。这个百分比低于 HTTPS 提供的请求数量，因为网站加载的第三方资源很多更可能通过 HTTPS 提供。

协议版本

多年来，TLS 诞生了多个新版本。为了保持安全性，使用最新版本的 TLS 非常重要。目前最新版本是 TLS1.3，已经成为首选版本。与 TLS1.2 相比，TLS1.3 废弃了一些在 1.2 中包含但被发现存在缺陷的加密协议，并且强制实施前向保密（Perfect Forward Secrecy）。主要浏览器厂商早已不再支持旧版本的 TLS。基础协议为 HTTP/3 的 QUIC（快速 UDP 互联网连接）也使用 TLS，提供了与 TLS1.3 类似的安全保证。

数据显示，TLS1.3 被 73% 的网页支持和使用。总体来看，TLS1.3 的使用有所增加，尽管相比 2022 年，QUIC 的使用取得了显著增长，移动页面的使用率从 0% 增加到接近 10%。 TLS1.2 的使用继续按预期减少。与上一版年鉴相比，移动页面上 TLS1.2 的使用率减少了超过 12%，而 TLS1.3 则增加了 2% 多。预计 QUIC 的采用率将继续上升，而 TLS1.2 的使用将继续减少。

我们假设大多数网站不是从 TLS1.2 直接迁移到 QUIC，而是从 TLS1.3 迁移到 QUIC，另一些则从 TLS1.2 迁移到 TLS1.3，这使得 TLS1.3 的增长显得有限。

加密套件

在客户端和服务器能够通信之前，他们必须达成一致使用的加密算法，也就是加密套件。与上次类似，超过 98% 的请求使用 Galois/Counter Mode（GCM）加密套件，这被认为是最安全的选择，因为它们不易受到填充攻击。此外，79% 的请求使用 128-bit 密钥，这在 GCM 模式下仍被认为是安全的密钥长度。访问页面时仅有少数几个套件被使用。TLS1.3 仅支持 GCM 及其他现代块加密模式，这也简化了其加密套件排序。

TLS1.3 强制要求前向保密，这意味着它在网络上得到了高度支持。前向保密是一项特性，确保即使使用中的密钥泄露，也无法用来解密未来或过去通过连接发送的消息。这对于确保对手无法解密长期存储的通信至关重要，即使他们能够泄露密钥。有趣的是，今年前向保密的使用下降了近 2%，降至 95%。

HTTP 严格传输安全（HTTP Strict Transport Security, HSTS）

HTTP 严格传输安全（HSTS）是一种响应头，服务器可以使用它来通知浏览器只应通过 HTTPS 访问该域托管的页面，而不是先通过 HTTP 访问再进行重定向。

目前，30% 的移动端响应包含 HSTS 头，较 2022 年增加了 5%。使用该头的用户可以通过在头值中添加指令来与浏览器通信。max-age 指令是必需的，它向浏览器指示应继续仅通过 HTTPS 访问页面的时间（以秒为单位）。

具有有效 max-age 的请求份额保持不变，为 95%。其他可选指令（包括 includeSubdomains 和 preload）分别增加了 1%，移动端的使用率分别为 35% 和 18%。preload 指令不是 HSTS 规范的一部分，它要求设置 includeSubdomains，并要求 max-age 大于 1 年（或 31,536,000 秒）。

有效 max-age 值的分布与 2022 年几乎相同，唯一区别是移动端第 10 百分位数从 72 天减少到 30 天。max-age 的中位值保持为 1 年。

Cookies

网站可以通过设置 HTTP cookies 在用户浏览器中存储少量数据。根据 cookie 的属性，它将在每次对该网站的后续请求中发送。因此，cookies 可用于隐式认证、追踪或存储用户偏好。

为了保护用户免受跨站请求伪造（CSRF）、会话劫持、跨站脚本包含（XSSI）和跨站泄漏等攻击，网站应安全地配置认证 Cookies。

下面介绍的三个 cookie 属性增强了认证 cookies 的安全性，防止前述的攻击。理想情况下，开发人员应考虑使用所有属性，因为它们提供了互补的保护层。

HttpOnly

通过设置此属性，cookie 不允许通过 JavaScript 的 document.cookie API 访问或操作。这防止了跨站脚本攻击（XSS）访问包含秘密会话令牌的 cookies。

在桌面端，42% 的一方 cookie 有 HttpOnly 属性，与 2022 年相比增加了 6%。至于第三方请求，使用率下降了 1%。

Secure

浏览器仅通过安全加密通道（如 HTTPS）传输带有 Secure 属性的 cookies，而不会通过 HTTP 传输。这样可以确保中间人攻击者无法拦截和读取存储在 cookies 中的敏感值。

多年来，Secure 属性的使用稳步增加。自 2022 年以来，一方上下文中的 cookies 增加了 7%，第三方上下文中增加了 6%。如前几期安全章节讨论所指出的，两个上下文之间的显著差异主要是因为 SameSite=None 的第三方 cookies 必须标注为 Secure。这表明，为启用所需的非默认功能而添加额外的安全先决条件是推动安全功能采用的有效驱动因素。

SameSite

最近引入的 cookie SameSite 属性允许开发人员控制 Cookie 是否允许包含在第三方请求中，目的也是为了防御 CSRF。

该属性可以设置为三个值之一：Strict、Lax 或 None。为 Strict 值的 cookies 完全排除在跨站点请求之外。设置为 Lax 时，cookies 仅在特定条件下（如导航 GET 请求）包含在第三方请求中，但不包含在 POST 请求中。设置 SameSite=None 时，cookie 绕过同站点策略并包含在所有请求中，使其在跨站点上下文中可访问。

与 2022 年相比，带 SameSite 属性的 cookies 数量相对增加，这主要归因于通过设置 SameSite=None 明确排除在同站点策略之外的 cookies。

需要注意的是，所有不带 SameSite 属性的 cookies 默认视为 SameSite=Lax。因此，一方上下文中 75% 的 cookies 实际上被视为设置为 Lax。

Cookie 前缀

通过使用 cookie 前缀如 __Secure- 和 __Host- 可以缓解会话固定攻击。当 cookie 名称以 __Secure- 开头时，浏览器要求该 cookie 具有 Secure 属性并通过加密连接传输。对于 __Host- 前缀的 cookies，浏览器还要求该 cookie 包含设置为 / 的 Path 属性，并排除 Domain 属性。这些要求有助于保护 cookies 免受中间人攻击和受损子域的威胁。

带有这些前缀的 cookies 采用率仍然很低，桌面和移动平台上的使用率均低于 1%。尽管带 Secure 属性的 cookie 采用率很高，这种前缀的 cookies 采用率却较低，这尤其令人惊讶。然而，由于更改 cookie 的名称可能需要大量重构，这可能是开发人员避免这种做法的原因之一。

Cookie age

网站可以通过设置 cookie 的 age 来控制浏览器存储 cookie 的时长。当到达 Max-Age 属性指定的年龄或 Expires 属性定义的时间戳时，浏览器将丢弃该 cookie。如果未设置任何属性，cookie 被视为会话 cookie，并将在会话结束时删除。

与去年相比，cookie 的生命周期分布大致没有变化。然而，自那时起，cookie 标准工作草案已更新，将最大 cookie 生命周期限制为 400 天。这一变化已经在 Chrome 和 Safari 中实施。根据上述百分位数显示，在这些浏览器中，超过 10% 的观察到的 cookies 的生命周期被限制在 400 天。

通过正确配置和使用这些属性，可以有效地增强网站的安全性，确保 cookies 的存储和传输更加安全。

内容嵌入

内容引入是 Web 的基础方面，允许 CSS、JavaScript、字体和图像等资源通过 CDN 或跨多个网站共享。然而，从外部或第三方来源获取内容带来显著风险。引用不受控制的资源即意味着信任这些第三方，但这些第三方可能会变得恶意或被攻破，这会导致供应链攻击，例如最近的 polyfill 事件，受损资源影响了成千上万的网站。因此，管理内容引入的安全策略对保护 Web 应用至关重要。

内容安全策略（Content Security Policy, CSP）

内容安全策略（CSP）正成为网站控制嵌入内容的有力工具。通过在 HTTP 响应头或 <meta> 标签中设置 CSP，网站可以精确指定允许加载的资源及其来源。除了管理内容引入，CSP 还能强制使用加密连接和防范点击劫持等攻击。

CSP 的应用正稳步增长。从 2022 年的 15% 到今年的 19%，采用率增加了 27%。细看这两年的数据，2022 年到 2023 年增长了 12%，2023 年到 2024 年增长了 14%。相比 2021 年仅 12% 的采用率，这个增长趋势令人振奋。如果这种势头持续，明年 CSP 的使用率有望突破 20%。

大多数网站不仅用 CSP 控制资源加载，还广泛使用 upgrade-insecure-requests 和 frame-ancestors 等指令。

block-all-mixed-content 指令虽然已被 upgrade-insecure-requests 取代，但仍是第三常用的指令。它的使用率下降速度已经放缓，桌面端年均下降 4.4%，移动端下降 6.4%。

最常见的 CSP 配置通常包括前三大指令。许多网站同时使用 block-all-mixed-content 和 upgrade-insecure-requests，这是为了兼顾新旧浏览器的兼容性。

总体来说，各指令的使用情况相对稳定。值得注意的是，object-src 指令的使用量上升，已超过 connect-src 和 frame-src。自 2022 年以来，object-src 在桌面和移动端的使用分别增加了 15.9% 和 16.8%。

default-src 指令的使用率下降最为显著。这可能是因为 CSP 的应用范围扩大，不再局限于内容引入，而是涵盖了 HTTPS 升级和页面嵌入控制等领域。这些新用途不依赖 default-src，从而导致其使用率下降。

CSP 中最重要的指令之一是 script-src，因为限制网站加载的脚本会极大地阻碍潜在对手，此指令可以与多个属性关键词结合使用。

unsafe-inline 和 unsafe-eval 指令会显著降低 CSP 提供的安全保障。unsafe-inline 指令允许执行内联脚本，而 unsafe-eval 允许使用 eval 。但是，这些不安全做法的使用仍然普遍。

nonce- 和 strict-dynamic 的使用有略微上涨。通过使用 nonce- 关键词，可以定义一个 nonce 随机值，仅允许具有正确 nonce 的内联脚本执行。这种方法是 unsafe-inline 指令的安全替代方案，允许内联脚本。当与 strict-dynamic 关键词结合使用时，带 nonce 的脚本可以从任何来源导入额外脚本。这种方法简化了开发人员的安全脚本加载，因为它允许他们信任一个带 nonce 的脚本，然后该脚本可以安全地加载其他必要资源。

子资源完整性

尽管 CSP 是确保资源仅从可信来源加载的强大工具，但这些资源仍有可能被篡改。例如，脚本可能来自可信的 CDN，但如果该 CDN 遭到安全漏洞并且其脚本被入侵，那么任何使用这些脚本的网站都可能变得脆弱。

子资源完整性（Subresource Integrity, SRI）为这种风险提供了保护。通过在 <script> 和 <link> 标签中使用 integrity 属性，网站可以指定资源的预期哈希值。如果接收的资源哈希值与预期的不匹配，浏览器将拒绝呈现该资源，从而保护网站免受潜在的受损内容。

SRI 在 23.2% 的桌面网页和 21.3% 的移动网页中被使用。这相当于采用率分别增加了 13.3% 和 18.4%。

然而，子资源完整性的采用似乎停滞不前，每页检查哈希的脚本中位数仍保持在 3.23%，桌面和移动端相同。这个数字自 2022 年以来几乎没有变化。

大多数使用 SRI 保护资源的主机是 CDN。与 2022 年的数据相比，一个显著的不同是 cdn.shopify.com 已不在主机列表的前列（以前桌面端为 22%，移动端为 23%）。这是因为 Shopify 放弃了 SRI，转而支持由 importmap 的 integrity 属性提供的类似功能，他们在博客中对此进行了说明。

通过采用 SRI，开发人员可以增强网站的安全性，确保从第三方来源加载的资源没有被篡改。尽管目前的采用率有所停滞，继续推动 SRI 的普及对于整体 Web 安全性仍然至关重要。

Permissions Policy

权限策略（Permissions Policy，前称为 Feature Policy）是一组机制，允许网站控制网页上哪些浏览器特性可以被访问，比如地理位置、摄像头、麦克风等。通过使用权限策略，网站可以限制主站和任何嵌入内容的功能访问，从而增强安全性和保护用户隐私。这可以通过为主站及其所有嵌入的 <iframe> 元素设置 Permissions-Policy 响应头来配置。另外，网站管理员还可以使用 <iframe> 元素的 allow 属性为其设定单独的策略。

2022 年，Permissions-Policy 头的采用率显著增加了 85%。但从 2022 年到今年，增长率急剧下降到仅 1.3%。这可以预料，因为 2020 年底 Feature Policy 更名为 Permissions Policy，导致初期激增。随后的几年里，由于该头只被基于 Chromium 的浏览器支持，增长率保持较低。

目前，只有少数网站采用了 Permissions-Policy 响应头，桌面端和移动端的使用率分别为 2.8% 和 2.5%。这个政策最初主要用来明确退出 Google 的联合学习群体（FLoC）项目。在使用这个响应头的网站中，有 21% 设置了 interest-cohort=() 策略，这源于 FLoC 试验期间引发的争议。虽然 FLoC 后来被 Topics API 取代，但 interest-cohort 指令的持续使用表明，特定问题确实能影响网络政策的采纳情况。

其他被观察到的指令中，至少有 2% 的网站使用它们来限制自身及其嵌入的 <iframe> 元素的权限。权限策略和内容安全策略（CSP）类似，都是'默认开放'而非'默认安全'的。也就是说，如果没有设置这个策略，就意味着没有任何保护。这种设计是为了避免新政策的引入破坏现有网站功能。有趣的是，约 0.28% 的网站明确使用了 * 通配符策略，这样做实际上允许网站及其所有未特别设置 allow 属性的嵌入 <iframe> 请求任何权限——这其实就是不设置权限策略时的默认行为。

除了在响应头中设置，权限策略还可以通过 <iframe> 元素的 allow 属性单独定义。比如，如果想让某个 <iframe> 使用地理位置和摄像头权限，可以这样设置属性：

<iframe src='https://example.com' allow='geolocation 'self'; camera *;'></iframe>

在爬取的 2140 万个 <iframe> 元素中，半数包含了 allow 属性。与前一个月仅有 21% 的 <iframe> 元素有 allow 属性相比，这是一个显著的增加——表明其使用在一个月内增长了一倍多。合理解释是一个或多个广泛使用的第三方服务传播了这个更新。在我们现在观察到的广告专用指令（如表格中第 1 行和第 3 行）中——这些指令在 2022 年都不存在——这很可能是一个广告服务引起的变化。

与 2022 年相比，最常见的前十个指令现在由三个新引入的指令领先：join-ad-interest-group，attribution-reporting 和 run-ad-auction。其中第一和第三个指令特定于 Google 的 Privacy Sandbox。对于前十个观察到的指令，几乎没有一个是与起源或关键词（如 src, self 和 none）结合使用的，这意味着加载的页面无论其起源如何都可以请求指定的权限。

Iframe sandbox

在 <iframe> 元素中嵌入第三方网站总是存在风险的，尽管这可能是为了丰富 Web 应用程序的功能。网站管理员应当知晓，一个恶意的 <iframe> 可以利用几种机制来伤害用户，比如启动弹出窗口或将顶级页面重定向到恶意域。

通过在 <iframe> 元素上使用 sandbox 属性，可以遏制这些风险。使用这个属性，可以将加载的内容限制在由属性定义的规则内，用以防止嵌入的内容滥用功能。当值为空字符串时，策略是最严格的。然而，可以通过添加特定指令来放宽此策略，每个指令都有各自特定的放宽规则。例如，下面的 <iframe> 允许嵌入的网页运行脚本：

<iframe src='https://example.com' sandbox='allow-scripts'></iframe>

在桌面和移动端，分别有 28.4% 和 27.5% 的 <iframe> 元素使用了 sandbox 属性，相较于 2022 年报告的 35.2% 和 32%，这是一个显著的下降。与前一节中提到的 allow 属性使用突然激增类似，这一下降很可能是因为嵌入服务的操作模式发生了变化，模板 <iframe> 中省略了 sandbox 属性。

超过 98% 的在 <iframe> 中设置了 sandbox 属性的页面使用 allow-scripts 指令，允许嵌入的网页运行脚本。

通过合理设置和使用权限策略和 sandbox 属性，网站管理员可以显著提高网站的安全性，保护用户免受潜在的安全威胁。

攻击预防措施

Web 应用可能会通过多种方式被利用，虽然有很多方法可以保护它们，但全面了解所有选项可能是很困难的。当保护机制不是默认启用或需要选择加入时，这一挑战会更加突出。换句话说，网站管理员必须了解与其应用相关的潜在攻击向量以及如何预防它们。因此，评估有哪些攻击预防措施到位对于评估 Web 整体安全性至关重要。

安全头的采用

大多数安全策略是通过响应头配置的，这些响应头指导浏览器执行哪些政策。虽然不是每个安全策略对每个网站都相关，但某些安全头的缺失表明网站管理员可能没有考虑或优先考虑安全措施。

在过去的两年里，有三个安全头的使用量有所下降。最显著的下降是 Expect-CT 头，该头用于选择加入证书透明性（Certificate Transparency），现在因为证书透明性已默认启用而被弃用。同样，Feature-Policy 头因被 Permissions-Policy 头替代而使用量减少。最后，Content-Security-Policy-Report-Only 头也有所减少。该头主要用于测试和监控内容安全策略的影响，通过将违规报告发送到指定端点。需要注意的是，Report-Only 头不会强制执行内容安全策略，因此其使用量减少不表示安全性降低。由于这些头都不影响安全，我们可以安全地假设安全头的整体采用仍在增长，反映了 Web 安全性的积极趋势。

自 2022 年以来，绝对增长最快的三个头为：Strict-Transport-Security（+5.3%）、X-Content-Type-Options（+4.9%）和 Content-Security-Policy（+4.2%）。

通过CSP 和 X-Frame-Options 防止点击劫持

如前所述，内容安全策略的主要用途之一是防止点击劫持攻击。通过 frame-ancestors 指令，网站可以指定允许哪些来源在框架中嵌入它们的页面。该指令通常用来完全禁止嵌入或仅限同源嵌入。

另一种防止点击劫持的措施是 X-Frame-Options（XFO）头，但其控制粒度不如 CSP。XFO 头可以设置为 SAMEORIGIN，允许页面仅被同源网页嵌入，或设置为 DENY，完全阻止页面的嵌入。大多数头配置为允许同源网站嵌入页面，以放松政策。

尽管已弃用，但 0.6% 的桌面观察头和 0.7% 的移动观察头仍使用 ALLOW-FROM 指令，其功能类似于 frame-ancestors 指令，指定可信来源能嵌入页面。然而，现代浏览器忽略含 ALLOW-FROM 指令的 X-Frame-Options 头，这可能在点击劫持防御中造成漏洞。不过，这种做法可能是为了向后兼容，与 CSP 中包含 frame-ancestors 指令的支持策略一起使用。

跨域策略

Web 的核心原则之一是复用和嵌入跨域资源。然而，随着 Spectre、Meltdown 等微架构攻击和利用侧信道泄露潜在敏感用户信息的跨站泄露（XS-Leaks）等新兴威胁，我们的安全视角发生了显著转变。这些威胁产生了对控制资源是否以及如何被其他网站渲染的机制的需求，以更好地防护这些新漏洞。

这种需求导致了一些新安全头的引入，统称为跨域策略（Cross-Origin Policies）：跨域资源策略（Cross-Origin-Resource-Policy, CORP）、跨域嵌入策略（Cross-Origin-Embedder-Policy, COEP）和跨域打开策略（Cross-Origin-Opener-Policy, COOP）。这些头通过控制资源跨域共享和嵌入的方式，提供了对侧信道攻击的强大对策。这些策略的采用率稳步增长，过去两年 Cross-Origin-Opener-Policy 的使用率几乎每年倍增。

• ** 跨域嵌入策略（Cross Origin Embedder Policy） **

跨域嵌入策略限制了嵌入跨域资源的网站的能力。目前，网站不再能访问强大功能如 SharedArrayBuffer 和通过 Performance.now() API 的不受限计时器，因为这些功能可能被利用来推断跨域资源的敏感信息。如果一个网站需要访问这些功能，它必须向浏览器表示其只打算与不含证明信息的资源（credentialless）或明确允许其他来源访问的资源（通过 Cross-Origin-Resource-Policy 头）交互。

大多数设置 COEP 头的网站表明它们不需要访问上述强大功能（unsafe-none）。如果缺少 COEP 头，也是这种默认行为，意味着网站将在限制的跨域资源访问下操作，除非明确配置为其他方式。

• 跨域资源策略（Cross Origin Resource Policy）

相反，提供资源的网站可以使用跨域资源策略响应头（CORP）给予其他网站渲染所提供资源的明确许可。该头可以取以下三个值之一：same-site，仅允许同站请求接收资源；same-origin，限制访问到同源请求；以及 cross-origin，允许任何来源访问资源。除了减轻侧信道攻击之外，CORP 还可以防止跨站脚本包含攻击（XSSI）。例如，通过禁止将动态 JavaScript 资源提供给跨域网站，CORP 有助于防止包含敏感信息的脚本泄露。

CORP 头主要用于允许任意来源访问所提供资源，cross-origin 值是最常见的设置。在较少情况下，头限制访问：限制资源到同源网站的不足 5%，仅限于同站的网站不到 4%。

• 跨域打开策略（Cross Origin Opener Policy）

跨域打开策略（COOP）有助于控制其他网页如何打开和引用受保护页面。COOP 防护可以通过 unsafe-none 明确禁用，这也是缺少头时的默认行为。same-origin 值允许来自同源页面的引用，same-origin-allow-popups 还允许窗口或标签页的引用。类似于跨域嵌入策略，COOP 必须配置为 same-origin 才能解锁强大功能如 SharedArrayBuffer 和 Performance.now()。

近一半的观察到的 COOP 头采用了最严格的设置，same-origin。

通过 Clear-Site-Data 防止攻击

Clear-Site-Data 头允许网站轻松清除与其相关的浏览数据，包括 cookies、存储和缓存。这在用户登出时特别有用，确保认证令牌和其他敏感信息被移除，无法被滥用。头的值指定网站请求浏览器清除的数据类型。

Clear-Site-Data 头的采用率仍然有限；我们的观察显示仅有 2,071 个主机（占所有主机的 0.02%）使用此头。然而，这一功能主要用于登出页面，而爬虫不会捕捉到这些页面。要调查登出页面，爬虫需要扩展以检测并交互账户注册、登录和登出功能——这将需要相当的精力。一些进展已经在这一领域由安全和隐私研究人员取得，例如自动登录网页和自动注册。

当前的使用数据表明，Clear-Site-Data 头主要用于清除缓存。值得注意的是，该头中的值必须用引号括起来；例如，cache 是不正确的，应该写成 'cache'。有趣的是，对这一语法规则的遵守有所显著改善：在 2022 年，65% 的桌面和 63% 的移动网站使用了不正确的 cache 值。而现在，这些数字分别降至 22% 和 23%。

通过 <meta> 防止攻击

网页上的某些安全机制可以通过 HTML 源代码中的 meta 标签配置，例如内容安全策略（Content-Security-Policy）和引用策略（Referrer-Policy）。今年，有 0.61% 的移动网站启用了 CSP，2.53% 启用了 Referrer-Policy，均使用了 meta 标签。我们发现，使用这种方法设置 Referrer-Policy 有轻微增加，而设置 CSP 有轻微减少。

开发人员有时还尝试通过 meta 标签启用其他安全功能，但这不会被允许，因而会被浏览器忽略。以 2022 年的同一个例子为例，4,976 个页面尝试通过 meta 标签设置 X-Frame-Options，这将被浏览器忽略。相较于 2022 年有了绝对增加，但仅因为数据集中的页面数量多了一倍以上。相对地，移动页面从 0.04% 降至 0.03%，桌面页面从 0.05% 降至 0.03%。

Web Cryptography API

Web 加密 API 是一个 JavaScript API，用于在网站上执行基本的加密操作，例如随机数生成、哈希、签名生成和验证，以及加密和解密。

与上次的年鉴相比，CryptoGetRandomValues 的使用量继续下降，下降速度在过去两年显著加快，降至 53%。尽管下降，它显然仍是采用最多的功能，远超其他功能。在 CryptoGeRandomValues 之后，接下来最常用的五个功能已被更广泛采用，从不到 0.7% 增至 1.3% 至 2% 的采用率。

机器人防护服务

由于恶意机器人在现代 Web 上仍然是一个重要问题，我们看到防护措施的采用继续上升。从 2022 年桌面网站的 29% 和移动网站的 26%，跃升至现在的 33% 和 32%。看来开发人员对移动网站的保护投资有所增加，使得受保护的桌面和移动网站数量更加接近。

reCAPTCHA 仍是最大的保护机制，但其使用量有所减少。相比之下，Cloudflare Bot Management 的采用增加，仍是第二大保护机制。

HTML 清理

浏览器新增了 setHTMLUnsafe 和 ParseHTMLUnsafe API，允许开发人员从 JavaScript 使用声明性影子 DOM。当开发人员从 JavaScript 使用包含声明性影子 DOM 定义的自定义 HTML 组件（使用 <template shadowrootmode='open'>...</template>），使用 innerHTML 将这个组件放在页面上不会如预期般工作。可以使用替代的 setHTMLUnsafe 来确保声明性影子 DOM 得到考虑。

使用这些 API 时，开发人员必须小心只传递已安全的值，因为如名字所示，它们是不安全的，意味着不会清理输入，可能导致 XSS 攻击。

由于这些 API 是新的，低采用率是预期的。我们总共发现仅有 6 个页面使用 parseHTMLUnsafe，2 个使用 setHTMLUnsafe，与访问的页面数量相比相对较少。

安全配置错误与忽视

尽管网站存在安全策略表明管理员在积极努力保护其网站，正确配置这些策略至关重要。以下部分将突出一些观察到的配置错误，可能会对安全性造成影响。

不支持的政策通过 <meta> 定义

开发者了解特定安全策略应该在哪里定义非常重要。例如，尽管可以通过 <meta> 标签定义安全策略，但如果浏览器不支持，在该处定义的策略可能会被忽略，从而潜在地使应用易受攻击。

虽然内容安全策略（CSP）可以使用 <meta> 标签定义，但它的 frame-ancestors 和 sandbox 指令在这种上下文中不受支持。尽管如此，我们观察到 1.70% 的桌面页面和 1.26% 的移动页面错误地在 <meta> 标签中使用了 frame-ancestors 指令。对于不允许的 sandbox 指令，此值远低于 0.01%。

COEP、CORP 和 COOP 混淆

由于名字和目的相似，跨域嵌入策略（COEP）、跨域资源策略（CORP）和跨域打开策略（COOP）有时很难区分。然而，将不支持的值赋给这些头可能会对网站安全性产生不利影响。

例如，约 3% 的观察到的 COEP 头错误地使用了不支持的值 same-origin。发生这种情况时，浏览器会恢复默认行为，即允许嵌入任何跨域资源，同时限制访问诸如 SharedArrayBuffer 和不受限使用 Performance.now() 的特性。只要站点管理员的意图不是为 CORP 或 COOP 设置 same-origin，这种回退对安全性没有内在影响，因为 same-origin 对它们来说是一个有效的值。

此外，只有 0.26% 的观察到的 COOP 头设置为 cross-origin，只有 0.02% 的 CORP 头使用了 unsafe-none 值。即便这些值被错误地应用于错误的头，它们代表了可用的最宽松政策。因此，这些配置错误被认为不会降低安全性。

除了为一个头有效的值被错误地用于另一个头的情况外，我们还发现了若干个较小的语法错误，但每个错误仅占总观察头的不到 1%，表明虽然此类错误存在，但相对较少。

Timing-Allow-Origin 通配符

Timing-Allow-Origin 是一个响应头，允许服务器指定可查看通过资源计时 API 获得的属性值的来源列表。这意味着在此头中列出一个来源可以访问有关到服务器连接的详细时间戳，例如 TCP 连接开始、请求开始和响应开始的时间。

当 CORS 生效时，为防止跨域泄露，许多这些时间（包括上面所列的那些）返回为 0。通过在 Timing-Allow-Origin 头中列出一个来源，这种限制被解除。

允许不同的来源访问这些信息应该谨慎处理，因为利用这些信息，加载资源的站点可能执行时间攻击。在我们的分析中发现，所有包含 Timing-Allow-Origin 头的响应中，83% 的 Timing-Allow-Origin 头包含通配符值，因此允许任何来源访问详细的时间信息。

缺少服务器信息头的抑制

尽管通过模糊化（Security by obscurity）进行安全一般被认为是不好的做法，Web 应用仍然可以通过不公开有关服务器或框架的过多信息来受益。虽然攻击者仍然可以对某些细节进行指纹识别，最小化暴露——尤其是有关特定版本号的暴露——可以减少应用在自动漏洞扫描中被针对的可能性。

这些信息通常通过 Server、X-Server、X-Backend-Server、X-Powered-By 和 X-Aspnet-Version 等头报告。

最常公开的头是 Server 头，显示运行在服务器上的软件。其次是 X-Powered-By 头，透露服务器使用的技术。

检视 Server 和 X-Powered-By 头的最常见值，我们发现特别是 X-Powered-By 头指出了版本，前 10 个值揭示了特定的 PHP 版本。对于桌面和移动端，至少 25% 的 X-Powered-By 头包含这些信息。此头可能在观测到的 Web 服务器上默认启用。虽然它对分析可能有用，但其好处有限，因此应默认禁用。然而，仅禁用此头并不能解决过时服务器的安全风险；定期更新服务器仍然至关重要。

缺少 Server-Timing 头的抑制

Server-Timing 头在 W3C 编辑草案中被定义为一个可以用来传达服务器性能指标的头。开发人员可以发送包含零个或多个属性的指标。指定的属性之一是 dur 属性，用于传达服务器上特定操作的持续时间，以毫秒为准。

我们发现 6.4% 的互联网主机使用 Server-Timing。超过 60% 的这些主机在响应中包含了至少一个 dur 属性，超过 55% 的主机甚至发送了两个以上的 dur 属性。这意味着这些站点将服务器端过程的持续时间直接暴露给客户端，可被用于攻击。由于 Server-Timing 可能包含敏感信息，其使用现限于同一来源，除非开发人员使用了 Timing-Allow-Origin 头，如前一部分所讨论的。然而，时间攻击仍可直接针对服务器执行，无需访问跨域数据。

.well-known URIs

.well-known URI 是一种用于指定与整个网站相关的数据或服务特定位置的机制。.well-known URI 的路径部分始终以字符 /.well-known/ 开头。

security.txt

security.txt 是一种文件格式，网站可以通过这种文件以标准化的方式传达漏洞报告相关信息。网站开发者可以在该文件中提供联系信息、PGP 密钥、政策等细节。白帽黑客和渗透测试人员可以利用这些信息，在进行安全分析时报告他们发现的潜在漏洞。我们的分析显示，1% 的网站目前使用 security.txt 文件，这表明他们正在积极提升网站的安全性。

大多数 security.txt 文件包含联系信息（88.8%）和首选语言（56.0%）。今年，有 47.9% 的 security.txt 文件定义了过期时间，相较于 2022 年的 2.3% 是一个巨大的跳跃。这主要可以通过方法论的更新来解释，因为今年的分析仅包括文本文件，而不是简单地包含所有响应码为 200 的响应，从而显著降低了误报率。这意味着使用 security.txt 的网站中，少于一半遵循了标准（包括但不限于定义 expires 属性为必需）。有趣的是，只有 39% 的 security.txt 文件定义了政策，这是一块开发者可以指示发现漏洞的白帽黑客应如何报告漏洞的区域。

change-password

change-password 是一个在 W3C 编辑草案状态下的特定 .well-known URI，与 2022 年时的状态相同。这个特定的 .well-known URI 提议为用户和软件提供一种轻松识别更改密码链接的方法，这意味着外部资源可以轻松链接到该页面。

采用率仍然非常低。对于移动和桌面网站均为 0.27%，相比 2022 年桌面网站的 0.28% 略有下降。由于标准化过程缓慢，不预期其采用率会有很大变化。我们也重复说明，没有认证机制的网站不需要使用这个 URL，这意味着对它们而言实现该 URL 没有意义。

检测状态码可靠性

与 2022 年一样，一个仍在编辑草案状态的规范定义了一个特定的 .well-known URI 用于确定网站 HTTP 响应状态码的可靠性。这个 .well-known URI 的背后思路是，它不应存在于任何网站中，这意味着导航到该 .well-known URI 不应产生 ok 状态的响应。如果它重定向并返回'ok 状态'，这意味着网站的状态码不可靠。当发生重定向到特定 '404 not found' 错误页面的情况，但该页面使用 ok 状态提供时，这可能发生。

我们发现与 2022 年类似的分布，83.6% 的页面以非 ok 状态响应，这是预期的结果。同样，这些数据可能不太会有变化的原因之一是标准仍处于编辑草案状态且标准化进程缓慢。

robots.txt 中的敏感端点

最后，我们检查了是否 robots.txt 包含可能的敏感端点。通过使用这些信息，黑客可能基于 robots.txt 中的排除条目选择网站或端点进行攻击。

我们看到约 4.3% 的网站在其 robots.txt 文件中包含至少一个管理员条目。这可以用来寻找网站的仅管理员部分，这部分会被隐藏，找到它需要尝试访问该 URL 下的特定子页面。 login、signin、auth、sso 和 account 指向一个用户使用他们创建或接收到的账户登录的机制的存在。每个这些端点在若干网站的 robots.txt 文件中被包含（一些可能会重叠），其中 account 是更受欢迎的一个，占网站的 2.9%。

最后

本文章是对报告内容关键部分的解读，报告原文请查看：https://almanac.httparchive.org/en/2024/security

Node 社群

我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。

   “分享、点赞、在看” 支持一波👍