网站上线后，首页能打开，只说明一条访问路径可用。域名解析、邮件身份、证书、响应头、历史页面和对外端口还可能暴露另一张清单。站点负责人如果想在一次发布前做基线检查，可以用开源项目 Web-Check 把这些分散线索放在同一页面，再由相应负责人核对和整改。本文给出一套只针对自有或获授权域名的操作流程、优先级表和复查模板。
项目当前 GitHub 仓库 显示约 35.3K Star。这只是截至 2026 年 10 月 30 日的页面状态，会继续变化；用“34.8K”给文章定标题很快就会过时。“30 秒扒光全部暴露面”也不准确：项目会调用不同的检查和外部数据源，部分还会启动 Chromium 或探测端口，完成时间与网络、目标站点和第三方配额有关。更重要的是，一张 OSINT 面板不能证明“全部资产已发现”，也不能把缺少配置直接判成可利用漏洞。
先划清范围：这是一张外部视角的线索表
Web-Check 官方 README 将它描述为面向网站的按需开源情报工具：输入网站地址后，汇总技术栈、服务架构、安全配置和潜在攻击路径。它适合回答“外部访问者能看到什么”，不适合单独回答“我们的资产是否完整”“某项配置是否被利用”“内网服务是否安全”。
扫描之前先写下资产边界。例如目标是自有的 example.com，但营销站 www.example.com、管理入口 admin.example.com 和发信域可能由不同团队维护。DNS 记录映射的是某一时刻的解析状态；CDN、代理与多个地域节点会改变实际返回。把“看到一个 IP”理解成“找到了全部源站”，会造成错判。结果应按域名、环境、采样时间、网络位置和所用工具版本保存。
授权也要写清。Web-Check 的安全说明指出，它可能发起 DNS 查询、TLS 握手、HTTP 请求、常见端口检查与 traceroute，并通过第三方服务补充信息。端口与路由检查属于主动探测；不要对第三方目标、合作方资产或公共演示实例做未经授权的批量测试。本文的步骤只用于你自己管理或明确获准审计的站点。
图 1｜从域名到解析、证书、邮件和 Web 响应。图为自查范围示意，不是扫描结果截图。
选择运行方式：偶尔查看与团队复查不同
图 2｜Web-Check 项目仓库展示的界面局部：多项检查汇集在同一面板。截图来自项目仓库，界面和字段可能随版本变化，图中不是本站测试结果。
单次了解界面，可以先看项目的在线演示。打开页面后输入自己可审计的域名，等待各模块返回。不要把面板里一行“红色”直接记为漏洞：先展开原始值、记录时间与来源，再在自己的 DNS、服务器或 CDN 控制台中复核。在线实例的吞吐量、外部服务额度与维护状态都可能变化，不应写进固定的 SLA。
需要保存团队复查流程时，可按官方 Docker 用法在受控机器上运行：
docker run --rm -p 127.0.0.1:3000:3000 lissy93/web-check
docker run --rm -p 127.0.0.1:3000:3000 lissy93/web-check
这里把端口绑定在本机回环地址，是为了避免把无登录保护的面板直接暴露到公网。打开 http://localhost:3000 后，只扫描已授权目标。官方示例是 docker run -p 3000:3000 lissy93/web-check；对团队环境，绑定方式、网络隔离、身份验证、资源限额和镜像更新还需按实际部署补充。项目安全说明明确指出：服务没有内置账户系统，公开实例应放在有身份验证的反向代理或 VPN 后面。
如果要从源码运行，当前 README 的路径为 git clone、yarn install、yarn build、yarn start。依赖版本请以当时 README 为准，别把复制来的旧 Node 版本写进长期 SOP。部分检查需要 Chromium、traceroute 等运行环境；缺依赖时，空白或失败状态不代表目标安全。对生产资产清单，最好记录容器镜像标签或提交号，便于几周后复查同一规则。
第一轮读结果：先确认“对象是谁”
从目标域名开始，核对 A/AAAA、CNAME、MX、NS、TXT 与证书中的 SAN。目标如果经 CDN，结果可能同时包含边缘地址、代理商信息和证书覆盖的其他名字。把每条发现写进“域名—解析/服务—维护人”表，而不是直接进入整改。例如：
| 线索 | 要向谁核对 | 验收依据 |
|---|---|---|
| 发现未知子域名 | DNS 管理人、业务负责人 | 资产台账、解析历史与当前服务归属 |
| MX 指向旧邮件商 | 邮件管理员 | 实际收信链路、DNS 变更记录 |
| 证书 SAN 含旧名称 | 证书维护人 | 证书签发清单、对应服务是否仍公开 |
| 页面暴露服务标识 | 应用或网关负责人 | 实际响应头及是否含精确版本 |
不能由名称推断业务归属。一个子域名可能是已废弃但尚未回收的外包测试环境，也可能是第三方托管。要进一步看 DNS 控制台、CDN 路由、云资源标签和工单，再决定停用、迁移或保留。此处最有价值的产出不是“发现了多少项”，而是有维护人的资产清单。
图 3｜外部观测值必须回到内部资产台账核对；未知域名先定归属，再判断风险。
第二轮读结果：邮件、证书、响应头分开处理
邮件风险经常被误读。MX 说明邮件接收路线，SPF、DKIM、DMARC 处理发信身份；它们不是同一个开关。Cloudflare 的邮件安全文档解释：SPF 列出获准发送的来源，DKIM 用签名验证发信域及内容，DMARC 规定对校验失败邮件的处置并提供报告。面板发现缺少 DMARC 时，应先盘点合法发信系统、检查对齐和报告，再逐步调整策略。直接把策略改成最严格值，可能让正常通知邮件被拦截。
证书到期、链不完整与弱 TLS 配置是另一条线。先在浏览器、网关配置与证书服务中核对当前证书和自动续期；若 CDN 终止 TLS，分别记录客户端到 CDN 与 CDN 到源站的责任边界。某个扫描节点握手失败，可能是网络或反爬规则造成的，也需要第二种方法复查。可把“发现时间、证书序列号、影响域名、续期负责人与复测结果”写入工单，而非只截一张红字图。
响应头同样要结合应用。HSTS、CSP 等配置的目标和部署前提不同。参考 OWASP Secure Headers Project核对建议，同时查看自己站点的跳转链、子域名、第三方脚本和历史 HTTP 流量。尤其不要在不了解子域名 HTTPS 状态时，机械启用覆盖所有子域的 HSTS。发现 Server 或 X-Powered-By 等标识，也不等于存在可利用漏洞；应确认是否暴露精确版本，再交给服务维护人评估补丁与最小化信息泄露。
图 4｜邮件认证、TLS 和 HTTP 安全头分别对应不同的配置入口与验收方法。
第三轮读结果：历史页面与端口不能直接当事故
站点历史快照、robots.txt、sitemap.xml、公开仓库链接和页面中的技术栈指纹，有助于发现已遗忘路径，但并不证明这些页面仍在线，也不代表其中出现过的内容在当前环境可访问。对历史记录，先确认快照日期，再打开当前路径并由负责人核对；不要把第三方存档里的旧页面误报成现网泄露。若真有敏感数据，按现行访问控制、缓存清理和事件响应流程处理。
开放端口需要看主机、边界和业务用途。端口探测只说明从某个探测位置观察到响应；不证明服务开放给全互联网，不证明有未授权访问，更不能由端口号判断数据库版本。先核对负载均衡、防火墙、安全组和服务配置，再决定限制来源、关闭监听或接受业务需要。对资产所有者来说，一个“意外对外可达的管理端口”通常应比一个缺少装饰性响应头更优先调查，但优先级仍取决于数据敏感度、访问控制与可达范围。
Web-Check 的安全说明还提醒：它会把待查域名或 IP 发送给若干第三方服务；代理日志里可能保留 URL 查询参数中的目标。对未公开的预发布域名、并购项目或内部主机名，先决定是否允许外发。私有实例并不会自动消除第三方数据传输。可以通过 API_ENABLED_CHECKS 或 API_DISABLED_CHECKS 控制检查项；想限制输入主机，可设 API_BLOCKED_HOSTS，但官方说明指出该配置并不完整处理 DNS 解析变化和重定向，严格边界仍需网络防火墙。
图 5｜用可达性、敏感度和证据强度安排复查；颜色只表示处理顺序，不代表已证实漏洞。
一次可执行的 45 分钟自查
开始前，建一张最小记录表：目标域名、业务负责人、授权范围、运行位置、工具版本、开始时间。不要把“30 秒”当成任务预算；完整自查时间主要花在解释和复核，而非等待页面加载。
**前 10 分钟：列范围。**从台账挑一个生产域名和一个对应的发信域，确认谁管理 DNS、证书、网关与应用。明确是否允许端口和 traceroute 检查；若不允许，先在自建实例禁用。把公开实例只用于非敏感的、获授权的域名。
**第 10—20 分钟：跑基线。**保存面板生成的结果、时间和检查失败项；如果界面没有可满足审计要求的持久化能力，使用你们自己的工单系统记录必要字段。项目安全说明称服务本身不保存扫描结果，因此不要把浏览器里出现一次当成已留存证据。失败项单独标记“未完成”，不要视为“通过”。
**第 20—35 分钟：核三类高价值项。**先看未知对外资产与端口，再看证书到期和邮件身份，最后看响应头与历史页面。每项都补一次独立验证：DNS 控制台或 dig、证书管理系统、邮件管理平台、curl -I 或网关日志。记录观测值和内部配置值是否一致。
**最后 10 分钟：给动作。**只把有归属、能复现、影响明确的项进入整改队列。每张工单写负责人、变更动作、回滚条件和复测方式。对证据不足的项设“待复核”，对第三方服务故障设“检查失败”，两者都不计为已解决。下次发布后按相同网络位置和规则再跑一遍，比较变化。
可直接复制的记录模板：
目标/环境：
授权范围与禁用检查：
工具版本/运行位置/检查时间：
观察项与原始值：
内部系统复核：
影响范围与判断：
负责人/动作/回滚：
复测日期与结果：
目标/环境：
授权范围与禁用检查：
工具版本/运行位置/检查时间：
观察项与原始值：
内部系统复核：
影响范围与判断：
负责人/动作/回滚：
复测日期与结果：
图 6｜四段时间对应范围、基线、复核和分派；实际用时随站点复杂度变化。
自建实例本身也要管好
有些团队为了审计自己的网站，把 Web-Check 放到一台能访问内网的服务器上，又将 3000 端口公开。这会把扫描器本身变成新暴露面。项目安全政策列明没有内置登录，服务可以请求目标地址并运行主动检查；它建议用反向代理身份验证或 VPN 限制访问，配合网络隔离、目标限制与速率限制。公有演示站不适合做压力测试。
部署前至少确认四件事：谁能访问实例，实例能访问哪些网络，哪些检查真正需要开启，第三方 API 密钥会消耗谁的额度。项目当前配置支持 API_ENABLE_RATE_LIMIT、API_ENABLED_CHECKS、API_DISABLED_CHECKS 和 API_BLOCKED_HOSTS 等变量；但应用层黑名单不是网络隔离的替代。官方还指出截图等检查会启动无沙箱 Chromium，容器镜像需及时更新；只支持最新版本接收安全修复。生产环境应把这些风险写入部署审批，而不是把工具当成无状态网页随手公开。
如果团队想把它放进日常流程，建议每周只做一次基线核对，变更 DNS、证书、邮件服务或 CDN 后再做事件驱动复查。高频全量扫描可能增加目标负载、触发风控和耗尽外部 API 配额。资产盘点、漏洞扫描、配置审计与人工渗透测试仍各有职责；Web-Check 更适合在这些工作之前把“值得查的线索”集中展示。
Apito 团队：把 API 入口也纳入资产边界
使用 Apito 等 API 接入层时，团队需要区分自己的公开域名、接入服务的官方域名、第三方模型服务域名和内部回调地址。Web-Check 输入一个域名，只会围绕那个目标给出外部线索，不能替整个调用链做安全审计；尤其不要因为一个共享服务的 IP 或证书名称就擅自将其归为自己的资产。
在自己的发布清单中，给“对外 API 域名、回调域名、状态页面、邮件通知域名”各留一行，逐项核对 DNS、证书有效期和责任人。对于 API Key，不要放进扫描目标、查询参数、截图或工单附件。工具返回的信息只用于决定哪些配置要复核，真正的密钥权限、调用日志和账单仍在相应管理后台检查。
发布前可用的验收清单
- 目标属于自有资产或已获得书面授权，主动检查范围已确认。
- 结果记录了采样时间、工具版本、网络位置和失败检查项。
- 未知域名、IP、端口有业务负责人，不能仅凭图标定性。
- SPF、DKIM、DMARC 的处置与合法发信系统相容。
- TLS 与安全头在真实访问链路上复测过，变更有回滚方案。
- 历史页面与现网状态分开记录，避免把旧快照当新事故。
- 自建 Web-Check 有访问控制、网络隔离、更新计划和密钥额度管理。
- 整改后按同一口径复测，保留前后差异与验收人。
资料与核验口径
本文依据 Web-Check 项目仓库、官方安全政策、OWASP 安全响应头项目与 Cloudflare 邮件安全记录文档整理。Star 数、部署依赖、功能列表与第三方接口会变化；正式执行时以当日仓库版本和自己的运行环境为准。文中的流程图为解释性示意，不代表对某个真实站点的实测。
常见问题（FAQ）
输入域名后，Web-Check 能找出所有漏洞吗？
不能。它汇总公开线索和部分主动检查结果，可能遗漏资产，也不能证明每项配置都可被利用。把发现交给资产负责人核对，再用适合的配置审计、漏洞测试或人工验证确认。
为什么有的模块一直转圈或没有结果？
可能是目标防护、网络位置、第三方 API 限额、依赖程序缺失或检查超时。记录“检查失败”，查看运行日志和依赖，必要时换方法复测；空白不等于安全。
在线演示与 Docker 自建该怎么选？
偶尔查看自己公开域名可用在线实例。涉及敏感目标、反复复查或团队共享时，选择受控部署，并处理身份验证、网络访问、第三方数据外发、更新和资源限额。自建不自动等于更安全。
缺少 DMARC 或 HSTS 就一定是严重漏洞吗？
不一定。它说明配置状态需要核对。DMARC 需要先盘点合法发信源，HSTS 要结合 HTTPS 与子域名情况部署；影响大小由实际业务和访问路径决定。
能否拿它检查别人公司的网站？
只有在资产所有者允许、测试范围明确时才应做主动检查。公开可访问不代表允许端口扫描、批量请求或压力测试；不要用公共演示实例试探未经授权的目标。
