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-hubllms-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 组件在页面加载时自动初始化。服务端校验流程如下GET、HEAD、OPTIONS 等安全方法直接放行携带 Bearer Token 的 API 请求视为已认证跳过检查从请求头x-csrf-token、表单字段或 URL 参数中提取令牌从 Cookie 中取出存储令牌并比对是否过期用crypto.timingSafeEqual做时间恒定比较防止时序侧信道攻击校验 Origin 与 Host 是否同源阻断跨站伪造。校验失败统一返回 403 与CSRF_VALIDATION_FAILED错误码全程还会记录脱敏后的令牌哈希日志方便安全审计。第二道防线速率限制从源头掐断接口滥用仅靠 CSRF 拦不住合法登录后的脚本轰炸所以 llms-txt-hub 在 rate-limiting 包中基于Upstash Redis 滑动窗口算法构建了统一限流层。分接口精细化限流策略不同接口的风险等级不同限流阈值也各不相同源码中RATE_LIMITS常量接口类型限制额度时间窗口提交接口SUBMIT_API10 次1 小时认证接口AUTH_API20 次15 分钟元数据抓取METADATA_API50 次1 小时会员接口MEMBERS_API200 次1 小时贡献接口CONTRIBUTIONS_API100 次1 小时通用 APIGENERAL_API500 次1 小时提交接口门槛最高每小时仅允许 10 次从业务层面杜绝批量灌库。客户端识别如何防伪造限流的关键在于识别谁在请求。llms-txt-hub 采用多级回退识别链见 index.ts优先读取 Vercel 专属头x-vercel-forwarded-for防伪造的最可靠来源依次回退到x-forwarded-for、x-real-ip、cf-connecting-ip最后兜底用 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考