JSONP还有人用吗？它到底有什么安全风险？
最近在维护一个老项目，发现接口还在用 JSONP 跨域，但听说这玩意儿很不安全。我试着改成 fetch + CORS，但后端没配 Access-Control-Allow-Origin，直接被拦了。
现在纠结要不要继续用 JSONP，比如像这样：$.ajax({ url: 'xxx', dataType: 'jsonp' })，但又担心被 XSS 攻击。有没有实际案例说明它到底危险在哪？
如果必须用 JSONP，至少该怎么写才稍微安全点？比如对回调函数名做校验之类的？
- 1
回答
18浏览
JSONP真的不安全吗？为什么现在都不推荐用了？
最近在维护一个老项目，发现它还在用 JSONP 跨域请求用户数据。我看网上说 JSONP 有安全风险，但不太明白具体危险在哪——毕竟我们只信任自家的 API 啊？而且试过改成 fetch + CORS...
- 1
回答
30浏览
JSONP还能用吗？为什么现在都说是安全风险？
最近在重构一个老项目，发现它还在用 JSONP 跨域请求第三方数据。我查了下资料，说 JSONP 有 XSS 风险，但又没太明白具体怎么出问题的。我自己试着重构成 fetch + CORS，但对方接口...
- 1
回答
30浏览
JSONP跨域请求在Vue中怎么用？一直报错
我在Vue项目里想用JSONP请求第三方接口，但总是失败，浏览器控制台提示“Uncaught ReferenceError: callback is not defined”。我试过动态创建scrip...
- 2
回答
46浏览
JSONP跨域调用时如何防范第三方注入恶意脚本导致XSS？
我在用JSONP做跨域请求时突然意识到，如果第三方接口返回恶意代码，岂不是能直接在页面执行？比如我这样调用： const script = document.createElement('script...
- 2
回答
14浏览
前端密码加密到底该怎么做才安全？
我在做登录页面，用户输入的密码直接传给后端总觉得不安全，想在前端先加密一下。但不知道用什么方式合适，试过用 crypto-js 做 MD5，结果发现好像还是能被破解？ 而且我看到有人说前端加密没意义，...
- 2
回答
567浏览
CORS设置中用*通配符有什么安全风险？为什么改用具体域名反而报错？
我在后端设置了CORS的Access-Control-Allow-Origin为"*"，结果被安全审计指出存在漏洞。改成允许特定域名后，浏览器却报"Response to preflight requ...
- 1
回答
7浏览
前端开发中如何落地SDL安全实践？
我们团队最近开始推行安全开发生命周期（SDL），但我作为前端，不太清楚具体该做些什么。比如在需求和设计阶段，前端需要参与哪些安全评审？ 我试过在代码里加 CSP 头，但上线后发现很多第三方脚本报错，像...
- 1
回答
8浏览
前端安全审计时如何防止CSS注入风险？
最近在做项目的安全审计，发现有个用户自定义主题的功能，允许传入CSS字符串动态应用样式。我担心这里会有CSS注入漏洞，比如用户输入恶意代码破坏页面或窃取数据。虽然我用了DOMPurify处理HTML，...
- 1
回答
14浏览
前端安全审计时如何防止XSS攻击？
最近在做项目的安全审计，发现用户输入的内容直接渲染到页面上，担心有XSS风险。比如下面这段代码，把用户昵称直接插进HTML里，会不会被注入脚本？ <div class="user-info"&g...
- 1
回答
26浏览
Vue项目做白盒安全测试时，如何避免模板注入风险？
我们团队最近在做Web安全的白盒测试，发现有个Vue组件直接把后端返回的HTML字符串用v-html渲染了，担心会有XSS漏洞。但业务又需要展示富文本，试过用DOMPurify清洗，但测试工具还是报“...
JSONP的安全风险主要在这几个方面：
第一，没有机制阻止恶意站点调用。JSONP本质是动态创建script标签，浏览器对script标签的跨域请求没有同源限制，服务端返回啥浏览器就执行啥。这意味着任何网站都可以调用你的JSONP接口，攻击者可以构造一个页面诱导用户访问，然后神不知鬼不觉地调用你的接口。
第二，XSS风险。如果攻击者控制了JSONP返回的数据（比如通过URL参数注入），可以直接在返回内容里插入恶意JS代码，用户访问时就会执行。
第三，CSRF风险。JSONP请求会带上用户的cookie，攻击者可以诱导用户发送带有认证信息的请求。
实际案例的话，早年12306、淘宝等网站都曝出过通过JSONP泄露用户信息的漏洞，攻击者只需要构造一个URL让已登录用户访问，就能拿到他们的数据。
如果非用JSONP不可，防护措施：
对回调函数名严格限制，只能是字母数字下划线，禁止特殊字符，可以用正则
/^[a-zA-Z0-9_]+$/这样过滤。验证Referer或者Origin请求头，虽然可以被伪造，但能挡住大部分直接访问。
接口加上token验证，别完全依赖cookie。
但说真的，能不用就别用。
你后端没配CORS的话，最简单的办法是让后端配一下，就加一个响应头
Access-Control-Allow-Origin: 你的域名，如果是需要带cookie的跨域，那就要配Access-Control-Allow-Credentials: true，同时Origin不能是通配符。如果后端实在不配合，你还可以搞个后端代理，让前端请求同源的后端服务，后端再去调第三方接口返回给你。这样就不涉及跨域了。