必须牢记的7个后端安全漏洞：从SQL注入到SSRF，附OWASP速查表

API能运行并不意味着安全。据TechtoTech主页的一组幻灯片，有7个漏洞是每个后端工程师都必须了解的——从SQL注入到SSRF——只要漏掉一层检查，整个系统就可能泄露。每个漏洞都附有错误代码、正确代码及其在OWASP列表中的位置。本文总结这7个漏洞的本质、常见位置和防御方法，帮助你自信地审查代码和参加面试。

快速回答：据TechtoTech的幻灯片，必须牢记的7个后端安全漏洞是：SQL注入（用参数化查询阻止）、身份验证失效（安全会话、多因素认证）、IDOR/BOLA（对每个对象检查所有权）、SSRF（限制目标、阻止出站连接）、批量赋值（独立DTO、允许字段列表）、不安全的反序列化（固定类型、验证数据）和敏感数据暴露（加密、遮盖密钥、仅返回最少数据）。这7个漏洞都出现在OWASP Top 10和OWASP API Security Top 10中，其中访问控制失效位居两个列表之首——授权检查是首先要做的事情。

OWASP Top 10是OWASP组织发布的Web应用十大最严重安全风险列表，OWASP API Security Top 10是面向API的同类列表。后端是处理界面背后的逻辑、数据和授权的服务器端——漏掉一层检查就可能导致整个系统泄露。

1. SQL注入——用户数据变成了SQL语法

用户输入的数据被直接拼接到SQL语句中，成为语法的一部分。一条不安全的查询就足以泄露整个数据库。错误代码是字符串拼接："SELECT ... WHERE email = '" + email + "'"。正确代码使用PreparedStatement："SELECT ... WHERE email = ?"并配合st.setString(1, email)。

该漏洞常见于登录表单、搜索和数据筛选。在电子邮件字段中输入' OR 1=1 --就足以使WHERE条件恒为真。防御方法：使用参数化查询使数据与命令分离；绝不从字符串拼接动态SQL；动态列名和表名使用允许列表。仅验证输入数据是不够的。

2. 身份验证失效——安全的登录只是一半

安全的登录只是一半。会话薄弱、令牌泄露或不阻止密码猜测都会让攻击者冒充用户。会话Cookie必须正确设置：Set-Cookie: HttpOnly; Secure; SameSite=Lax——HttpOnly使JavaScript无法读取Cookie，Secure使其仅通过HTTPS发送。

常见的失效模式：不阻止撞库（尝试批量泄露的用户名和密码）、会话长期有效且无法撤销、令牌泄露或存储不安全。防御方法：多因素认证、限制登录尝试次数、登录后签发新会话，以及可撤销的会话。要分清：身份验证回答“你是谁”；授权回答“你被允许做什么”。

3. IDOR/BOLA——改动URL中的一个数字就能查看他人的数据

只需改动URL中的一个数字就能查看他人的数据：API找到了正确的记录，却不检查调用者是否有权访问它。例如，GET /orders/{id}必须检查权限，并在调用者无权时抛出AccessDeniedException。

该漏洞出现在查看他人订单、私人文档或属于其他账户的数据时。防御方法：对资源的每次操作都检查权限，按所有权、角色和共享规则检查；通过切换到其他账户进行测试。使用难以猜测的UUID不能替代授权检查——难以猜测的ID仍可能泄露或被猜到。

4. SSRF——服务器被借用来刺探内网

SSRF（服务器端请求伪造）发生在服务器获取用户提供的任意URL时，包括内部地址。攻击者借用服务器来刺探内部网络：用户向后端API发送URL，API又调用内部网络。

它常见于链接预览生成、从URL导入数据、Webhook测试和从链接获取图像。防御方法：仅允许受信任的目标列表，在DNS解析后验证地址，检查每个重定向步骤，并在网络层通过出站控制进行阻止。仅检查URL字符串是不够的，因为DNS和重定向可能改变真实目标。

5. 批量赋值——API自动赋值用户无权修改的字段

批量赋值发生在API将请求中的每个字段自动赋值到内部对象时，包括用户无权修改的字段——例如角色。恶意请求如{"name": "Asha", "role": "admin"}如果API直接绑定到实体，就可能提升权限。正确做法：使用仅接受允许字段的DTO，角色保持为"user"。

它常见于用户资料更新和账户设置。防御方法：每个请求使用独立的DTO、允许编辑的字段列表、仅管理员可改的属性，并且绝不将请求直接绑定到实体。验证和授权都需要：有效的值仍可能是此人不被允许设置的值。

6. 不安全的反序列化——不受信任的数据决定创建哪个对象

不安全的反序列化发生在不受信任的数据决定创建哪个对象时。根据技术的不同，后果可能是未经授权的状态更改，甚至代码执行。错误代码是对外部数据使用ObjectInputStream的readObject()；正确代码是读入固定的DTO然后验证，例如读入UserDto并调用validate(u)。

它出现在接收已序列化的Java对象、对外部数据使用ObjectInputStream，或JSON通过@type字段启用多态类型的地方。防御方法：绝不对外部数据进行原生反序列化；如果必须，则设置ObjectInputFilter；读入固定DTO，不开放多态；并在读取后验证数据。JSON本身并不危险——风险在于多态类型的配置方式。

7. 敏感数据暴露——日志绝不能成为数据泄露事件

私人信息、密码和令牌可能通过日志、响应、存储或传输泄露。错误示例：记录Authorization: Bearer <real-token>和电子邮件地址。正确做法：在日志中遮盖密钥（Authorization: [REDACTED]）并仅返回所需内容。

它发生在将令牌和密码写入日志、响应返回过多的个人数据，或未加密发送敏感数据时。防御方法：传输和存储时加密，在日志中遮盖密钥，仅返回必要的字段，并限制数据访问权限。仅靠加密无法阻止通过日志或响应的过度暴露。

7个漏洞在OWASP列表中的位置？

据幻灯片，7个漏洞都出现在两个最流行的安全列表中：面向Web的OWASP Top 10和OWASP API Security Top 10。幻灯片中的对应关系如下：

漏洞	幻灯片中的位置
IDOR / BOLA	API1 — 对象级授权失效；A01 访问控制失效
身份验证失效	API2 — 身份验证失效；A07 身份验证失效
批量赋值	API3 — 对象属性级授权
SQL注入	A05 注入
SSRF	A01 访问控制失效（包括SSRF）；SSRF也有独立条目
敏感数据暴露	A04 加密失效
不安全的反序列化	A08 软件和数据完整性失效

幻灯片的关键点：授权失效位居两个列表之首——授权检查是首先要做的事情。

速查表：7个漏洞，7种防御

最后一张幻灯片是用于检查自己项目的速查表：

#	漏洞	防御
1	SQL注入	参数化查询
2	身份验证失效	安全会话、多因素认证
3	IDOR / BOLA	对每个对象授权
4	SSRF	限制目标、阻止出站连接
5	批量赋值	DTO、允许字段列表
6	反序列化	固定类型、验证数据
7	数据暴露	加密、遮盖密钥、返回最少数据

幻灯片的结语：认识弱点，懂得防御——安全不是一项功能，而是后端职业的一部分。

常见问题

1. 据OWASP，哪个后端漏洞最危险？ 据幻灯片，访问控制失效（包括IDOR/BOLA）位居OWASP Top 10和OWASP API Security Top 10之首——授权检查是首先要做的事情。

2. 如何阻止SQL注入？ 使用参数化查询（PreparedStatement）使数据与命令分离；绝不从字符串拼接动态SQL；动态列名和表名使用允许列表。

3. 身份验证和授权有什么区别？ 身份验证回答“你是谁”；授权回答“你被允许做什么”。安全的登录只是一半——会话和令牌也必须安全管理。

4. 为什么难以猜测的UUID不能替代授权检查？ 因为难以猜测的ID仍可能泄露或被猜到；API仍必须检查调用者是否有权访问每个具体对象。

5. SSRF的危险在哪里？ 服务器获取用户提供的任意URL，包括内部地址——攻击者借用服务器访问内部网络，因此必须限制目标、在DNS和重定向后检查，并在网络层阻止。

本文改写自TechtoTech主页于2026年11月14日发布的幻灯片。内容、代码示例和OWASP对应关系均来自原始幻灯片。