安全建议
介绍 API Key 的保护策略、服务端代理架构设计、版本控制隔离以及密钥泄露应急响应流程。
AnyStarX 的 API Key 拥有直接消耗账户额度与调用模型资源的完整权限。在任何集成方案中，均应将密钥作为核心机密凭据进行保护。
防范客户端与前端暴露
严禁将 AnyStarX 的 API Key 写入任何由客户端直接执行的代码中，包括浏览器网页的 JavaScript 脚本、微信小程序、以及移动端原生代码应用：
// 错误示例：禁止在前端代码中直接暴露真实密钥
const apiKey = 'sk-...';由于前端代码、网络请求和静态资源均运行在不受信的用户设备上，页面中的所有变量与明文请求头都可以被用户端直接提取。标准的系统架构应当通过后端服务进行转发：
- 客户端仅与自建的后端服务进行通信，并完成用户身份鉴权。
- 自建后端服务在安全的服务器环境中存储 AnyStarX 的 API Key。
- 后端服务校验请求合法性后，代为向 AnyStarX 发起真实调用并返回结果。
版本控制与敏感信息隔离
在项目初始化阶段，应当配置好版本控制系统的忽略规则，防止包含密钥的本地配置文件被推送到公开或私有代码仓库中。
确保项目根目录下的 .gitignore 文件已加入常用环境配置文件：
.env
.env.local
.env.*.local如果不慎将包含有效密钥的文件提交到了 Git 仓库：
- 立即登录控制台废除该 API Key，切断外部恶意利用通道。
- 生成新的有效密钥，并更新部署环境的实际配置。
- 对 Git 提交历史执行清理重写（例如使用 git-filter-repo 彻底抹去历史记录），或更换为全新仓库。
服务端代理架构
将 AnyStarX 集成进企业产品或面向最终用户的应用时，推荐在架构中部署服务端代理层，以实现精细化的安全管控：
- 下游用户鉴权：在服务端校验业务用户的登录态与权限，防止未授权调用。
- 速率与额度限制：针对每个终端用户或 IP 地址设置每分钟调用频次上限与每日用量配额。
- 调用审计与监控：记录每一笔请求的耗时、模型 ID 与 HTTP 响应码，建立异常流量告警。
- 模型路由收敛：在服务端决定当前请求使用的模型版本，避免由前端直接指定高成本模型。
团队权限与凭证管理
在多人协同开发或多服务部署的组织环境中，建议执行最小权限和职责分离原则：
- 为每位开发人员与每个独立服务实例分别颁发单独的 API Key，避免凭据混用。
- 生产环境、预发测试环境与本地调试环境完全隔离，使用不同密钥。
- 团队成员离职、更换开发笔记本或设备丢失时，立即在管理控制台吊销对应的密钥。
- 禁止通过聊天软件、团队协作文档或邮件直接传输未经加密的密钥文本。
密钥泄露应急处理
一旦发现监控指标中出现异常调用高峰，或怀疑 API Key 存在泄露风险，应立即执行应急处理：
- 吊销凭证：登录 AnyStarX 控制台，立即删除处于风险中的旧 API Key。
- 生成新凭证：创建全新 API Key，并更新服务器集群或容器的环境变量配置。
- 核查账单与用量：审查控制台中的最近调用日志，确认是否存在异常请求与被盗用记录。
- 排查泄露源头：全面排查公开的代码仓库、构建日志、服务端错误堆栈、前端打包产物以及通信记录，定位泄露节点并彻底修复。