识别 API 设计中的‘尖锐边缘’以规避安全陷阱
通过分析 API、配置模式和接口设计，识别那些容易导致开发者误操作而引发安全漏洞的“陷阱”（Footguns），确保系统的安全使用路径具有最低的阻力。
为什么需要这个技能
在软件设计中，许多安全漏洞并非源于实现 Bug，而是源于 API 设计过于“灵活”，给开发者留下了误用的空间。例如，如果一个加密 API 允许用户自行选择算法，开发者可能会为了方便而选择一个不安全的算法，或者在压力下直接复制粘贴了错误的代码示例。
这种设计缺陷被称为“尖锐边缘”（Sharp Edges）。一个优秀的 API 应该构建一个“成功之坑”（Pit of Success）：即开发者即便不阅读文档、随意调用，其默认行为也应该是安全的。
适用场景
- 评审 API 或类库设计：检查接口是否强制要求安全实践。
- 审计配置模式：评估配置文件中的选项是否允许危险的组合。
- 评估加密库易用性：检查是否将原始字节（Primitives）直接暴露给用户，而非语义化类型。
- 鉴权接口审查：分析认证/授权流程中是否存在可被绕过的默认值。
核心工作流
1. 识别潜在风险点
重点审查涉及认证、授权、加密、会话管理和输入验证的接口。找出所有允许开发者进行“选择”的地方（如算法选择、超时设置、模式切换）。
2. 边缘 case 探测
针对每个选择点，模拟以下极端输入：
- 零值/空值：输入
0、""、null或空数组时，安全检查是否被跳过？ - 负值：
-1是否被误认为“永久有效”或“禁用限制”？ - 类型混淆：两个同为
string或bytes的参数（如 Nonce 和 Key）互换位置是否会导致静默失败？
3. 威胁建模分析
从三类角色视角审视：
- 恶意攻击者：能否通过修改配置直接关闭安全校验？
- 懒惰开发者：直接复制第一个 Demo 运行，结果是否安全？
- 困惑开发者：在不看文档的情况下，能否通过参数误用触发漏洞？
4. 拒绝常见辩解
在评审过程中，应拒绝以下理由：
- “文档里写了”
开发者在压力下不会读文档。 - “高级用户需要灵活性”
灵活性即陷阱，应提供高层安全 API 并隐藏底层原语。 - “这是开发者的责任”
允许误用本身就是设计失败。
下载和安装
解压后将目录放入你的 AI 工具 skills 文件夹，重启工具后即可使用。具体路径参考内附的 USAGE.zh.md。
你可能还需要
暂无推荐