我试图发布然后获得一个简单的表格时会得到这个chrome标志。
问题是开发者控制台没有显示任何相关内容，我自己无法找到问题的根源。
有更多细节可供选择吗？ 查看触发错误的代码片段来修复它......
答案 0 :(得分：72)
在开发过程中绕过此错误的简单方法是将标题发送到浏览器
在将数据发送到浏览器之前放置标题。
在 php 中，您可以发送此标头以绕过此错误send header reference：
header('X-XSS-Protection:0');
在 ASP.net 中，您可以发送此标头并send header reference：
HttpContext.Response.AddHeader("X-XSS-Protection","0");
or
HttpContext.Current.Response.AddHeader("X-XSS-Protection","0");
在 nodejs 发送标题中，send header reference：
res.writeHead(200, {'X-XSS-Protection':0 });
// or express js
res.set('X-XSS-Protection', 0);
答案 1 :(得分：26)
Chrome v58 可能 或 可能不会 修复您的问题......这实际上取决于您和＃ 39;实际上是POST。例如，如果您尝试在输入/ select / textarea元素中发布一些原始HTML / XML数据，则您的请求可能仍会被审核员阻止。
在过去的几天里，我在两个不同的场景中遇到了这个问题：一个WYSIWYG 客户端编辑器和一个以某种内容预览为特色的交互式上传表单。我设法通过在 POST之前对原始HTML 进行base64编码来修复它们，然后在接收PHP页面上对其进行解码。这很可能会解决问题，最重要的是，提高开发人员对来自POST请求的数据的认知水平，希望推动他采用有效的数据编码/解码策略，并通过XSS类攻击加强他们的Web应用程序
要在客户端上对您的内容进行base64编码，您可以使用现在大多数浏览器都支持的native btoa() function，或者使用第三方替代方案，例如jQuery插件（我最终使用了this，这样就可以了。）
要对POST数据进行base64解码，您可以使用PHP的base64_decode(str)函数，ASP.NET的Convert.FromBase64String(str)或其他任何东西（取决于您的服务器端场景）
有关详细信息，请查看我就该主题撰写的this blog post。
答案 2 :(得分：5)
在这种情况下，作为Creative forums（某种vBulletin构造）的第一次撰稿人并减少在论坛访问之前向主持人发布PM，很容易从上面比较流行的答案中概括了问题的本质。 命令是
http://forums.creative.com/private.php?do=insertpm&pmid=
如上所述，实际数据是“输入/选择/ textarea元素中的原始HTML / XML数据”。
在用户端处理此类错误（或功能）的一般要求是某种快速修改或旋转。 This post讨论了清除缓存，重置Chrome设置，创建new_user或使用新的Beta版本重试操作的选项。 还有人建议用以下方法启动一个新实例：
google-chrome-stable --disable-xss-auditor
在此修改后的版本中，该推出实际上适用于此W10 1703 Chrome 061 版本：
chrome --disable-xss-auditor
但是，在重新登录到站点并再次尝试发布时，会生成相同的错误。也许语法想要提炼或其他东西都是错误的。
然后启动Edge并从那里重新发布似乎是合理的，结果证明完全没问题。
答案 3 :(得分：3)
在某些情况下，此可能有帮助。修改Apache httpd.conf文件并添加
ResponseHeader set X-XSS-Protection 0
可能已修复Version 58.0.3029.110 (64-bit)。
答案 4 :(得分：2)
我注意到如果文字中有撇号'，Chrome会屏蔽它。
答案 5 :(得分：0)
当我在 POST请求页面中将javascript:void(0)从#更新为<a href="javascript:void(0)" id="loginlink">login</a>
时，就可以了。
例如：
<a href="#" id="loginlink">login</a>
更改为：
export MONGO_URL= mongodb://<dbuser>:<dbpassword>@ds035693.mlab.com:35693/abcd
答案 6 :(得分：0)
这是一个Chrome错误。唯一的补救措施是使用FireFox，直到他们修复此Chrome错误。 XSS审核员破坏了一个已经工作了20年的页面似乎是一种症状，而不是原因。
答案 7 :(得分：0)
我解决了这个问题！
在我的情况下，当我创建submmit时，我将HTML发送到操作，在模型中我有一个属性，接受HTML＆＃34; AllowHTML＆＃34;。
解决方案包括删除这个＆＃34; AllowHTML＆＃34;财产和一切都好！
显然我不再将HTML发送到动作，因为在我的情况下我不需要它