JSONP真的不安全吗？为什么现在都不推荐用了？

UI子轩提问于 2026-03-11 20:49:18 阅读 18

安全

最近在维护一个老项目，发现它还在用 JSONP 跨域请求用户数据。我看网上说 JSONP 有安全风险，但不太明白具体危险在哪——毕竟我们只信任自家的 API 啊？而且试过改成 fetch + CORS，但后端没配响应头，直接被浏览器拦了。

现在纠结要不要硬着头皮重构，还是继续用 callback=? 这种方式。有没有人能说说 JSONP 到底会引发什么实际的安全问题？比如 XSS 或数据泄露之类的？

我来解答赞 2 收藏

反馈

1 条解答

Newb.梓艺 Lv1

JSONP确实有安全问题，而且不是那种"理论上有风险"的级别，是实打实的坑。

核心问题在于：JSONP本质是让你去请求一个script标签，返回的直接就是一段JavaScript代码，会被浏览器执行。这意味着你完全信任服务端返回的内容，但如果有人劫持了你的DNS或者API被攻击，返回一段恶意JS，那用户的cookie、token啥的直接就被人拿走了。你没法验证返回的数据是不是真的是JSON，也没法阻止服务端返回恶意代码。

还有一个CSRF的问题：script标签发请求会自动带上cookie，绕不过浏览器的同源策略保护。你说只信自家API，但万一API被XSS或者被其他方式插入了恶意代码呢？防不胜防。

至于你说后端没配CORS被拦了，这反而是简单的事。只需要后端加几个响应头：

// PHP示例，其他语言类似

header("Access-Control-Allow-Origin: https://your-frontend.com");

header("Access-Control-Allow-Credentials: true");

header("Access-Control-Allow-Methods: GET, POST, OPTIONS");

如果后端不肯改，那就搞个服务端代理，让你的前端请求同域的代理接口，代理去调用那个跨域的API。

我的建议：能重构就重构，别纠结。JSONP是历史遗留方案，现在CORS才是标准。短期看配响应头或者加代理都能解决，长期看趁早淘汰JSONP。你只是被后端的懒政卡住了，又不是技术上的死胡同。

2026-03-11 21:02