Appearance
Security Hardening 解决的是 AI 写完功能后忽略安全边界的问题。凡是涉及用户输入、登录权限、敏感数据、文件上传、数据库查询或外部服务，都要按安全约束检查，而不是只看页面能不能跑。
AI 写代码怎么做安全检查：Security Hardening 怎么用
下载 security-and-hardening 中文版 Skill ZIP
AI 写登录接口和文件上传都很快。
如果它顺手把用户输入拼进查询里，功能也许能跑，风险也已经埋下了。
安全事故不会等到你有空再处理。
security-and-hardening 这个技能提醒我们：只要代码碰到外部输入、用户身份、权限、敏感数据，就不能只按功能验收。
哪些任务必须做安全检查
看到这些关键词，就要提高警惕：
- 登录、注册、会话、密码。
- 权限、角色、组织、成员。
- 用户输入、表单、富文本。
- 数据库查询。
- 文件上传、下载、路径处理。
- Webhook、回调、第三方 API。
- 支付、联系方式、个人信息。
这些不是普通功能点，而是系统边界。
AI 可以帮你写代码，但你要让它知道：这里不能只追求“能用”。
输入边界：外部数据都要验证
浏览器传来的数据不可信。
第三方 API 回来的数据也不该盲信。
CSV、JSON、Webhook、上传文件，都是外部输入。
安全检查的第一步是问：这个数据从哪里来？进入系统时有没有校验？
比如 API route 里要验证 body，文件上传要限制类型和大小，URL 参数要做格式检查。前端表单校验只能改善体验，不能当安全边界。
给 AI 的要求可以写成：
md
这个接口接收外部输入。
请在服务端边界做 schema 校验。
不要只依赖前端校验。
错误信息要对用户友好，但不要泄露内部细节。权限：登录不等于有权操作
很多权限 bug 来自一个误解：用户登录了，就能操作资源。
这不够。
用户 A 登录后，不能修改用户 B 的订单。普通成员不能调用管理员接口。团队成员也不一定能删除整个团队。
审 AI 代码时，要特别看这些点：
- 是否只检查了登录，没有检查资源归属。
- 是否把角色判断放在前端。
- 是否相信客户端传来的 userId、role、teamId。
- 是否在列表查询和详情查询里都做了权限过滤。
权限必须在服务端关键路径上检查。
敏感数据：不要写进代码、日志和前端
AI 有时会为了方便，把 token、API Key、测试密码直接写进示例。
这在真实项目里很危险。
安全检查时要看：
- 是否有硬编码密钥。
- 是否把完整 token 打到日志。
- 是否把 passwordHash、resetToken 返回给前端。
- 是否把会话 token 存在 localStorage。
- 错误响应是否暴露堆栈或内部配置。
敏感数据的规则很简单：少存、少传、少显示、少记录。
SQL、命令和路径不要拼字符串
只要外部输入进入 SQL、shell command、文件路径，就要特别小心。
数据库查询优先用参数化查询或 ORM 的安全 API。
文件路径要限制在允许目录下，不能让用户传 ../ 去访问任意文件。
命令执行要避免把用户输入拼进 shell 字符串。能用参数数组，就不要拼命令文本。
这类问题 AI 很容易为了省事写出危险版本，所以 review 时要盯住。
安全检查不是让 AI 过度设计
安全加固不等于什么都加。
一个本地脚本和一个公网登录接口，风险不一样。个人博客的静态页面和多租户后台，风险也不一样。
你要做的是在边界处加必要约束，而不是给每个函数都套一层防御。
古法编程讲“决策在人”。安全也是一样：AI 可以列风险，你来决定哪些必须修，哪些记录后续处理。
给 AI 的安全检查 Prompt
md
请按安全角度审查这次改动。
重点看：
1. 外部输入是否在服务端边界校验。
2. 数据库、命令、文件路径是否存在注入风险。
3. 登录和权限是否分开检查。
4. 敏感数据是否被写进代码、日志或前端响应。
5. 外部 API、Webhook、文件上传是否有限制和错误处理。
只列真实风险，不要泛泛而谈。
把问题分成必须修和可后续。这比“帮我看看安全问题”更容易得到有用结果。
你可能还需要
同类技能：
如果一个功能碰到用户输入、登录、权限或敏感数据，安全检查应该在合并前完成。