Web安全：每一行代码都是一道门

互联网上，每个输入框都是一扇门。用户从门外递进来名字、密码、搜索词、图片、链接，而Web安全要做的，就是确保这扇门只对该开的人开，只放该进的东西进。攻击者并不关心你的业务逻辑有多优雅，他们只关心哪里没锁：一个拼接的SQL语句、一个未转义的评论、一个缺少校验的重定向、一个过期未更新的依赖库。

Web安全不是某个框架的插件，也不是上线前的一次扫描。它是一种贯穿设计、编码、部署和运维的习惯。它的第一原则很简单：永不信任用户输入。所有来自外部的数据——URL参数、请求头、Cookie、表单、文件、API返回值——都必须经过验证、编码或参数化处理。

先看一个最经典的错误：把用户输入直接拼进SQL。

# 危险：字符串拼接
query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)

如果 email 是 ' OR '1'='1，查询就会变成另一句话。正确的做法是参数化查询，让数据库把输入当作数据，而不是代

# 安全：参数化查询
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

同样的思路适用于XSS。当你要把用户输入放进HTML时，必须进行输出编码。否则，一段 <script> 就能在别人的浏览器里执行。

from markupsafe import escape

# 安全：输出编码
return f"<div>{escape(user_input)}</div>"

除了注入和XSS，Web安全还要面对CSRF、认证缺陷、敏感数据泄露、SSRF、反序列化漏洞、依赖链攻击等。防御它们没有单一银弹，而是层层设防：使用HTTPS、设置HttpOnly和SameSite Cookie、启用CSP、限制请求方法、校验Origin、实施最小权限、记录关键操作、定期更新依赖、做安全测试。

一个简单的安全响应头，就能挡住不少低级攻击：

resp.headers["Content-Security-Policy"] = "default-src 'self'"
resp.headers["X-Content-Type-Options"] = "nosniff"

但代码只是最后一道防线。真正的安全左移，是在需求评审时就问：这个接口需要认证吗？这个字段能暴露吗？这个文件上传会存到哪里？这个错误信息会不会泄露堆栈？这个第三方库还在维护吗？

Web安全没有终点。今天安全的系统，明天可能因为一个新CVE而变得脆弱。所以，安全不是一次冲刺，而是一种持续的习惯：小步提交、自动扫描、及时修补、假设会被攻破、并准备好被攻破后的响应。

每一行代码都是一道门。你不需要把门焊死，但你必须知道谁有钥匙，以及门后放着什么。