FreeLLMAPI 安全策略解读密钥加密、认证边界与自托管加固指南【免费下载链接】freellmapi7.4 billion tokens per month. 34 free LLM providers. 635 free model endpoints. All behind one /v1 endpoint, plus any custom OpenAI-compatible endpoint. Smart routing, automatic failover, encrypted keys. Personal experimentation only.项目地址: https://gitcode.com/GitHub_Trending/fr/freellmapiFreeLLMAPI 是一款把 34 个免费 LLM 提供商的 635 个模型端点收敛到单一/v1接口的自托管网关其安全模型围绕真实凭证展开提供商 API KeySQLite 中加密存储、统一的/v1Bearer Token 以及仪表盘账号。本文以仓库根目录的 SECURITY.md 为骨架结合 server/src/lib/crypto.ts、server/src/lib/password.ts、server/src/services/auth.ts、server/src/lib/db-backup.ts 等源码系统讲解它的漏洞报告流程、受支持版本策略、安全边界定义以及自托管者可以落地的加固措施。安全策略总览三类必须保护的凭证FreeLLMAPI 的安全策略建立在三个明确的安全目标之上任何能暴露其中之一的漏洞都会被严肃对待提供商 API Key用户在 Keys 页面粘贴的各家模型提供商密钥落盘时使用 AES-256-GCM 加密统一/v1Bearer Token形如freellmapi-…的网关级令牌客户端应用通过它访问代理接口仪表盘账号邮箱 密码的管理员登录凭证用于访问/api/*管理面。仓库中大量测试直接围绕这三类凭证展开例如 server/src/tests/routes/keys.test.ts、server/src/tests/lib/crypto.test.ts、server/src/tests/routes/proxy-auth-cors.test.ts 等验证了错误密钥应被拒绝这一基本安全前提。受支持版本与修复节奏版本支持状态0.6.x当前是 —— 安全修复只落在这个版本线0.5.x尽力而为建议升级0.4.x 及更早否策略明确说明安全修复只随最新版本线发布不对旧版本做 backport。因此保持补丁最新最直接的方式就是跟踪0.6.xDocker 用户只需定期重新拉取:latest镜像即可。漏洞报告渠道与预期响应首选渠道GitHub 私有漏洞报告通过仓库 Security 标签页的Report a vulnerability按钮提交会与维护者建立私有对话线程避免细节暴露在公开 issue 中。备选渠道邮件发送邮件至supportfreellmapi.co主题须包含[freellmapi security]。重要约束在修复发布之前请勿为安全缺陷开启公开 issue、PR 或 discussion。一份高质量报告应包含受影响的版本或 commit以及运行方式Docker、npm run dev、桌面应用影响面 —— 攻击者能获得什么读取密钥、绕过认证、RCE 等可复现步骤确切的请求、配置或涉及的.env设置并脱敏你的真实提供商 Key可分享的相关服务器日志。报告后的预期确认数天内收到回复。这是由单人维护的业余项目并非 24 小时 SLA修复按严重程度尽力而为首次回复会给出大致时间线披露修复发布后披露报告人可选择在 release notes 中署名无赏金项目没有资金支付 bug bounty提供的是署名与感谢。安全范围Scope什么算漏洞什么不算范围内路由服务器本身/v1代理、/api/*管理路由、/mcp端点仪表盘认证邮箱 密码账号scrypt 哈希、会话令牌与统一的freellmapi-…API Key密钥处理链路AES-256-GCM 静态加密、ENCRYPTION_KEY的使用、加密数据库备份、密钥导入/导出Electron 桌面应用及其本地数据目录Docker 镜像与打包Dockerfile、docker-compose.yml、安装脚本包括任何会把机密泄漏进镜像层或日志的内容Premium 许可证密钥校验与签名的 catalog 订阅源。范围外明确不算漏洞上游 LLM 提供商自身的漏洞应报告给对应提供商但网关与它们通信的方式存在 bug仍在范围内运营者主动暴露到公网FreeLLMAPI 是单用户、可信网络工具默认绑定127.0.0.1HOST_BIND0.0.0.0是有警告的显式选择且设计上不提供多租户认证。我把服务放到公网 IP 上被人刷了配额属于预期行为而非漏洞。从 server/src/lib/config.ts 可以看到默认 host 是::IPv6 全接口或回落 IPv4HOST 环境变量可覆盖进一步印证了默认不面向公网的设计取向社会工程、钓鱼、物理接触或假设主机/账号已被攻破的攻击无实际影响的自动化扫描器输出。加固建议面向自托管者逐条拆解1. 保持 localhost 绑定只在可信网络中将HOST_BIND0.0.0.0置为真且若必须更广泛可达应放在带 TLS 与认证的反向代理之后绝不能直接暴露到公网。2. 保护好ENCRYPTION_KEY与.env这是加固建议中分量最重的一条。原因可以从 server/src/lib/crypto.ts 的源码中看得很清楚算法aes-256-gcm密钥必须是 32 字节64 个十六进制字符。parseHexKey会前置校验长度与字符集长度不对会立刻报错并给出生成命令而不是在首次加密时才抛出晦涩的node:crypto错误密钥来源优先级显式ENCRYPTION_KEY环境变量 数据库旁自动生成的密钥文件.encryption-key 旧版 settings 表迁移 全新生成。生产环境必须显式设置ENCRYPTION_KEY否则在NODE_ENVproduction下会直接抛出ENCRYPTION_KEY is required in production for API key encryption生成方式node -e console.log(require(crypto).randomBytes(32).toString(hex))密钥文件落盘细节密钥文件位于数据库同目录、与数据库分开存放而非存在数据库的 settings 表里并使用临时文件 rename 的原子写入同时以chmod 0600限制为属主可读 —— 详见 server/src/lib/file-permissions.ts 的restrictToOwner实现。之所以丢失密钥即丢失所有存储的 Key是因为每个提供商密钥都是用这把主密钥加密的主密钥不可恢复则密文永远无法解密。此外 server/src/lib/crypto.ts 还做了几件值得注意的加固GCM auth tag 长度钉死为 16 字节AUTH_TAG_BYTES 16堵住4–16 字节任意 tag 被接受的截断攻击面RFC 5116 §3.2密钥指纹encryptionKeyFingerprint()用 sha256 截断 64 位输出用于数据库备份头部标识这份密文是用哪把钥匙写的恢复前可据此判断密钥是否匹配又不至于帮助恢复密钥掩码展示maskKey对短密钥5 字符全部打码、5–8 字符只露最后 2 位、长密钥露前4...后4确保 UI 里展示的maskedKey永远不足以反推完整密钥 —— 这在代理凭证、自托管 Ollama token、本地开发密钥等短密钥场景尤其关键。3. 及时更新定期重新拉取 Docker 镜像或git pull后重新构建依赖与路由器的修复会随功能版本一起发布。这与仅支持最新 0.6.x 版本线的策略相互呼应。4. 轮换泄漏的密钥如果持有统一 API Key 的客户端失陷从 Keys 页面重新生成该密钥同时替换可疑的提供商 Key。由于路由器会自动故障转移到兄弟 Key多 Key 池化轮换不会造成停机。这一点与 server/src/lib/key-parser.ts 的密钥池设计一致一个平台可挂载多个 KeyPREFIX_MAP通过GOOGLE_、GROQ_等前缀自动识别平台导入/导出格式.env、CSV、JSON、auth JSON均围绕一批凭证组织。纵深防御源码层面的安全实现细节仪表盘认证scrypt 密码哈希 不透明会话令牌server/src/lib/password.ts 使用 Node 内置 scrypt无外部依赖哈希密码存储格式为scrypt$saltHex$hashHex盐 16 字节、派生密钥 64 字节并用crypto.timingSafeEqual做常量时间比较抵御时序侧信道。server/src/services/auth.ts 实现了会话生命周期管理会话令牌为 32 字节随机值只存哈希sha256(token)落库原始令牌仅返回给客户端会话 TTL 为 30 天过期自动删除修改密码会使所有会话失效DELETE FROM sessions WHERE user_id ?登录标识使用规范化邮箱trim 小写防止大小写歧义。这与 SECURITY.md 中仪表盘认证scrypt、会话令牌在范围内的定义严格对应。日志脱敏密钥不出现在日志里server/src/lib/log-redaction.ts 内置了对freellmapi-…这类网关签发密钥的正则脱敏规则/\bfreellmapi-[A-Za-z0-9_\-]{8,}/gserver/src/lib/error-redaction.ts 同样会对请求中的密钥做[redacted-key]替换。这意味着即使报告漏洞时附上服务器日志也只会暴露已被脱敏的内容 —— 这解释了 SECURITY.md 为什么鼓励分享失败请求附近的日志。加密数据库备份备份即密文server/src/lib/db-backup.ts 表明备份链路同样加密备份文件使用独立的FREEAPI_DB_BACKUP_KEY或回退ENCRYPTION_KEY做 AES-256-GCM 加密载荷带FAPIBK1魔数 12 字节 IV 16 字节 auth tag支持本地路径、HTTP(S) PUT、以及 Hugging Face 仓库走 commit APIblob 以 base64 文本上传兼容 Xet 存储写入时以mode: 0o600创建并调用restrictToOwner收紧权限 —— 因为备份虽然是密文但解密密钥就在同机的.env里默认每 5 分钟调度一次FREEAPI_DB_BACKUP_INTERVAL_MS可调启动时若发现数据库不存在则自动从备份恢复。自托管安全清单速查动作说明相关文件保持默认绑定仅在本机使用不设HOST_BIND0.0.0.0server/src/lib/config.ts生产设置ENCRYPTION_KEY64 位十六进制32 字节显式设置而非依赖开发回退server/src/lib/crypto.ts.env不入 git密钥与配置文件隔离、异地备份仓库根目录.env约定定期拉取最新镜像跟踪 0.6.x 版本线SECURITY.md失陷即轮换Keys 页重新生成统一 Key替换可疑提供商 Keyserver/src/lib/key-parser.ts启用加密备份配置FREEAPI_DB_BACKUP_TARGET与FREEAPI_DB_BACKUP_KEYserver/src/lib/db-backup.ts结论FreeLLMAPI 的安全策略是一份务实的、面向单用户可信网络场景的文档它把真实凭证不泄漏作为核心目标明确圈定了范围与边界公网暴露不在其责并通过源码层的 AES-256-GCM 静态加密、scrypt 密码哈希、常量时间比较、会话令牌哈希存储、日志脱敏与加密备份等机制把文档中的每一项声明都落到了实现上。对自托管者而言最重要的三件事始终是显式设置并安全保管ENCRYPTION_KEY、保持 localhost 绑定、及时更新到最新版本线。【免费下载链接】freellmapi7.4 billion tokens per month. 34 free LLM providers. 635 free model endpoints. All behind one /v1 endpoint, plus any custom OpenAI-compatible endpoint. Smart routing, automatic failover, encrypted keys. Personal experimentation only.项目地址: https://gitcode.com/GitHub_Trending/fr/freellmapi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FreeLLMAPI 安全策略解读：密钥加密、认证边界与自托管加固指南
FreeLLMAPI 安全策略解读密钥加密、认证边界与自托管加固指南【免费下载链接】freellmapi7.4 billion tokens per month. 34 free LLM providers. 635 free model endpoints. All behind one /v1 endpoint, plus any custom OpenAI-compatible endpoint. Smart routing, automatic failover, encrypted keys. Personal experimentation only.项目地址: https://gitcode.com/GitHub_Trending/fr/freellmapiFreeLLMAPI 是一款把 34 个免费 LLM 提供商的 635 个模型端点收敛到单一/v1接口的自托管网关其安全模型围绕真实凭证展开提供商 API KeySQLite 中加密存储、统一的/v1Bearer Token 以及仪表盘账号。本文以仓库根目录的 SECURITY.md 为骨架结合 server/src/lib/crypto.ts、server/src/lib/password.ts、server/src/services/auth.ts、server/src/lib/db-backup.ts 等源码系统讲解它的漏洞报告流程、受支持版本策略、安全边界定义以及自托管者可以落地的加固措施。安全策略总览三类必须保护的凭证FreeLLMAPI 的安全策略建立在三个明确的安全目标之上任何能暴露其中之一的漏洞都会被严肃对待提供商 API Key用户在 Keys 页面粘贴的各家模型提供商密钥落盘时使用 AES-256-GCM 加密统一/v1Bearer Token形如freellmapi-…的网关级令牌客户端应用通过它访问代理接口仪表盘账号邮箱 密码的管理员登录凭证用于访问/api/*管理面。仓库中大量测试直接围绕这三类凭证展开例如 server/src/tests/routes/keys.test.ts、server/src/tests/lib/crypto.test.ts、server/src/tests/routes/proxy-auth-cors.test.ts 等验证了错误密钥应被拒绝这一基本安全前提。受支持版本与修复节奏版本支持状态0.6.x当前是 —— 安全修复只落在这个版本线0.5.x尽力而为建议升级0.4.x 及更早否策略明确说明安全修复只随最新版本线发布不对旧版本做 backport。因此保持补丁最新最直接的方式就是跟踪0.6.xDocker 用户只需定期重新拉取:latest镜像即可。漏洞报告渠道与预期响应首选渠道GitHub 私有漏洞报告通过仓库 Security 标签页的Report a vulnerability按钮提交会与维护者建立私有对话线程避免细节暴露在公开 issue 中。备选渠道邮件发送邮件至supportfreellmapi.co主题须包含[freellmapi security]。重要约束在修复发布之前请勿为安全缺陷开启公开 issue、PR 或 discussion。一份高质量报告应包含受影响的版本或 commit以及运行方式Docker、npm run dev、桌面应用影响面 —— 攻击者能获得什么读取密钥、绕过认证、RCE 等可复现步骤确切的请求、配置或涉及的.env设置并脱敏你的真实提供商 Key可分享的相关服务器日志。报告后的预期确认数天内收到回复。这是由单人维护的业余项目并非 24 小时 SLA修复按严重程度尽力而为首次回复会给出大致时间线披露修复发布后披露报告人可选择在 release notes 中署名无赏金项目没有资金支付 bug bounty提供的是署名与感谢。安全范围Scope什么算漏洞什么不算范围内路由服务器本身/v1代理、/api/*管理路由、/mcp端点仪表盘认证邮箱 密码账号scrypt 哈希、会话令牌与统一的freellmapi-…API Key密钥处理链路AES-256-GCM 静态加密、ENCRYPTION_KEY的使用、加密数据库备份、密钥导入/导出Electron 桌面应用及其本地数据目录Docker 镜像与打包Dockerfile、docker-compose.yml、安装脚本包括任何会把机密泄漏进镜像层或日志的内容Premium 许可证密钥校验与签名的 catalog 订阅源。范围外明确不算漏洞上游 LLM 提供商自身的漏洞应报告给对应提供商但网关与它们通信的方式存在 bug仍在范围内运营者主动暴露到公网FreeLLMAPI 是单用户、可信网络工具默认绑定127.0.0.1HOST_BIND0.0.0.0是有警告的显式选择且设计上不提供多租户认证。我把服务放到公网 IP 上被人刷了配额属于预期行为而非漏洞。从 server/src/lib/config.ts 可以看到默认 host 是::IPv6 全接口或回落 IPv4HOST 环境变量可覆盖进一步印证了默认不面向公网的设计取向社会工程、钓鱼、物理接触或假设主机/账号已被攻破的攻击无实际影响的自动化扫描器输出。加固建议面向自托管者逐条拆解1. 保持 localhost 绑定只在可信网络中将HOST_BIND0.0.0.0置为真且若必须更广泛可达应放在带 TLS 与认证的反向代理之后绝不能直接暴露到公网。2. 保护好ENCRYPTION_KEY与.env这是加固建议中分量最重的一条。原因可以从 server/src/lib/crypto.ts 的源码中看得很清楚算法aes-256-gcm密钥必须是 32 字节64 个十六进制字符。parseHexKey会前置校验长度与字符集长度不对会立刻报错并给出生成命令而不是在首次加密时才抛出晦涩的node:crypto错误密钥来源优先级显式ENCRYPTION_KEY环境变量 数据库旁自动生成的密钥文件.encryption-key 旧版 settings 表迁移 全新生成。生产环境必须显式设置ENCRYPTION_KEY否则在NODE_ENVproduction下会直接抛出ENCRYPTION_KEY is required in production for API key encryption生成方式node -e console.log(require(crypto).randomBytes(32).toString(hex))密钥文件落盘细节密钥文件位于数据库同目录、与数据库分开存放而非存在数据库的 settings 表里并使用临时文件 rename 的原子写入同时以chmod 0600限制为属主可读 —— 详见 server/src/lib/file-permissions.ts 的restrictToOwner实现。之所以丢失密钥即丢失所有存储的 Key是因为每个提供商密钥都是用这把主密钥加密的主密钥不可恢复则密文永远无法解密。此外 server/src/lib/crypto.ts 还做了几件值得注意的加固GCM auth tag 长度钉死为 16 字节AUTH_TAG_BYTES 16堵住4–16 字节任意 tag 被接受的截断攻击面RFC 5116 §3.2密钥指纹encryptionKeyFingerprint()用 sha256 截断 64 位输出用于数据库备份头部标识这份密文是用哪把钥匙写的恢复前可据此判断密钥是否匹配又不至于帮助恢复密钥掩码展示maskKey对短密钥5 字符全部打码、5–8 字符只露最后 2 位、长密钥露前4...后4确保 UI 里展示的maskedKey永远不足以反推完整密钥 —— 这在代理凭证、自托管 Ollama token、本地开发密钥等短密钥场景尤其关键。3. 及时更新定期重新拉取 Docker 镜像或git pull后重新构建依赖与路由器的修复会随功能版本一起发布。这与仅支持最新 0.6.x 版本线的策略相互呼应。4. 轮换泄漏的密钥如果持有统一 API Key 的客户端失陷从 Keys 页面重新生成该密钥同时替换可疑的提供商 Key。由于路由器会自动故障转移到兄弟 Key多 Key 池化轮换不会造成停机。这一点与 server/src/lib/key-parser.ts 的密钥池设计一致一个平台可挂载多个 KeyPREFIX_MAP通过GOOGLE_、GROQ_等前缀自动识别平台导入/导出格式.env、CSV、JSON、auth JSON均围绕一批凭证组织。纵深防御源码层面的安全实现细节仪表盘认证scrypt 密码哈希 不透明会话令牌server/src/lib/password.ts 使用 Node 内置 scrypt无外部依赖哈希密码存储格式为scrypt$saltHex$hashHex盐 16 字节、派生密钥 64 字节并用crypto.timingSafeEqual做常量时间比较抵御时序侧信道。server/src/services/auth.ts 实现了会话生命周期管理会话令牌为 32 字节随机值只存哈希sha256(token)落库原始令牌仅返回给客户端会话 TTL 为 30 天过期自动删除修改密码会使所有会话失效DELETE FROM sessions WHERE user_id ?登录标识使用规范化邮箱trim 小写防止大小写歧义。这与 SECURITY.md 中仪表盘认证scrypt、会话令牌在范围内的定义严格对应。日志脱敏密钥不出现在日志里server/src/lib/log-redaction.ts 内置了对freellmapi-…这类网关签发密钥的正则脱敏规则/\bfreellmapi-[A-Za-z0-9_\-]{8,}/gserver/src/lib/error-redaction.ts 同样会对请求中的密钥做[redacted-key]替换。这意味着即使报告漏洞时附上服务器日志也只会暴露已被脱敏的内容 —— 这解释了 SECURITY.md 为什么鼓励分享失败请求附近的日志。加密数据库备份备份即密文server/src/lib/db-backup.ts 表明备份链路同样加密备份文件使用独立的FREEAPI_DB_BACKUP_KEY或回退ENCRYPTION_KEY做 AES-256-GCM 加密载荷带FAPIBK1魔数 12 字节 IV 16 字节 auth tag支持本地路径、HTTP(S) PUT、以及 Hugging Face 仓库走 commit APIblob 以 base64 文本上传兼容 Xet 存储写入时以mode: 0o600创建并调用restrictToOwner收紧权限 —— 因为备份虽然是密文但解密密钥就在同机的.env里默认每 5 分钟调度一次FREEAPI_DB_BACKUP_INTERVAL_MS可调启动时若发现数据库不存在则自动从备份恢复。自托管安全清单速查动作说明相关文件保持默认绑定仅在本机使用不设HOST_BIND0.0.0.0server/src/lib/config.ts生产设置ENCRYPTION_KEY64 位十六进制32 字节显式设置而非依赖开发回退server/src/lib/crypto.ts.env不入 git密钥与配置文件隔离、异地备份仓库根目录.env约定定期拉取最新镜像跟踪 0.6.x 版本线SECURITY.md失陷即轮换Keys 页重新生成统一 Key替换可疑提供商 Keyserver/src/lib/key-parser.ts启用加密备份配置FREEAPI_DB_BACKUP_TARGET与FREEAPI_DB_BACKUP_KEYserver/src/lib/db-backup.ts结论FreeLLMAPI 的安全策略是一份务实的、面向单用户可信网络场景的文档它把真实凭证不泄漏作为核心目标明确圈定了范围与边界公网暴露不在其责并通过源码层的 AES-256-GCM 静态加密、scrypt 密码哈希、常量时间比较、会话令牌哈希存储、日志脱敏与加密备份等机制把文档中的每一项声明都落到了实现上。对自托管者而言最重要的三件事始终是显式设置并安全保管ENCRYPTION_KEY、保持 localhost 绑定、及时更新到最新版本线。【免费下载链接】freellmapi7.4 billion tokens per month. 34 free LLM providers. 635 free model endpoints. All behind one /v1 endpoint, plus any custom OpenAI-compatible endpoint. Smart routing, automatic failover, encrypted keys. Personal experimentation only.项目地址: https://gitcode.com/GitHub_Trending/fr/freellmapi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考