安全AndHardening

你正在踩的那些坑

很多团队在开发 Web 应用时，把安全当成上线前的“补漏环节”，结果就是：默认信任前端传来的参数，直到用户提交 '; DROP TABLE users;-- 才意识到问题；授权检查写成了“有 token 就能访问”，忽略了角色边界，导致普通用户能调用管理员接口；密钥直接写在代码里，直到仓库公开才被发现；文件上传没限制类型，用户上传一个伪装成图片的脚本就拿下服务器。

这些都不是“黑客太厉害”，而是安全约束没有前置到每一行处理用户数据、认证授权或外部系统的代码里。

它如何帮你把安全变成约束

这个技能不会让你买一堆安全工具，而是先改变你的思考顺序：在动手加固之前，先用五分钟做威胁建模。

• 画出信任边界：找出所有不受信数据进入系统的入口——HTTP 请求、表单字段、文件上传、Webhook、第三方 API、消息队列，甚至 LLM 输出。每个边界都是潜在的攻击面。
• 列出资产清单：明确哪些东西值得被窃取或破坏，比如凭证、个人身份信息（PII）、支付数据、管理操作权限、资金流转记录。
• 用 STRIDE 快速过一遍：对每个边界，从 spoofing（仿冒）、tampering（篡改）、repudiation（抵赖）、information disclosure（信息泄露）、denial of service（拒绝服务）、elevation of privilege（权限提升）六个角度问一句“可能发生什么”，并找到对应的缓解措施。

接下来才是具体的加固实践：把每一个外部输入都当作敌意输入来校验，用参数化查询或 ORM 避免 SQL 注入，为每个操作做最小权限的授权检查，用环境变量或密钥管理服务替代硬编码密钥，对敏感数据加密存储和传输，给文件上传加类型、大小和内容校验，处理支付和 PII 时遵循数据合规要求。

适用边界与注意点

它适用于任何接受用户输入、实现认证授权、存储或传输敏感数据、集成外部 API、添加文件上传或 Webhook、处理支付或 PII 的场景。但它不能替代专业的安全审计、渗透测试或合规认证——它提供的是开发阶段的安全思维和基础实践，不是万无一失的保险。