上线前别急着庆祝，先过一遍这道关
项目终于开发完了，测试也跑通了，产品组已经在准备上线发布会的文案。可这时候你心里得清楚：系统一上线，就等于把家门钥匙交给了全世界。有没有漏关的窗？有没有没锁的门？这些都得在发布前查清楚。
身份认证与权限控制不能马虎
最常见的漏洞之一就是权限绕过。比如普通用户访问管理员接口，只需要改一下 URL 里的 ID 就能查看别人的数据。这种问题在赶进度时最容易被忽略。
检查每一个 API 接口，确认是否做了身份校验和权限判断。尤其是涉及用户敏感信息的操作，比如修改密码、删除账户、导出数据，必须二次验证身份。
输入验证是第一道防线
用户输入不可信，这是铁律。无论是表单提交、URL 参数还是文件上传，都可能成为攻击入口。
SQL 注入、XSS 跨站脚本、命令执行，这些经典攻击方式大多源于对输入内容的放任。后端要对所有输入做过滤或转义，前端的验证只是用户体验优化，不能当真。
<?php
// 示例：对用户输入进行基本过滤
$username = htmlspecialchars($_POST["username"]);
$email = filter_var($_POST["email"], FILTER_SANITIZE_EMAIL);
?>敏感信息别留在代码里
开发时为了方便，把数据库密码、API 密钥直接写在配置文件甚至代码中，等上线才发现忘了删。这种情况每年都有公司因此被拖库。
上线前务必检查所有配置文件，确保敏感信息通过环境变量或密钥管理服务注入。版本控制系统里也不该出现任何密钥痕迹，.gitignore 要配好。
HTTPS 和安全头一个都不能少
即使功能没问题，传输过程不加密也是白搭。确保生产环境强制启用 HTTPS，HTTP 请求自动跳转。
同时加上必要的安全响应头，比如防止点击劫持的 X-Frame-Options，防御 XSS 的 X-XSS-Protection，还有内容安全策略 CSP。
# Nginx 配置示例
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
add_header Content-Security-Policy "default-src 'self';";第三方组件也要查风险
项目用了多少 npm 包、Maven 依赖、Python 库？这些外部代码同样可能带漏洞。别以为“别人写的”就安全。
用工具扫描依赖项，比如 npm audit、OWASP Dependency-Check，发现已知漏洞及时升级。有些老版本的库连维护都没有了，就得考虑替换成更可靠的方案。
日志和监控不是上线后再补
系统出问题时，没有日志就像黑夜里找开关。登录失败、权限拒绝、异常请求这些关键行为必须记录。
但也要注意别记录敏感信息，比如用户密码、身份证号。日志本身泄露出去也是一场灾难。提前配置好日志收集和告警规则，有问题能第一时间发现。
压力测试顺便揪出隐藏问题
性能测试不只是看扛不扛得住流量，高并发下往往暴露出平时看不到的安全隐患。比如缓存击穿导致数据库暴露，或者会话机制在负载均衡下失效。
模拟真实场景压测一遍，既能验证稳定性，也能顺手排查逻辑缺陷。有时候一个接口在万人同时请求时，竟然能返回其他用户的订单数据。