免费网站安全检查工具

此工具检查什么

• HTTPS 和重定向

  页面在重定向后是否最终使用 https://、途经的每一跳，以及 http://yourdomain/ 是否以永久（301 或 308）重定向跳转到 HTTPS。

• SSL/TLS 证书

  证书是否受信任并与您的域名匹配、使用的 TLS 版本、颁发机构，以及距离过期还有多少天。

• HSTS 的值

  会解析 Strict-Transport-Security 标头，而不只是检测它是否存在：max-age 至少 180 天、没有格式错误的指令、includeSubDomains，以及 preload 标记是否有预加载列表所需的设置作为支撑。

• Content-Security-Policy 指令

  逐条读取指令：是否对脚本做了任何限制、'unsafe-inline'（使用 nonce 或哈希时不标记）、'unsafe-eval'、script-src 中的宽泛来源（如 *、https: 或 data:）、object-src、base-uri，以及策略是否仅为 Report-Only。

• 点击劫持防护

  X-Frame-Options（包括无效值和已过时的 ALLOW-FROM），或者不是 * 也不是单纯协议的 CSP frame-ancestors 规则。

• 其他防护标头

  X-Content-Type-Options 必须恰好是 nosniff；Referrer-Policy 会检查是否为 unsafe-url 或无法识别的值；Permissions-Policy 会检查哪些功能未加限制。跨源隔离标头仅作为参考信息列出。

• 版本信息泄露和 source map

  暴露版本号的 Server、X-Powered-By、X-AspNet-Version、X-AspNetMvc-Version 和 X-Generator 标头，以及最多三个自有脚本的公开 source map。

• Cookie 标记

  页面响应设置的 cookie，只看名称：HTTPS 上的 Secure、名称看起来像会话或令牌的 cookie 是否设置了 HttpOnly、未设置 Secure 的 SameSite=None、缺少 SameSite，以及作用于上级域名的 cookie。

• CORS

  额外发送一次请求，携带一个无害的虚构 Origin（https://rudra-audit.invalid），看您的服务器是否会原样返回任意来源 — 以及是否同时允许凭据，这正是有风险的组合。

• 混合内容

  HTTPS 页面上的 http:// 脚本、样式表或框架（主动混合内容），以及 http:// 图片或媒体（被动混合内容）。

• security.txt

  /.well-known/security.txt 是否存在，是否有 Contact 行和未过期的 Expires 日期，让安全研究人员知道如何联系您。

• 技术栈和可见暴露面

  可从标头和 HTML 中识别出的框架和服务，以及登录表单、页面中提到的 API 或文档 URL，以及 robots.txt 等公开文件。仅供了解，不扣分。

• 客户端模式（人工复核）

  onclick 等内联事件处理程序，以及未使用 Subresource Integrity 加载的第三方脚本。这些是需要复核的低优先级提示，并非已确认的漏洞。

检查的工作原理

此工具不检查的内容

• 它不是渗透测试

  不利用漏洞、不使用攻击载荷、不暴力破解，也不猜测隐藏路径。它只读取任何浏览器都会收到的配置。

• 需要登录的页面

  我们从不登录或发送凭据，因此不测试需要登录的页面、管理后台和账户设置。

• 您的代码和依赖项

  不审查服务器端代码，也不扫描您的 CMS、插件、库或服务器软件中的漏洞。

• 恶意软件或网站被入侵

  它不查找恶意软件、页面篡改、垃圾内容注入或泄露的账户。

• 您网站使用的所有 cookie

  只能看到页面自身响应设置的 cookie — 看不到之后由 JavaScript、其他页面或第三方添加的 cookie。从不读取 cookie 的值。

• 您的表单如何运作

  会记录表单，但从不提交，因此无法测试服务器端验证、CSRF 防护和频率限制。

我们常发现的问题

• 缺少 HSTS 或有效期过短

  非常常见，即使是将所有请求都重定向到 HTTPS 的网站也是如此 — 而测试时遗留下来的几分钟 max-age 几乎起不到保护作用。

• 没有 CSP，或 CSP 允许的内容过多

  这是最常缺失的标头。即使设置了，script-src 中的 'unsafe-inline'、'unsafe-eval' 或 * 也常常会让它的大部分保护作用失效。

• 没有点击劫持防护

  既没有 X-Frame-Options，也没有 frame-ancestors 规则。

• 证书即将过期

  通常是因为在更换服务器或修改 DNS 后，自动续期停止了工作。

• 暴露服务器版本

  类似“Server: Apache/2.4.41”或“X-Powered-By: PHP/7.4”的标头，会告诉攻击者该从哪里下手。

• HTTP 没有重定向

  http://yourdomain/ 仍在提供页面，或只做临时（302）重定向，因此直接输入域名的访客可能会在未加密的连接下浏览。

• 会话 cookie 未设置 Secure 或 HttpOnly

  脚本可以读取、或者可能通过普通 HTTP 发送的登录或会话 cookie。

如何修复

1. 1

   在提供网站服务的地方设置标头

   标头可以在您的 Web 服务器（Nginx add_header、Apache Header set）、CDN，或主机的设置或标头文件中配置。修改后重新运行检查，确认实际到达浏览器的值。

2. 2

   在 HTTPS 全面可用后开启 HSTS

   使用 Strict-Transport-Security: max-age=31536000（我们接受的最低值为 180 天）。只有当所有子域名都支持 HTTPS 时才添加 includeSubDomains，最后再考虑 preload。

3. 3

   逐步收紧 CSP

   先使用 Content-Security-Policy-Report-Only，再切换为强制执行。用 nonce 或哈希替代 'unsafe-inline'，去掉 'unsafe-eval'，列出确切的脚本来源而不是 * 或 https:，并添加 object-src 'none' 和 base-uri 'self'。

4. 4

   添加简单的标头

   X-Content-Type-Options: nosniff、Referrer-Policy: strict-origin-when-cross-origin 和 X-Frame-Options: DENY（或 SAMEORIGIN）很少会造成问题。

5. 5

   自动续期证书并设置重定向

   使用托管证书或可自动续期的 Let's Encrypt 证书，并将每个 http:// 请求以 301 或 308 重定向到对应的 https:// URL。

6. 6

   隐藏版本号

   关闭版本标识（例如 Nginx 中的 server_tokens off、PHP 中的 expose_php = Off），除非有意为之，否则不要在生产环境发布 source map。

7. 7

   为 cookie 设置标记

   在 HTTPS 网站上为每个 cookie 设置 Secure，为会话和登录 cookie 添加 HttpOnly，并明确设置 SameSite=Lax（或 Strict）。SameSite=None 必须同时设置 Secure。