🛡️ 网站安全诊断

只需输入 URL,即可审核安全相关响应头(HSTS、CSP、X-Frame-Options 等)和 Mixed Content。

完全免费无需注册服务器处理无日志 / 数据库限速 5 种语言深色模式

📖 本诊断能告诉你什么

本诊断检查一次请求所能揭示的范围——响应头、Cookie 属性、TLS 使用方式——报告从外部可见的安全状况。它无法发现应用层漏洞：即使这里满分，SQL 注入和越权问题依然可能存在。这里覆盖的是「加一行配置就能关上的入口」，是投入产出比最高的一层。

检查项	含义	未通过时的处理
Cookie 的 `HttpOnly`	设置后 `document.cookie` 无法读取该值，即便 XSS 得逞也带不走会话 ID。	会话 Cookie 必须设置，PHP 中为 `session.cookie_httponly = 1`。需要被 JS 读取的值应放在另一个独立 Cookie 中；为了能读取而去掉 HttpOnly 是本末倒置。
Cookie 的 `SameSite`	控制来自其他站点的请求是否携带该 Cookie。这是针对 CSRF 的结构性防护，应与令牌方案配合使用而非替代。	默认用 `Lax`，支付等敏感操作用 `Strict`。若设为 `None`，则必须同时设置 `Secure`，否则现代浏览器会直接丢弃该 Cookie——这正是 SSO 或 iframe 嵌入突然失效的典型原因。
服务器信息暴露	`Server: nginx/1.18.0`、`X-Powered-By: PHP/8.1.2` 这类响应头等于直接告诉攻击者该查哪个版本的已知漏洞。	nginx 设置 `server_tokens off;`，PHP 设置 `expose_php = Off`。这只是拖延时间，并非防御——隐藏版本远不如真正升级版本来得实在。
混合内容（Mixed Content）	HTTPS 页面通过 http:// 加载脚本或图片。浏览器会直接拦截脚本，图片则会导致锁标消失。	将嵌入的 URL 改为 `https://`。若第三方服务完全不支持 HTTPS，真正需要决定的是是否继续使用它。迁移期间可用 `Content-Security-Policy: upgrade-insecure-requests` 自动升级。

这里满分仅代表对外可见的配置是妥当的。认证与授权实现、输入处理、依赖库的已知漏洞都需要另行检查。从 composer audit、npm audit 之类的依赖审计入手最为现实。