如果我需要身份验证标头，提供 jsonp 是否安全？
我想提供 jsonp 服务，以便其他站点可以从我的站点获取 json 数据。我知道，如果我使用 cookie 来对用户进行身份验证，这将是危险的，因为浏览器会将 cookie 与所有请求一起发送到我的网站，因此恶意页面可以在不询问用户的情况下代表我的用户发出经过身份验证的请求。
对我的服务的所有请求都必须使用请求中设置的特殊标头 X-AG-AUTH 进行身份验证。必须在该标头中设置标识用户的秘密令牌。
在用户不提供秘密令牌的情况下，恶意网站是否能够通过 jsonp 从我的服务获取数据？
I want to serve jsonp so other sites can get json data from my site. I understand that this would be dangerous if I used cookies to authenticate users, because browsers would send the cookies with all requests to my site, so a malicious page could make authenticated requests on my users' behalves without asking them.
All requests to my service have to be authenticated with a special header set on the request, X-AG-AUTH. A secret token identifying the user must be set in that header.
Would a malicious site be able to get data from my service via jsonp without the user providing the secret token?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
那么，要求 jsonp 调用使用自定义标头将使 jsonp 调用对于来自其他域的请求毫无用处，因为您的调用者将无法设置这些标头。
您可以使用有点类似的方法：需要 CSRF 预防-style token 作为 POST 请求中的参数传递。这将要求您与您希望允许调用端点的每个站点共享生成这些令牌的逻辑和密钥。当然，如果这些密钥中的任何一个在远程服务器端被泄露，您可能不会知道，直到为时已晚。
如果您愿意放弃使用旧浏览器的功能，您可以使用 通过 CORS 的常规 JSON*解析器破坏前缀以防止跨站点脚本包含。
我假设您不想公开您的数据，在这种情况下您也希望需要 SSL。
Well, requiring a custom header for a jsonp call would render the jsonp call useless for requests coming from other domains, because your callers wouldn't be able to set those headers.
You could use a somewhat similar approach: require a CSRF-prevention-style token passed as a parameter in a POST request. This would require you to share both the logic for generating these tokens and a secret key with each site you want to allow to call your endpoint. Of course, if any of those keys were ever compromised on the remote server's side, you probably wouldn't know about it until it was too late.
If you're willing to forgo functionality for folks with really old browsers, you could use regular JSON over CORS* with a parser-breaking prefix to prevent cross-site script inclusion.
I'm assuming your data is not something you want to be made public, in which case you're hopefully also requiring SSL.