在编写接受用户输入、认证、数据存储或外部集成的代码时…

面向 Web 应用的安全优先开发实践：先做威胁建模，再按 Always/Ask First/Never 三层规则与各类加固控制编写代码，最后用清单验证。

适用场景

解决思路

1. 先做五分钟威胁建模：1) 画出信任边界——HTTP 请求、表单字段、文件上传、webhook、第三方 API、消息队列、LLM 输出，以及看似内部的本地值（其他进程的命令行或环境变量、共享卷上的文件名、job payload 中的路径）；信任取决于谁写了这个值，而不是哪个通道传递的。2) 列出值得窃取或破坏的资产：凭据、PII、支付数据、管理员操作、资金流动。3) 对每个边界跑 STRIDE：Spoofing 用认证与签名验证；Tampering 用完整性校验、参数化查询、HTTPS；Repudiation 用安全事件审计日志；Information disclosure 用加密、字段白名单、通用错误；Denial of service 用限流、输入大小上限、超时；Elevation of privilege 用授权检查、最小权限。4) 在每个用例旁写滥用用例，并把它作为第一个测试。
2. Always Do（无例外）：在系统边界（API 路由、表单处理器）校验所有外部输入；所有数据库查询参数化，绝不把用户输入拼进 SQL；输出编码防 XSS（用框架自动转义，不要绕过）；所有外部通信走 HTTPS；用 bcrypt/scrypt/argon2 哈希密码，绝不存明文；设置安全响应头（CSP、HSTS、X-Frame-Options、X-Content-Type-Options）；会话 cookie 使用 httpOnly、secure、sameSite；每次发布前用检测到的包管理器对已提交的 lockfile 跑原生 audit。
3. Ask First（需人工批准）：新增认证流程或修改认证逻辑；存储新类别的敏感数据（PII、支付信息）；新增外部服务集成；修改 CORS 配置；新增文件上传处理器；修改限流或节流；授予提权权限或角色。
4. Never Do：绝不把密钥提交到版本控制（API key、密码、token）；绝不记录敏感数据（密码、token、完整信用卡号）；绝不把客户端校验当作安全边界；绝不为了方便禁用安全响应头；绝不对用户提供的数据使用 eval() 或 innerHTML；绝不把会话存在客户端可访问的存储中（如用 localStorage 存认证 token）；绝不向用户暴露堆栈跟踪或内部错误细节。
5. 注入、XSS 与访问控制：每个查询都参数化，绝不用输入字符串构建 SQL、NoSQL 或 shell 命令；通过框架自动转义做输出编码，无法避免原始 HTML 时先用白名单 sanitizer 清洗；每个请求都检查授权而不只是认证——已认证用户必须拥有或被允许访问该具体资源（A01、IDOR）。
6. 认证与会话：用 bcrypt（≥12 轮）、scrypt 或 argon2 哈希密码；会话密钥来自环境变量而非代码；会话 cookie 设为 httpOnly、secure、sameSite: 'lax' 或 'strict'（CSRF 防御，'none' 会在跨站请求发送 cookie），并设置有限的 maxAge。
7. 响应头、CORS 与响应：每个响应都带安全头（helmet 或框架等价物）；CSP 从 default-src 'self' 起步并逐步收紧而非放松；CORS 限制为配置中的显式 origin 列表，带凭据时绝不用 *；响应前剥离敏感字段（passwordHash、重置 token）；错误体保持通用，内部信息只进服务端日志。
8. 输入校验与上传：在边界用 schema 校验——白名单形状、长度、枚举、格式；以 422 加结构化详情拒绝，下游代码只用解析后的类型化值；上传时白名单 MIME 类型、限制大小、必要时校验内容（magic bytes），扩展名不能证明任何事。
9. 服务端请求（SSRF）：任何用户可影响的 URL（webhook、从 URL 导入、图片代理、链接预览）都可能指向内部服务；白名单 scheme 和 host，解析所有 DNS 记录并拒绝任何私有或保留地址（loopback、link-local 169.254.169.254、private、unique-local，IPv4 和 IPv6 都要），并禁止重定向；该检查仍有 DNS rebinding 的 TOCTOU 缺口，高风险场景要固定解析后的 IP 或前置过滤代理。
10. 派生路径上的破坏性操作：delete、move、overwrite 的安全性取决于命名目标的值，信任取决于谁写了这个值而非哪个通道传递；形状检查只证明格式合法，不证明授权。执行前必须同时满足三条：解析后的目标（解析符号链接）位于白名单根目录下；至少在该根目录下一层；带有在操作前读取的所有权证据。拒绝时记录被拒目标并停止，绝不回退到更宽泛的默认路径。
11. 限流：对 API 做一般限流，对认证端点严格限流（约每 15 分钟 10 次尝试）；一旦有多个进程服务流量，内存计数器会静默变成 max × instances，或在 serverless 上永不触发，因此限流器要用共享存储支撑。
12. 密钥：密钥来自环境变量；提交带占位符的 .env.example；真实 .env* 文件和密钥材料加入 gitignore；提交前 grep 暂存的 diff。密钥一旦到达远端即视为已泄露：先轮换，再清理历史。
13. 依赖与供应链：1) 找到安装边界和管理器——用拥有 lockfile 的工作区根目录，或仅当独立嵌套项目在该工作区之外时使用它；用 packageManager（若存在）、lockfile 和 CI 相互印证，出现分歧或竞争 lockfile 就停止；固定管理器版本。2) 在首次执行前阻止依赖脚本——以禁用脚本或文档化的 fail-closed 策略引导，检查待执行脚本源码，只批准最小必要项，提交策略，然后用干净的 frozen/immutable 安装验证；绝不 blanket-approve。3) 每次发布前对已提交的 lockfile 跑原生 audit；按可达性（运行时、构建、测试、部署路径）和修复可用性分诊 critical/high；绝不自动应用强制修复（npm audit fix --force 或等价物），因为强制修复可能跨越声明的依赖范围；先预览、读 changelog、逐个升级测试；每个延期都记录原因和复审日期。4) audit 只匹配已知公告，抓不到新出现的恶意或仿冒包（cross-env vs crossenv）；把新依赖、lockfile diff 和脚本策略变更放在一起审查：所有权、维护情况、发布年龄、来源、传递依赖图；在支持时验证 registry 签名（npm audit signatures、pnpm audit signatures），把签名缺失当作需要调查的信号而非自动证明被入侵（A06、LLM03）。
14. 个人数据与隐私：加固问“攻击者能读到吗”，隐私问“我们到底该不该持有、持有多久”；最便宜保护、防泄露和合规的数据是从未收集的数据，把个人数据当作要最小化的负债。添加字段时就分类（非个人、PII、敏感）并分别处理——找不到的数据就无法保护或响应删除请求；只按声明的目的收集，“以后可能有用”是潜在泄露范围而非目的，PII 不要进遥测；预先设定保留期并真正删除，每个个人数据存储都需要 TTL 和可用的删除路径，包括备份、缓存、搜索索引和分析副本；支持所在司法辖区要求的数据主体权利（GDPR、CCPA 等）：导出、更正、删除，设计 schema 时让用户数据可查找、可擦除，而不是不可逆地散落各系统；同意是收集和第三方共享的前提且可审计，把 PII 发给分析、广告或 LLM 供应商属于共享，供应商需要数据处理协议；把地区做成可配置策略而非硬编码假设。隐私事件会启动泄露通知时钟，事后复盘用 debugging-and-error-recovery 技能。
15. AI/LLM 功能：调用 LLM（聊天机器人、摘要器、agent、RAG）会新增攻击面，映射到 OWASP Top 10 for LLM Applications (2025)：模型输出是不可信输入（LLM05），绝不进入 eval、SQL、shell、innerHTML 或文件路径，先防御性解析、按 schema 校验、再编码；提示可被劫持（LLM01），上下文中的不可信文本（用户消息、抓取的页面、PDF）可能携带指令，系统提示不是安全边界，权限要在代码中强制；把密钥、其他租户数据和完整系统提示排除在上下文窗口之外（LLM02、LLM07）；限定工具权限、校验每个工具参数、确认破坏性操作（LLM06）；限制 token、请求速率和递归深度（LLM10）；按租户分区 RAG embedding 并在索引前校验文档（LLM08）。
16. 签核前走一遍 references/security-checklist.md：覆盖认证、授权、输入、数据保护与隐私、响应头与 CORS、依赖与供应链、AI/LLM、错误处理，以及 OWASP 速查表。
17. 用常见合理化对照表自检：内部工具也要安全；安全要现在加而非以后；自动化扫描器会找到漏洞；框架只提供工具不提供保证；原型会变生产；五分钟威胁建模能防住任何控制都补不了的设计缺陷；LLM 输出可能是一条 SQL、script 标签或 shell 命令；audit 通过不代表依赖安全；以后可能需要不是收集理由；手动删除会漏掉备份缓存和分析副本；合规是 schema 和代码问题不只是法务问题。
18. 对照红旗清单排查：用户输入直接进数据库查询、shell 命令或 HTML 渲染；delete/move/overwrite 的目标来自 payload、配置值或其他进程命令行且只有路径形状检查；源码或提交历史中有密钥；API 端点缺少认证或授权检查；缺少 CORS 配置或通配符 origin；认证端点无限流，或多实例前用内存限流器；向用户暴露堆栈跟踪或内部错误；依赖有已知 critical 漏洞、同一安装边界有竞争 lockfile、安装不可复现或 blanket-approved 脚本；服务端抓取用户提供的 URL 而无白名单（SSRF）；LLM/模型输出进入查询、DOM、shell 或 eval；密钥、PII 或完整系统提示放进 LLM 上下文窗口；收集个人数据无声明目的、保留限制或删除路径；PII 发给分析/广告/LLM 供应商而无同意或数据处理协议；“删除我的账户”只翻标志位而个人数据仍留在各存储和备份中。
19. 实现安全相关代码后逐项验证：原生 audit 没有未缓解的可达 critical/high 发现，CI 保留权威 lockfile 并阻止未审查的依赖脚本；源码和 git 历史中无密钥；所有用户输入在系统边界校验；破坏性文件系统操作先解析符号链接，再验证白名单根、最小深度和所有权后才执行；每个受保护端点都检查认证和授权；响应中存在安全头（用浏览器 DevTools 检查）；错误响应不暴露内部细节；认证端点限流生效，多实例时用共享存储支撑；服务端 URL 抓取经白名单校验（无 SSRF）；LLM/模型输出使用前经校验和编码（若有 AI 功能）；个人数据已分类、按声明目的最小化并有保留限制；删除和导出请求端到端可用（包括备份、缓存和分析副本）。

适用边界 · 注意事项

• 纯本地、不接触任何用户输入、认证、敏感数据或外部系统的代码，无需按此流程加固
• 尚未确定信任边界的功能不应开始加固——先补威胁建模，否则控制只是猜测
• 需要人工批准的变更（新增认证流程、新类别敏感数据、新外部集成、CORS 变更、文件上传、限流调整、提权）不能自行实施，须先获得批准