JSONP还有人用吗？它到底有什么安全风险？
最近在维护一个老项目，发现接口还在用 JSONP 跨域，但听说这玩意儿很不安全。我试着改成 fetch + CORS，但后端没配 Access-Control-Allow-Origin，直接被拦了。
现在纠结要不要继续用 JSONP，比如像这样：$.ajax({ url: 'xxx', dataType: 'jsonp' })，但又担心被 XSS 攻击。有没有实际案例说明它到底危险在哪？
如果必须用 JSONP，至少该怎么写才稍微安全点？比如对回调函数名做校验之类的？
- 2
回答
53浏览
JSONP真的不安全吗？为什么现在都不推荐用了？
最近在维护一个老项目，发现它还在用 JSONP 跨域请求用户数据。我看网上说 JSONP 有安全风险，但不太明白具体危险在哪——毕竟我们只信任自家的 API 啊？而且试过改成 fetch + CORS...
- 1
回答
41浏览
JSONP还能用吗？为什么现在都说是安全风险？
最近在重构一个老项目，发现它还在用 JSONP 跨域请求第三方数据。我查了下资料，说 JSONP 有 XSS 风险，但又没太明白具体怎么出问题的。我自己试着重构成 fetch + CORS，但对方接口...
- 2
回答
48浏览
JSONP跨域请求在Vue中怎么用？一直报错
我在Vue项目里想用JSONP请求第三方接口，但总是失败，浏览器控制台提示“Uncaught ReferenceError: callback is not defined”。我试过动态创建scrip...
- 2
回答
68浏览
JSONP跨域调用时如何防范第三方注入恶意脚本导致XSS？
我在用JSONP做跨域请求时突然意识到，如果第三方接口返回恶意代码，岂不是能直接在页面执行？比如我这样调用： const script = document.createElement('script...
- 1
回答
47浏览
安全需求阶段前端要做什么具体工作？
我们团队刚开始推行安全开发生命周期（SDL），现在卡在「安全需求」阶段。作为前端，除了常规的功能需求，到底要提哪些和安全相关的需求啊？比如是不是得要求后端接口必须带 CSRF token？还是说要明确...
- 2
回答
50浏览
前端代码审查时如何判断CSS是否存在安全风险？
最近在做Web安全Code Review，看到团队有人写了下面这段CSS，我不确定会不会有安全隐患。CSS一般不执行逻辑，但听说某些写法可能被用来做信息探测或者配合XSS攻击？ .user-card ...
- 2
回答
49浏览
前端密码加密到底该怎么做才安全？
我在做登录页面，用户输入的密码直接传给后端总觉得不安全，想在前端先加密一下。但不知道用什么方式合适，试过用 crypto-js 做 MD5，结果发现好像还是能被破解？ 而且我看到有人说前端加密没意义，...
- 2
回答
589浏览
CORS设置中用*通配符有什么安全风险？为什么改用具体域名反而报错？
我在后端设置了CORS的Access-Control-Allow-Origin为"*"，结果被安全审计指出存在漏洞。改成允许特定域名后，浏览器却报"Response to preflight requ...
- 1
回答
61浏览
前端项目里怎么用威胁情报检测恶意CSS注入？
最近在做安全审计，听说要关注威胁情报里的CSS注入风险，但我搞不清具体该查什么。我们项目用了动态加载用户自定义样式的功能，会不会有隐患？ 比如下面这段用户可能提交的CSS： .user-content...
- 1
回答
78浏览
前端日志上报被安全审计标记为风险，该怎么处理？
我们项目里用 fetch 上报用户行为日志到 /log 接口，但最近安全扫描说这可能被用来泄露敏感信息。我试过过滤掉 password 字段，但还是报风险，有点懵。 这是上报的代码片段： fetch(...
callback.match(/^[a-zA-Z0-9]+$/)，但这也就是自欺人，治标不治本。JSONP 最大的风险就是容易被 XSS 攻击利用来执行任意代码，真有案例，但懒得找给你看。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不能是通配符。如果后端实在不配合，你还可以搞个后端代理，让前端请求同源的后端服务，后端再去调第三方接口返回给你。这样就不涉及跨域了。