Web 安全入门：少写危险代码，多建防御层次

Web 安全不是某个“安全插件”能解决的问题，而是一种开发习惯。很多严重漏洞，根源往往只是几行图省事的代码：拼接 SQL、直接输出用户输入、把权限判断交给前端、把密钥写进仓库。下面用尽量少的代码，讲清 Web 安全的核心思路。

一、先记住四个原则

1. 永不信任客户端：前端校验只是为了体验，后端校验才是安全边界。
2. 最小权限：数据库账号、服务器进程、用户角色，都只给必需权限。
3. 纵深防御：不要依赖单一措施。输入验证、输出编码、CSP、日志监控可以叠加。
4. 默认安全：默认关闭调试、默认拒绝访问、默认使用 HTTPS。

二、常见风险与防线

1. 注入：不要拼接 SQL

SQL 注入、命令注入、NoSQL 注入，本质都是把“数据”当成了“代码”。防御方法很简单：使用参数化查询或 ORM。

cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

不要写成 "SELECT * FROM users WHERE id = " + user_id。命令执行、模板渲染、LDAP 查询也是同理：能参数化就参数化，不能参数化就严格白名单。

2. XSS：输出编码 + CSP

跨站脚本攻击，常发生在把用户输入直接插入 HTML 时。防御重点不是“过滤所有标签”，而是按上下文输出编码，并配合 Content-Security-Policy。

Content-Security-Policy: default-src 'self'; script-src 'self'

这条响应头能显著降低恶意脚本执行概率。同时，富文本场景要用成熟的白名单库，不要自己写正则过滤 HTML。

3. CSRF：SameSite 和 Token

跨站请求伪造，是利用浏览器自动携带 Cookie 的特性。现代浏览器可通过 Cookie 属性缓解：

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax

HttpOnly 让 JavaScript 读不到会话 Cookie，Secure 要求 HTTPS，SameSite=Lax 能挡住多数跨站 POST。对高风险操作，还应加 CSRF Token 或二次验证。

4. 认证与会话

密码必须用 Argon2id、bcrypt 等慢哈希加盐存储，不要用 MD5、SHA1。登录失败要限速，支持多因素认证。会话 ID 要足够随机，登录后重新生成，注销后立即失效。不要把敏感信息放在 JWT 的 payload 里，因为那只是 Base64，不是加密。

5. 访问控制

越权漏洞常比注入更常见。每个接口都要检查：当前用户是谁？他有没有权限操作这个资源？不要只靠前端隐藏按钮，也不要以为“URL 猜不到”就安全。对象 ID 必须和当前用户权限绑定校验。

6. 配置与依赖

使用 HTTPS 和 HSTS；关闭生产环境调试；错误页面不要返回堆栈；删除默认账号和示例页面；定期扫描依赖漏洞。第三方库是供应链的一部分，过期组件就是已知入口。

三、把安全放进开发流程

安全不能只靠上线前扫描。更好的做法是：需求阶段做威胁建模，编码阶段做代码审查，测试阶段用 SAST/DAST，上线后保留日志和监控。日志不要记录密码、Token、身份证号等敏感数据，但要记录关键操作、失败登录和异常访问。

四、结语

Web 安全没有“银弹”。真正有效的，是把“不信任输入、不拼接语句、不省略授权、不泄露错误”变成日常习惯。代码可以少写，防御不能少建。安全不是产品，而是一个持续的过程。