llms-txt-hub安全架构揭秘：CSRF防护、速率限制与Google Web Risk三重防线

【免费下载链接】llms-txt-hub🤖 The largest directory for AI-ready documentation and tools implementing the proposed llms.txt standard项目地址: https://gitcode.com/gh_mirrors/ll/llms-txt-hub

llms-txt-hub 是目前最大的 llms.txt 标准文档与工具目录平台，收录了数千个 AI-ready 网站的 llms.txt 文件。作为一个开放提交、自动审核、面向全网用户的高流量站点，它的安全架构直接决定平台能否抵御恶意提交与攻击。本文将从源码层面拆解 llms-txt-hub 的CSRF 防护、速率限制与Google Web Risk 恶意网址检测三重防线，看看这套开源项目究竟如何做到"来者可查、提交可控、危险网址零放行"。

llms-txt-hub 面临哪些真实安全威胁？

任何允许用户提交网址并自动发布的平台，都会遇到三类典型攻击：

• CSRF 跨站请求伪造：攻击者在恶意网页中诱导已登录用户"代为提交"，绕过身份校验。
• 接口滥用与刷量：脚本批量提交垃圾网址、疯狂调用查询接口，拖垮服务器。
• 恶意网址投毒：把钓鱼、挂马、恶意软件下载链接伪装成正常网站混入目录。

针对这三类威胁，llms-txt-hub 分别部署了对应防线，形成"认证层—限流层—内容信誉层"的纵深防御体系。

第一道防线：CSRF 防护，让伪造请求无处遁形

llms-txt-hub 的 CSRF 防护核心位于 csrf-protection.ts 与 middleware-csrf.ts 两个文件，采用业界标准的双提交 Cookie 模式（Double-Submit Cookie），实现难度低且不依赖会话存储。

令牌如何生成与存储？

服务端调用crypto.randomBytes(32)生成 256 位随机令牌，并以HTTP-only Cookie方式写入浏览器：

• 令牌有效期 24 小时，过期自动失效；
• Cookie 标记httpOnly（防 XSS 窃取）、sameSite: 'strict'（阻止跨站携带）；
• 生产环境强制开启secure属性，仅允许 HTTPS 传输。

请求如何被验证？

用户提交表单或 AJAX 请求时，客户端需同时携带 Cookie 中的令牌与请求头/表单中的_csrf字段（由 csrf-provider.tsx 组件在页面加载时自动初始化）。服务端校验流程如下：

1. GET、HEAD、OPTIONS 等安全方法直接放行；
2. 携带 Bearer Token 的 API 请求视为已认证，跳过检查；
3. 从请求头x-csrf-token、表单字段或 URL 参数中提取令牌；
4. 从 Cookie 中取出存储令牌并比对是否过期；
5. 用crypto.timingSafeEqual做时间恒定比较，防止时序侧信道攻击；
6. 校验 Origin 与 Host 是否同源，阻断跨站伪造。

校验失败统一返回 403 与CSRF_VALIDATION_FAILED错误码，全程还会记录脱敏后的令牌哈希日志，方便安全审计。

第二道防线：速率限制，从源头掐断接口滥用

仅靠 CSRF 拦不住"合法登录后"的脚本轰炸，所以 llms-txt-hub 在 rate-limiting 包中基于Upstash Redis + 滑动窗口算法构建了统一限流层。

分接口精细化限流策略

不同接口的风险等级不同，限流阈值也各不相同（源码中RATE_LIMITS常量）：

提交接口门槛最高，每小时仅允许 10 次，从业务层面杜绝"批量灌库"。

客户端识别如何防伪造？

限流的关键在于"识别谁在请求"。llms-txt-hub 采用多级回退识别链（见 index.ts）：

1. 优先读取 Vercel 专属头x-vercel-forwarded-for（防伪造的最可靠来源）；
2. 依次回退到x-forwarded-for、x-real-ip、cf-connecting-ip；
3. 最后兜底用 User-Agent 哈希作为标识。

超过阈值时返回 429 状态码，并附上Retry-After与X-RateLimit-*响应头，客户端可据此自动退避重试。

第三道防线：Google Web Risk，恶意网址零容忍

提交内容本身的"善恶判定"交给第三层：Google Web Risk 恶意网址信誉检查。这部分实现在 web-risk.ts，是 llms-txt-hub 提交信任体系（submission-trust）的关键一环。

检查哪些威胁类型？

llms-txt-hub 针对每个提交网址，向 Google Web Risk API 查询四类威胁：

• MALWARE：传播恶意软件的站点；
• SOCIAL_ENGINEERING：钓鱼、欺诈类社工网站；
• UNWANTED_SOFTWARE：捆绑流氓软件下载站；
• SOCIAL_ENGINEERING_EXTENDED_COVERAGE：更广覆盖的社工扩展类别。

工业级的调用实现细节

代码里有几个值得学习的工程细节：

• 超时保护：每次查询设置严格截止时间，超时即中止请求并返回"未知"结论，绝不拖垮主流程（fetchWithDeadline函数）；
• 响应体上限：限制响应体不超过 16KB，防止恶意响应内存膨胀；
• 结果缓存新鲜度：标记为安全的网址带有过期时间expiresAt，过期后重新校验，平衡性能与时效；
• 失败降级：API Key 缺失、超时或解析失败时返回unknown状态，走"保守拒绝或稍后重试"策略，绝不误放行。

提交审核如何串联三层防线？

在 check-url/route.ts 中可以看到完整链路：请求先过限流检查（每 IP 每分钟 10 次）→ URL 格式与协议白名单校验 → 交由网络检查器抓取页面 → 同步调用Google Web Risk做信誉判定。任一环节不合格，都会返回安全提示文案（不泄露内部细节），只有全部通过才会进入发布队列。

总结：开源项目的安全范本

llms-txt-hub 用CSRF 双提交 Cookie 防护、Redis 滑动窗口限流与Google Web Risk 信誉检查三层防线，覆盖了从请求伪造、接口滥用到恶意投毒的完整攻击面，且每一层都遵循"失败保守、降级不误放"的安全原则。

如果你也在做类似的开放提交类 Web 项目，不妨直接 clone 这个仓库（git clone https://gitcode.com/gh_mirrors/ll/llms-txt-hub）研究它的安全模块源码——csrf-protection.ts、rate-limiting 和 web-risk.ts 都是可以直接借鉴的实战级实现。

【免费下载链接】llms-txt-hub🤖 The largest directory for AI-ready documentation and tools implementing the proposed llms.txt standard项目地址: https://gitcode.com/gh_mirrors/ll/llms-txt-hub