这篇文章按后端面试常见攻击面整理，重点放在漏洞产生条件、修复手段和工程限制。认证、JWT、OAuth 2.0 与权限模型见 认证与授权常见面试题总结。
输入与浏览器安全
⭐️什么是 SQL 注入？如何防止？
SQL 注入发生在应用把不可信输入作为 SQL 代码的一部分拼接执行。攻击者可以改变原查询语义，读取、修改甚至删除不该访问的数据。
主要防护手段是：
使用 PreparedStatement、ORM 参数绑定或 MyBatis #{}，让数据库区分 SQL 代码和数据。
#{}表名、列名和排序方向无法使用普通绑定参数时，使用服务端枚举或白名单映射，不能直接拼接用户输入。
数据库账号遵循最小权限，读服务不授予写权限，应用账号不使用 DBA 权限。
输入校验作为补充，但不能用“过滤几个关键字”代替参数化查询。
MyBatis ${} 是文本替换，适合受控的 SQL 片段。直接接收前端排序字段再写入 ${orderBy} 仍然会产生注入风险。
${}${orderBy}⭐️什么是 XSS？有哪些类型？
XSS（Cross-Site Scripting，跨站脚本攻击）让攻击者控制的内容在其他用户浏览器中作为代码执行。
常见类型有：
反射型 XSS：恶意输入随当前请求返回并执行，例如搜索参数直接写回页面。
存储型 XSS：恶意内容被保存到数据库，其他用户查看时执行，例如评论、昵称和富文本。
DOM 型 XSS：前端脚本把不可信数据写入危险 DOM API，漏洞主要发生在浏览器端。
防护重点是按输出上下文编码：HTML、属性、URL、JavaScript 和 CSS 上下文不能共用同一种转义。需要展示富文本时使用成熟的 HTML Sanitizer，并限制协议、标签和属性；减少 innerHTML、document.write、eval 等危险 API。CSP 可以降低部分攻击影响，但不能代替正确编码和净化。
innerHTMLdocument.writeeval⭐️什么是 CSRF？如何防止？
CSRF（Cross-Site Request Forgery，跨站请求伪造）利用浏览器会自动携带 Cookie 等凭据的行为，诱导已登录用户向目标站点发起非本人意愿的状态变更请求。
常见防护措施包括：
对状态变更请求校验不可预测并绑定会话的 CSRF Token。
根据架构使用同步 Token 或正确实现的 Double Submit Cookie。
校验 Origin，缺失时再按策略检查 Referer。
OriginReferer给会话 Cookie 配置合适的 SameSite，并使用 Secure、HttpOnly。
SameSiteSecureHttpOnly不用 GET 执行转账、改密、删除等状态变更操作。
对支付、改密等高风险操作要求用户再次确认或重新认证。
XSS 可能绕过很多 CSRF 防护，因此两类漏洞需要同时治理。CORS 也不是通用的 CSRF 防护方案。
⭐️什么是 SSRF？如何防止？
SSRF（Server-Side Request Forgery，服务端请求伪造）发生在服务端根据用户可控 URL 发起请求。攻击者可能借此访问本机管理端口、云元数据服务或内网系统。
防护时优先取消任意 URL 能力：业务只需要访问固定合作方时，对协议、域名、端口和路径做白名单。还要继续处理：
只允许 https 等必要协议，拒绝 file、gopher 等无关协议。
httpsfilegopherDNS 解析后校验目标 IP，阻止环回、私网、链路本地和保留地址；跳转后的目标也要重新校验。
防范 DNS Rebinding、IPv6、十进制或混合编码 IP 等绕过。
通过出口代理、网络 ACL 和云防火墙限制应用可访问的地址。
设置连接/读取超时、响应大小和重定向次数上限。
只用正则判断 URL 字符串不够，因为域名解析和重定向可能把请求带到另一个地址。
CORS 是什么？它能阻止接口被调用吗？
CORS（Cross-Origin Resource Sharing）是浏览器执行的跨源读取控制机制。服务端通过响应头声明哪些 Origin、方法和请求头可以被浏览器页面使用。
CORS 不能替代认证和授权：curl、服务端程序、恶意 App 不受浏览器同源策略约束，仍然可以直接请求 API。简单跨源请求甚至可能已经发送到服务端，只是浏览器不把响应内容交给脚本。
配置带凭据请求时，不能把 Access-Control-Allow-Origin 随意反射为任意 Origin，也不能与通配符混用。允许列表要精确匹配协议、主机和端口。
Access-Control-Allow-Origin接口与传输安全
⭐️如何防止接口请求被篡改和重放？
HTTPS 负责保护传输链路；接口签名用于验证请求来自持有密钥的一方，并校验关键字段没有被修改。常见签名内容包括 HTTP 方法、规范化路径、查询参数、Body 摘要、时间戳、随机数和客户端标识。
服务端需要：
使用 HMAC 或数字签名验证完整性和来源。
限制时间戳允许的偏差。
在有效窗口内记录并拒绝重复 nonce 或请求 ID。
nonce使用恒定时间比较签名，提供密钥轮换和吊销能力。
对业务操作继续做幂等校验，不能把安全防重放等同于业务幂等。
签名不能隐藏请求内容，不能替代 HTTPS。把固定密钥硬编码在前端 JavaScript 或可被反编译的客户端中，也无法建立可靠的客户端身份。
HTTPS 如何保证传输安全？
HTTPS 在 HTTP 与 TCP 之间使用 TLS，主要提供：
机密性：会话密钥加密应用数据。
完整性：认证加密或 MAC 防止数据被静默修改。
身份认证：客户端验证服务端证书链、域名和有效期。
TLS 握手通常利用非对称密码和证书完成身份验证与密钥协商，后续数据使用效率更高的对称加密。生产环境应全站使用 HTTPS，正确校验证书，禁用过时协议和弱密码套件，并根据场景启用 HSTS。
下面以 TLS 1.2 的 ECDHE_RSA 握手为例：
HTTPS 不能修复 SQL 注入、越权或 XSS。它保护的是通信链路，不会自动保证业务代码安全。
CORS、CSRF 和 XSS 有什么区别？
名称解决或利用的问题主要防护CORS浏览器是否允许页面脚本读取跨源响应精确配置允许的 Origin、方法和请求头CSRF利用浏览器自动携带凭据发起非预期请求CSRF Token、Origin 校验、SameSite、重新认证XSS不可信内容在页面中作为脚本执行上下文编码、HTML 净化、安全 DOM API、CSP
名称解决或利用的问题主要防护
名称
解决或利用的问题
主要防护
CORS浏览器是否允许页面脚本读取跨源响应精确配置允许的 Origin、方法和请求头
CORS
浏览器是否允许页面脚本读取跨源响应
精确配置允许的 Origin、方法和请求头
CSRF利用浏览器自动携带凭据发起非预期请求CSRF Token、Origin 校验、SameSite、重新认证
CSRF
利用浏览器自动携带凭据发起非预期请求
CSRF Token、Origin 校验、SameSite、重新认证
XSS不可信内容在页面中作为脚本执行上下文编码、HTML 净化、安全 DOM API、CSP
XSS
不可信内容在页面中作为脚本执行
上下文编码、HTML 净化、安全 DOM API、CSP
三者可能互相影响，但不能相互替代。例如，修好 CORS 不代表没有 CSRF；HttpOnly 能降低 Cookie 被脚本直接读取的风险，但 XSS 仍可能调用站内接口。
HttpOnlyWebhook 回调如何验真？
使用 HTTPS，并按第三方协议验证 HMAC 或数字签名。
签名覆盖原始请求体，避免 JSON 重新序列化后字段顺序和空白变化导致验签错误。
校验时间戳、事件 ID 和重放窗口。
以事件 ID 建立唯一约束或幂等记录，重复回调返回成功但不重复执行业务。
密钥支持轮换，轮换期可短暂同时接受新旧密钥。
不把来源 IP 白名单作为唯一验证方式；云平台出口地址会变化，代理头也可能被伪造。
接收成功与业务处理成功可以分开：先可靠落库或写入队列，再异步处理，避免第三方因超时反复重试放大压力。
密码、密钥与敏感数据
⭐️密码应该如何存储？
密码应使用专门的密码哈希算法，不使用可逆加密，也不直接使用 MD5、SHA-1 或 SHA-256 这类高速哈希。
OWASP 当前优先推荐 Argon2id；无法使用时可以选择 scrypt，遗留或兼容场景常用 bcrypt、PBKDF2。参数要根据服务器能力调到可接受的验证耗时，并为每个密码使用随机盐。成熟密码库通常会自动生成盐，并把算法、参数和盐编码进哈希结果。
可选的 Pepper 应与数据库分开保存在 KMS、HSM 或密钥管理系统中。Pepper 泄露后需要制定轮换方案；忘记密码只能重置，不能从密码哈希中还原原密码。
加密、哈希、编码和签名有什么区别？
手段是否可逆是否需要密钥常见用途编码可逆不需要数据表示与传输，如 Base64哈希单向通常不需要完整性摘要、密码哈希的组成部分对称加密可逆加解密共享密钥大量数据保密，如 AES-GCM非对称加密可逆公钥与私钥密钥封装、小数据加密数字签名验证而非解密私钥签名、公钥验证身份和完整性证明HMAC验证而非解密共享密钥接口签名、消息完整性
手段是否可逆是否需要密钥常见用途
手段
是否可逆
是否需要密钥
常见用途
编码可逆不需要数据表示与传输，如 Base64
编码
可逆
不需要
数据表示与传输，如 Base64
哈希单向通常不需要完整性摘要、密码哈希的组成部分
哈希
单向
通常不需要
完整性摘要、密码哈希的组成部分
对称加密可逆加解密共享密钥大量数据保密，如 AES-GCM
对称加密
可逆
加解密共享密钥
大量数据保密，如 AES-GCM
非对称加密可逆公钥与私钥密钥封装、小数据加密
非对称加密
可逆
公钥与私钥
密钥封装、小数据加密
数字签名验证而非解密私钥签名、公钥验证身份和完整性证明
数字签名
验证而非解密
私钥签名、公钥验证
身份和完整性证明
HMAC验证而非解密共享密钥接口签名、消息完整性
HMAC
验证而非解密
共享密钥
接口签名、消息完整性
下面三张图分别展示普通哈希、对称加密和非对称加密的基本关系。密码存储仍应使用 Argon2id 等专用密码哈希算法，而不是图中的 MD5、SHA-256 或 SHA-512。
Base64 不提供保密性。普通哈希也不能证明消息来自谁；需要来源认证时使用 HMAC 或数字签名。
密钥和 API Key 应该如何管理？
不把密钥硬编码进源码、镜像、前端包或公开配置。
使用 KMS、HSM、Vault 或云密钥管理服务集中存储、授权和审计。
每个服务使用独立身份和最小权限，避免多个系统共享同一长期密钥。
支持生成、分发、轮换、吊销和过期的完整生命周期。
日志、异常和监控中不输出密钥；已经提交到 Git 的密钥必须立即吊销，删除当前文件不等于泄露已消失。
开发、测试和生产环境使用不同密钥。
“配置文件不提交 Git”只能减少一种泄露途径，不能解决运行时访问、CI/CD、备份和员工权限问题。
日志中如何保护敏感数据？
密码、SessionId、Access Token、Refresh Token、银行卡安全码、私钥和完整连接串不应进入日志。手机号、邮箱、身份证号和银行卡号按业务与合规要求脱敏。
日志还要防止 CRLF 等日志注入：结构化记录字段，清理不可信换行和控制字符。安全审计日志应记录主体、操作、资源、结果、时间、来源和请求 ID，但避免记录原始凭据。日志访问本身需要权限、留存和防篡改策略。
文件、依赖与运行安全
⭐️文件上传要防范哪些风险？
文件上传可能带来 WebShell、脚本执行、路径穿越、恶意 SVG、压缩炸弹、超大文件耗尽资源和恶意文件传播。
常见防护措施包括：
只允许业务需要的扩展名，检查实际文件类型和文件签名，不能只信任 Content-Type。
Content-Type服务端重新生成文件名，规范化路径，禁止用户控制保存路径。
限制单文件大小、数量、解压层数和总解压大小。
文件存放在 Web 根目录之外或独立对象存储，通过受控下载接口访问。
图片、文档按需重新编码或做内容净化，接入杀毒和沙箱扫描。
上传和下载都做认证授权，设置下载响应头，避免浏览器把文件当作站点脚本执行。
允许上传 ZIP 时要特别处理 Zip Slip 和压缩炸弹。解压后的每个目标路径都必须仍在指定目录内。
什么是反序列化漏洞？
反序列化会把字节流或文本恢复为对象。如果输入由攻击者控制，而反序列化框架可以实例化任意类型或触发危险的对象方法，就可能造成远程代码执行、文件操作或拒绝服务。
优先使用简单、明确的数据传输格式和固定 DTO，不接收原生 Java 序列化数据。关闭多态类型自动识别，使用允许列表限制可反序列化类型，并及时升级相关库。数字签名只能证明数据未被未知第三方修改；如果可信发送方本身被攻陷，危险对象仍可能被正常签名。
如何治理第三方依赖和供应链风险？
锁定依赖版本和来源，避免构建过程无约束地获取变化内容。
使用 SCA、依赖机器人和漏洞数据库持续扫描，不只在上线前扫一次。
生成并保存 SBOM，知道线上版本实际包含哪些组件。
校验制品签名、哈希和构建来源，保护包仓库与 CI/CD 凭据。
删除不再使用的依赖，及时修复可达的高风险漏洞。
对重大升级做回归、灰度和回滚准备。
扫描报告中的漏洞不一定都能从当前应用路径触发，但“不可达”结论需要证据，不能仅因为暂未复现就长期忽略。
如何防止暴力破解、撞库和短信验证码滥用？
按账号、IP、设备和风险等级组合限流，避免只封 IP 误伤共享网络。
失败次数达到阈值后增加等待时间、验证码或 MFA，不使用可被攻击者批量触发的永久锁号。
登录和找回密码返回一致提示，降低账号枚举风险。
验证码短期有效、一次使用、绑定业务和接收方，并限制发送与校验次数。
检测泄露密码、异常设备、异地登录和凭据填充行为。
管理员和高风险账号强制使用更强认证。
限流计数器需要集中存储或在网关统一执行。多实例各自计数，很容易让攻击者把请求分散到不同节点绕过限制。
常见的安全响应头有哪些？
Content-Security-Policy：限制脚本、样式、图片等资源来源，降低 XSS 影响。
Content-Security-PolicyStrict-Transport-Security：要求浏览器后续只通过 HTTPS 访问。
Strict-Transport-SecurityX-Content-Type-Options: nosniff：禁止部分 MIME 嗅探。
X-Content-Type-Options: nosniffframe-ancestors CSP 指令：限制页面被嵌入，防范点击劫持。
frame-ancestorsReferrer-Policy：控制 Referer 暴露范围。
Referrer-PolicyPermissions-Policy：限制摄像头、麦克风、定位等浏览器能力。
Permissions-Policy响应头要结合站点实际资源逐步收紧。CSP 可以先用 Report-Only 观察违规，再上线强制策略；直接配置过宽的 unsafe-inline 会削弱防护效果。
unsafe-inline发生凭据泄露或入侵后应该怎么处理？
确认范围：识别泄露的密钥、账号、数据和受影响时间。
快速止血：吊销 Token 和密钥，隔离主机，关闭受攻击入口，但保留必要取证数据。
消除根因：修复漏洞、清理持久化手段、轮换关联凭据，检查横向移动。
恢复服务：从可信制品和备份恢复，灰度开放并加强监控。
复盘改进：补告警、测试、权限和密钥轮换流程，按法律与合规要求通知相关方。
不要在确认泄露后只“修改代码里的密钥字符串”。旧密钥需要在服务端正式吊销，Git 历史、日志、构建产物和下游系统也要检查。
参考资料
OWASP Cheat Sheet Series
OWASP SQL Injection Prevention Cheat Sheet
OWASP SQL Injection Prevention Cheat Sheet
OWASP Cross Site Scripting Prevention Cheat Sheet
OWASP Cross Site Scripting Prevention Cheat Sheet
OWASP Cross-Site Request Forgery Prevention Cheat Sheet
OWASP Cross-Site Request Forgery Prevention Cheat Sheet
OWASP Server Side Request Forgery Prevention Cheat Sheet
OWASP Server Side Request Forgery Prevention Cheat Sheet
OWASP Password Storage Cheat Sheet
OWASP Password Storage Cheat Sheet
OWASP File Upload Cheat Sheet
写在最后
感谢你能看到这里，也希望这篇文章对你有点用。
JavaGuide 坚持更新 6 年多，近 6000 次提交、600+ 位贡献者一起打磨。如果这些内容对你有帮助，非常欢迎点个免费的 Star 支持下（完全自愿，觉得有收获再点就好）：GitHub | Gitee。
如果你想要付费支持/面试辅导（比如简历优化、一对一提问、高频考点突击资料等）的话，欢迎了解我的知识星球。已经坚持维护六年，内容持续更新，虽白菜价（0.4元/天）但质量很高，主打一个良心！
