去年某电商平台被拖库，何预起因不是防信黑客多高明，而是息安一个后端接口忘了做权限校验。攻击者用普通用户账号就能直接读取其他用户的全漏订单信息，连SQL注入都不用。产生这种事我见过太多次了——漏洞往往不是何预"攻破"的，是防信"留着门"的。

写代码的息安人总觉得安全是安全团队的事。现实是全漏，安全团队不可能逐行审查每一行提交。产生真正决定系统安全水位线的何预，是防信每天写代码的那个人有没有把校验写全、把参数过滤干净、息安把错误信息收敛好。全漏下面聊几个实际能落地的产生做法，不讲大道理。

输入校验不是可选项

任何来自外部的数据都不可信。表单字段、URL参数、HTTP头、Cookie，甚至你调用的第三方API返回的内容——都可能被篡改。我见过一个案例，某系统对用户ID做了数字校验，但忘了校验排序字段，结果攻击者通过构造恶意的排序参数，把整个用户表导了出来。

校验要遵循白名单原则：明确允许什么，而不是试图枚举禁止什么。正则表达式写严一点，类型检查做足，长度限制加上。别嫌麻烦，这些代码加起来不超过二十行，但能挡掉八成以上的常见攻击。

权限校验放在该放的地方

很多漏洞出在"以为前端做了校验"。前端校验是给正常用户用的，攻击者直接调接口，根本不走你的页面。每个涉及数据读写的接口，都必须在服务端独立完成权限判断。

具体做法：把权限校验抽成中间件或拦截器，别散落在业务逻辑里。散着写迟早会漏。另外，校验粒度要细到"这个用户能不能操作这条记录"，而不只是"这个用户有没有登录"。水平越权比垂直越权更常见，也更难发现。

依赖库别拿来就用

npm install 一条命令拉进来几十个包，你知道每个包里有什么吗？2022年 colors.js 和 faker.js 的作者故意搞破坏，把库改成了无限循环，几千个项目直接崩了。供应链攻击不是理论风险，是已经发生过很多次的事实。

锁定依赖版本，用 lock 文件。定期跑 npm audit 或 pip audit，但别盲目升级——先看 changelog，确认没有破坏性变更。内部项目可以考虑搭建私有镜像源，对引入的包做一层审核。麻烦是麻烦，总比出事强。

日志和错误信息要收敛

生产环境的报错页面别把堆栈信息直接吐给用户。数据库连接字符串、文件路径、框架版本号——这些信息对攻击者来说就是地图。自定义统一的错误页面，详细日志写到服务端，只给用户一个模糊的提示和一个追踪ID。

日志本身也要注意脱敏。手机号、身份证号、密码字段，写日志前必须处理。我见过把用户密码明文打进日志的系统，运维人员随手一查就能看到，这跟没做安全有什么区别。

代码审查盯住安全点

Code Review 别只看业务逻辑对不对。专门留个心眼：这个接口有没有做鉴权？这个参数有没有过滤？这个SQL是不是拼接的？团队可以整理一份安全检查清单，每次提交对照着过一遍。不用多复杂，十几条就够。

安全漏洞不可能完全消灭，但大部分低级漏洞是可以避免的。关键是把安全意识嵌进日常开发流程里，而不是等出了事再补救。写代码的时候多想一步，比事后熬夜修漏洞划算得多。