由于其复杂性和用作攻击媒介的历史，某些格式可以被称为本质上不安全。想到 Adob​​e PDF 和 MS Office 文件。除非部署沙盒，否则任何类型的二进制可执行文件肯定都会出现问题。

但总的来说，这取决于用于打开文件的应用程序，而不是文件本身。即使是无法嵌入可执行代码的简单格式也可能被应用程序以错误的方式解析，从而导致错误和潜在漏洞。同样，沙盒应用程序可能存在允许可执行代码提升其权限的错误，因此我认为沙盒可执行文件与复杂文件格式一样危险。

通过使用可以自动检查的数据格式，使用自动生成的解析器，除了使用的语法之外不需要任何关于文件类型的信息，可以拥有相对安全的文件格式。我认为 ASN.1 格式是一个候选者。但这种技术几乎没有在任何地方使用。

理论上，任何需要复杂处理或允许嵌入其他格式（尤其是 Flash）的格式都可能是危险的。然而，目前最相关的问题是：

• 任何 Microsoft Office 文件（不是因为 Office 漏洞，而是因为这些文件可以嵌入 Flash 并利用其漏洞）
• PDF 文件
• 显然，任何可以自行执行的文件（各种可执行文件和批处理文件）。Windows 上的“批处理”文件不仅是*.bat文件，还包括 JavaScript 文件*.js、Visual Basic 脚本文件*.vbs、Windows 脚本文件*.wsf和具有各种文件扩展名的 PowerShell。
• 存档文件（主要是 ZIP 或 RAR），因为这些文件通常用于压缩上述文件类型并偷偷通过过滤器。

PDF 问题可能是对一个旧问题的引用，即预安装的 PDF 插件会自动执行 URL 片段中指定的 JavaScript。

没有危险文件格式的完整列表。这不仅是黑名单，它还忽略了polyglots：

该术语有时适用于在一种以上语言中有效但在每种语言中不严格执行相同功能的程序。

例如，可以构造一个也是 JavaScript 的 GIF和一个也是 JPEG 的 HTML 页面。任何安全但可以用另一种不安全语言编写多语言的文件格式都可能是不安全的。

当服务器发送文件时，它还会在 Content-Type 标头中发送该文件的 MIME 类型。当服务器断言的 Content-Type 与使用该内容的预期上下文一致时，一切都很好。当服务器不发送 Content-Type 时会发生什么？如果发送了具有一种 Content-Type 的文件而需要另一种类型，会发生什么情况？

悲伤发生。

一些浏览器认为服务器断言的内容类型是权威的，如果内容无法解析为该类型，则不会呈现内容。其他人忽略服务器声明的类型并尝试猜测（嗅探内容）其类型。这种嗅探可以采取启发式的形式，例如指定它的 URL 中文件名的后缀、内容的“神奇”前几个字节，或者只是尝试使用不同的解析器解析文件直到适合。尝试使用的解析器类型有时受特定标签的限制（例如img标记只会尝试根据浏览器支持的本机图像格式进行解析。）。Java和Flash等插件以及浏览器中不同类型的缓存和“文件保存”功能可能会或可能不记得服务器断言的内容类型，进一步加剧了这个问题。

此外，任何二进制文件格式都可能通过在解码它的代码中触发缓冲区溢出来提升权限。

如果您尝试从不受信任的来源提供内容，则需要对其进行代理和规范化。