去年有个做跨境电商的网站朋友，网站被注入了恶意脚本，安全用户一打开商品页就跳转到博彩网站。管理三天后他发现时，办法Google已经给域名标了“危险”警告，网站流量直接腰斩。安全他没做错什么大事，管理只是办法后台登录密码用了“admin123”，而且半年没改过。网站这事让我意识到，安全网站安全不是管理买套WAF就万事大吉，它更像每天出门前检查门窗有没有锁好——琐碎，办法但漏一次就可能出大事。网站

很多团队把安全当成上线前的安全检查项，过了就扔一边。管理可现实是，攻击者从不休假。我的做法是：把安全拆成三块——入口、内容、出口。入口管谁能进来，内容管数据怎么存，出口管用户看到什么。每一块都得有具体的动作，而不是一句“注意安全”。

入口：别让门锁形同虚设

后台登录是最常被撞的门。我见过一个教育平台，登录接口没做频率限制，攻击者用脚本每秒试200个密码，两小时就撞开了管理员账号。解决办法不复杂：加验证码、限制IP尝试次数、强制密码复杂度。但关键是——这些措施要真的启用。有些开发者写了限制逻辑，却把阈值设成1000次，等于没设。

另一个入口是文件上传。用户上传头像，你只检查后缀名？那攻击者把.php改成.jpg再上传，服务器一解析就执行了。我的习惯是：上传目录禁止执行任何脚本，文件名重命名成随机字符串，再用白名单校验MIME类型。这三步做完，基本堵死大部分上传漏洞。

内容：数据存进去之前先“消毒”

SQL注入和XSS至今还在OWASP前十，说明很多人没当回事。有个细节：参数化查询能防注入，但如果你拼接表名或列名，照样中招。比如“ORDER BY $column”这种写法，攻击者传个“id; DROP TABLE users”就完了。表名列名必须用白名单映射，不能直接拼。

XSS更隐蔽。用户评论里写“<script>alert(1)</script>”，你直接存进数据库再输出到页面，脚本就跑了。输出时转义是基本操作，但别忘了富文本场景——允许部分HTML标签时，得用专门的库过滤，自己写正则很容易漏。我一般推荐DOMPurify，省心。

出口：让用户看到的东西是干净的

HTTPS现在几乎是标配，但配置有讲究。TLS 1.0和1.1该关了，证书链要完整，HSTS头加上。有个客户网站用了HTTPS，但混合加载了HTTP的图片，浏览器照样提示“不安全”。检查方法很简单：打开开发者工具，看Console有没有混合内容警告。

还有响应头。Content-Security-Policy能限制页面能加载哪些外部资源，X-Content-Type-Options: nosniff防止MIME嗅探。这些头不加不会立刻出事，但加了能挡掉一批自动化扫描器。我的经验是：先上CSP的Report-Only模式，观察一周再切正式模式，避免误杀正常功能。

最后说个容易被忽略的点：日志。很多网站被入侵了却不知道从哪进来的，因为没留访问日志或日志只存三天。我建议至少保留30天，并且把登录失败、文件上传、数据库错误这几类事件单独记录。真出事时，这些日志就是破案线索。

安全没有终点，只有持续修补。每次上线新功能，花十分钟想想：这个输入能被伪造吗？这个输出会执行吗？这个权限给大了吗？三个问题问完，能避开八成坑。剩下的两成，靠定期扫描和及时打补丁。别等被黑了才后悔——那时候流量和信任都已经丢了。