代码中处理数据时如果不加防范，很容易成为漏洞的源头。下面这些事项直击日常开发中的痛点，简单、真实、管用。
- 密钥、口令等敏感信息绝不硬编码
数据库密码、API 密钥、加密盐值等绝不能明文写在代码或配置文件里提交到仓库。应通过环境变量、secret 管理服务或配置中心注入，即使只是内部工具也要遵守。
- 所有外部输入都是“毒药”
用户表单、URL 参数、Header、上传文件、接口返回数据……一律要做校验和净化。
- 数据库查询使用参数化查询或 ORM，严禁拼接 SQL。
- 避免直接使用
eval、exec、system拼接用户输入，防止命令注入。 - 对展示回前端的数据做输出编码，例如 HTML 实体化，防止 XSS。
- 日志和异常不要“泄密”
打印日志时剔除密码、Token、身份证号等；生产环境严禁向用户展示原始异常堆栈，统一使用友好的错误页面，防止暴露框架版本、内部路径等信息。
- 数据在哪儿都得“遮一下”
- 传输必须 HTTPS，内部服务间也可用 mTLS。
- 落地数据库时，敏感字段（如手机号、邮箱）最好加密存储或做不可逆哈希掩码。日志、备份文件同理。
- 需要使用真实数据才能测试？那就用脱敏/合成数据，别把生产库直接拷给开发机。
- 权限最小化，用完即弃
应用连数据库的账号只给 SELECT、INSERT 等必要权限，绝不直接给 root；临时 Token、签名链接设短有效期并限制使用次数。
- 文件上传要严防死守
- 限制文件类型（用白名单，不要信任 Content-Type）、大小。
- 重命名文件，保存到非执行目录，不用用户提供的文件名直接落地。
- 图片/文档可以额外做病毒扫描或降维处理。
- 依赖库也是“内鬼”的可能入口
定期跑 npm audit、pip check、dependency‑check 等工具扫描已知漏洞；不用来源不明的包，锁定版本，稳妥升级。
- 顺手做好 CSRF、CORS 防护
状态改变操作（POST/PUT/DELETE）务必携带 CSRF Token 或采用 SameSite Cookie；跨域配置不要图省事写成 Access‑Control‑Allow‑Origin: *，精确到业务域名。
以上都是写代码时随手就能做到的“小事”，但任何一项的疏忽都可能造成真实的安全事故。安全习惯要融进每一次 commit。