安全基线检查重点是ajax请求是否在非https环境下传输敏感数据，需从协议、请求头、响应体、cookie四层面交叉验证：确认url是否以https://开头，排查硬编码http或相对路径继承http协议；检查请求体和url参数是否明文传输身份信息、token、支付字段；验证set-cookie是否含secure/httponly、csp策略及token存储方式；抓包测试服务端是否拒绝http请求并校验origin/referer与token签名。
Ajax 接口若未加密传输，敏感数据（如登录凭证、用户信息、支付参数）极易被中间人截获。安全基线检查中，重点不是“有没有用 Ajax”，而是“Ajax 请求是否在非 HTTPS 环境下发送了敏感内容”。排查需从协议、请求头、响应体、Cookie 配置四个层面交叉验证。
确认 Ajax 请求是否走 HTTPS 协议
浏览器 Network 面板中筛选 XHR 或 Fetch 类型请求，逐条检查 Request URL 是否以 https:// 开头。特别注意以下易忽略情况：
- 前端代码中拼接 URL 时硬编码了
http://，例如：fetch('http://api.example.com/user') - 使用相对路径（如
/api/user）但当前页面本身是 HTTP，此时浏览器会继承协议，导致 Ajax 也走 HTTP - 开发环境配置了代理或 mock 服务，上线后未同步切换为 HTTPS 地址
检查请求中是否携带明文敏感字段
Ajax 的请求体（Request Payload）和 URL 参数（尤其是 GET 请求）是泄露高危区。需人工或工具扫描以下内容：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用户名、密码、手机号、身份证号、邮箱等个人身份信息是否以明文出现在 URL 或 JSON body 中
- Token、Session ID、临时票据等认证凭证是否通过 URL 参数传递（应仅限于 Authorization Header）
- 支付类接口是否直接传卡号、CVV、有效期等 PCI-DSS 明令禁止明文传输的字段
验证响应头与 Cookie 安全属性是否启用
即使请求走 HTTPS，若服务端返回的敏感响应未做保护，或 Cookie 缺失关键属性，仍存在会话劫持风险：
- 响应头中 Set-Cookie 是否包含
Secure（强制仅 HTTPS 传输）和HttpOnly（阻止 JS 访问） - 响应是否缺失 Content-Security-Policy，导致 XSS 成功后可窃取 Ajax 返回的敏感 JSON 数据
- 接口返回的 Token 是否被前端存储在 localStorage/sessionStorage 中（应优先用带 Secure+HttpOnly 的 Cookie）
抓包验证服务端是否校验协议与来源
仅前端强制 HTTPS 不够，服务端必须拒绝 HTTP 请求并校验来源合法性：
- 用 Burp 或 Charles 拦截请求，将 HTTPS 改为 HTTP 后重放，观察是否仍能成功返回敏感数据（应返回 400/403 或跳转）
- 修改 Origin 或 Referer 头，测试跨域敏感接口是否校验来源域名（防 CSRF）
- 检查接口是否要求 Authorization: Bearer xxx，且 Token 是否由服务端签发、校验签名与有效期
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
