摘要
自媒体创业者利用TRAE SOLO的AI Agent能力，对部署在阿里云OSS +函数计算上的字幕校准工具进行了完整的安全审计。SOLO自主操作阿里云控制台，尝试了FC自定义域名认证、API网关代理等多种方案，最终基于代码分析确定了最优的安全策略，实现了零成本的API安全防护优化。
背景
我是一名自媒体创业者，在创作过程中需要各种AI工具来提升效率。为了满足字幕校准需求，我开发了一个部署在阿里云上的字幕校准工具：https://www.666082.xy z/ （个人玩具，大哥们别拍死我 
）
技术架构：阿里云OSS (静态页面) +函数计算FC (Python后端) +表格存储OTS (Key管 理)
随着用户量增长，我意识到需要对这个公开服务的API进行安全审计和防护优化，但作为非专业开发者，我对云原生安全防护并不 熟悉。
实践过程
任务拆解
使用 的SOLO能力
1. WebSearc h + WebFetch：搜索阿里云FC签名认证文档， 获取官方认证机制说明
2. Browse r工具：直接操作阿里云控制台，创建API分组、修改F C自定义域名认证配 置
3.代码分析能力：分 析压缩后的app.min.js和用户提供的后端Pytho n代码，识别安全 机制
4.文档 生成能力：生成中文 安全审计报告和最终 实 践报告
关键操 作 过程
第一阶段 ：安全审计
SOLO通过curl获取前端页面，发现4个文件：index.html、app.min.js、style.css、QQ码.jpg。关键发现：API Key硬编码在前端，API Base U RL为https://ap i.666082.xyz/v1 ，共识别出12 个 安全漏洞 。
第二阶段： 控制台操作尝试
用户登 录阿里云控制台后，我 尝试了两种方案：
**方案A - API网关代理：**创建了API分组zimu-api (Server less实例)，发现Serverless实例有6 0s超时限制，配置 复杂，尝试后放弃。
**方案B - FC自定义域名认证：**导航到FC 3.0域名管理页面，找到api.666082.xyz自定义域名，尝试修改为签名认证后成功保存 。但发现签名认证需要暴露阿里云 AccessKey到前端， 不适合纯前端场景。最终 决定改回无需 认证。
第三阶 段：后端代 码深度分析
用户提供了完整的Python后端代码，我 进行了详细分析，发现 已有四层安 全防护机制：
1.域名白名单(is_domain_ allowed) - 检查Orig in头
2. IP频率限制(check_ip_r ate_limit) -内存字 典+线程锁
3. API Key验证(verify_api_key) - OTS表 格存储查询
4.每日次数限制(daily_limi t) -按用 户组区 分(20/5 0/100次)
踩过的坑
1. FC 2.0 vs 3.0控制台混乱：导航到域名管理页面时，显示“请在 3.0控制台操作”，但实际URL已是3.0地址 。最后通过函数拓扑图 点击域名节点才进入正确的编辑页面。
2.签名认证不适用前端场景：最 初启用了签名认证，但分析代码后发现需要在前端暴露阿里云Acc essKey，这比 暴露自定义API Key更危险。
3.单行 JS文件解 析：app.min.js是压缩的单行文件(2 7KB)，需 要用 Pytho n 提取关键函数进行分析。
成果展示
1.安全审 计报告：识别出12 个安全漏洞，生成完整的DO CX报告
2.云资源操作：成功创建API分组z imu-api， 尝试并验证了FC自定义域名认证的多种配置
3.安全架 构分析：完整梳理了后 端四层防护机制， 确认现有架构已基 本满足需求
4.最终方案：FC自定 义域名保持“ 无需 认证”，依赖 后端已有防护+账户 余额兜底
效果与总结
1.零成本安全优化：没有 购买任何额外的云安全 产品，仅通过分析已有架构和配置调整就完成了安全评估。
2.关键认知升级：彻底理解了“前端无法隐藏任何秘密” 这个安全铁律，任何认 证方式在纯前端场景下都只是增加攻击门槛，而非绝对防护。
3. AI提效显著：作为非云原生开发者，我无法独立完成这些操作。SOLO的AI Agent能力让我 能够直接操作阿里云控制台UI、阅读和分析后端代码、获取官方文档 并解读。整个过程体现 了“自主工作”和“问 题解决”的 能力。
4.可复用方法论：遇到类似项目 可以复用这个流 程- 静态分析、控 制台操作尝试、后端代码分析、方案对比与选择。
技术说明
本报告由TRAE SOLO的AI Agent全流程生成， 包括：安全分析、控制台操作、代码解读、报告撰写。SOLO能 够自主操作浏览器、控 制台、执行命令，体现了AI编程助手在复杂任务中的实际价值。