统一HTML中的外部链接安全标记的自动化工具

HTMLProofer 能做什么、不能做什么

html_doc.search("a[href]").each do |link|
  href = link.attributes["href"]&.value
  next unless href && href.start_with?("http") && !href.include?(current_host)
  link.set_attribute("rel", "noopener noreferrer") unless link.attributes["rel"]
end

C# + HtmlAgilityPack 的生产级过滤要点

如果你的系统基于 .NET，那么 HtmlAgilityPack 比正则表达式靠谱得多。但有几个细节必须严格注意。首先，必须启用 OptionFixNestedTags = true，否则自闭合标签像 这种，解析会出错。其次，SelectNodes("//a[@href]") 会遗漏带有命名空间的 HTML，比如 XHTML，应该改用 SelectNodes("descendant-or-self::a[@href]")。第三，判断外部链接不能只看协议头，一定要真正解析 URL：用 Uri.TryCreate(href, UriKind.Absolute, out var uri)，然后在 uri.Host 层面与 currentHost 进行比对。

此处有一个常见陷阱——如果你想保留内部锚点（比如 #section1）或者同源的绝对路径（比如 /about），使用正则表达式匹配风险极高。正确的做法是采用 URI 解析的分支路径，而不是在正则表达式中绕圈子。

白名单机制必须由后端控制

还有一个关键点需要强调：白名单。前端硬编码白名单，形同虚设。可信域名列表必须存放在配置中心或数据库里，支持热更新。每次保存 HTML 之前，后端必须逐一校验每个 href，不在白名单内的外链直接返回 400 状态码错误，并附带具体域名信息。而且白名单条目应该允许通配符匹配（比如 *.gov.cn）和端口限定（比如 docs.example.com:8080）。另外，mailto:、tel: 这类非 HTTP 协议要单独设置放行规则，避免误拦截。

归根结底，添加 rel 本身并非真正的难点。真正的难点在于定义“外部链接”的边界——当前部署的域名、CDN 域名、SaaS 子域、测试环境地址，这些在不同阶段都可能被视为“内部”。工具可以实现自动化，但策略必须随业务持续调整与校准，这才是做好这项工作的核心所在。