这是一个有点主观的问题，但我想听听这样做的利弊。我管理一个名为Quick and Dirty Feed Parser的开源项目，该项目的目标是尽可能无缝地使用.NET中的RSS和Atom提要。
我在项目开发中很早就遇到过的一个问题是我用作测试用例的一些feed（即Hacker News RSS feed）使用了格式不正确的HTTP头，以及HttpWebRequest类在.NET 1.1及更高版本中，只要您在GET请求中收到其中一个标头，就会立即抛出“不安全的标头”异常。
我的问题是 - 我可以通过编程方式启用“useUnsafeHeader”配置选项，但是它会在该应用程序的上下文中的所有HttpWebRequests中执行。我的用户抱怨QD Feed Parser无法使用有效的Feed，这个标题就是原因。
现在我的库设置方式使得使用它的开发人员必须自己启用不安全的头解析，尽管他们中的大多数都不知道这是问题而且它为我创建了支持开销。
我可以简单地让Quick and Dirty Feed Parser默认启用不安全的头解析，并强制安全性的用户禁用它，但我不想打开对安全攻击不了解的用户。这里最好的选择是什么？
答案 0 :(得分：6)
“不安全”在这里有点极端;我会以不同的方式命名此设置。当不良行为的服务器发出不完全遵循HTTP RFC的标头时，问题就出现了。例如，RFC说CR字符后面必须跟一个LF字符，所以如果没有LF，你将得到一个execption，除非你允许“不安全”的标题。
实际上，许多HTTP客户端会忽略这些轻微违规，以便与尽可能多的服务器通信。这就是为什么你的浏览器或RSS阅读器永远不会抱怨“不安全”的标题。即使标头是虚假的，.NET客户端库也足够强大，例如，如果恶意攻击者省略了换行符，您就不会崩溃服务器。 :-)所以这里没有一个很大的安全问题，除非（例如）你用HTTP标题名称做蠢事，比如将它们直接发送到你的HTML中（这可能允许攻击者在你的HTML中注入XSS攻击）。
因此，只要您将HTTP标头视为与您的应用程序中的任何其他用户提交的数据（如查询字符串，POST数据等）一样不值得信任，那么您应该可以您应用中的“不安全”标头。