对于大多数用例来说，默认配置下的 Tomcat 都是相当安全的。有些环境可能需要更多（或更少）的安全配置。本文统一介绍了一下可能影响安全性的配置选项，并适当说明了一下修改这些选项所带来的预期影响。目的是为了在评价 Tomcat 安装时，提供一些应值得考虑的配置选项。
注意：本章内容毕竟有所局限，你还需要对配置文档进行深入研究。在相关文档中有更完整的属性描述。
Tomcat 配置不应成为唯一的防线，也应该保障系统（操作系统、网络及数据库，等等）中的其他组件的安全。
不应该以根用户的身份来运行 Tomcat，应为 Tomcat 进程创建并分配一个专门的用户，并为该用户配置最少且必要的操作系统权限。比如，不允许使用 Tomcat 用户实现远程登录。
文件权限同样也应适当限制。就拿 ASF 中的 Tomcat 实例为例说明吧（禁止自动部署，Web 应用被部署为扩张的目录。），标准配置规定所有的 Tomcat 文件都由根用户及分组用户所拥有，拥有者具有读写特权，分组只有读取特权，而 World 则没有任何特权。例外之处在于，logs、temp 以及 work 目录的权限都由 Tomcat 用户而不是根用户所拥有。这意味着即使攻击者破坏了 Tomcat 进程，他们也不能改变 Tomcat 配置，无法部署新应用，也无法修改现有应用。Tomcat 进程使用掩码 007 来维护这种权限许可。
对于网络层面，需要使用防火墙来限制进站与出站连接，只允许出现那些你希望的连接。
Tomcat 安装时自带了一些默认启用的 Web 应用。过去一段时间内发现了不少关于这些应用的漏洞。用不到的应用就该删除，以避免给系统带来相关漏洞而产生的安全风险。
ROOT 应用带来安全风险的可能性非常小，但它确实含有正在使用的 Tomcat 的版本号。应该从可公开访问的 Tomcat 实例中清除 ROOT 应用，不是出于安全性原因，而是因为这样能给用户提供一个更适合的默认页面。
Documentation 带来安全风险的可能性非常小，但》它标识出了当前正使用的 Tomcat 版本。应该从可公开访问的 Tomcat 实例中清除该应用。
应该从安全敏感性安装中移除 examples 应用。虽然 examples 应用并不包含任何已知的漏洞，但现已证明，它所包含的一些功能可以被攻击者利用，特别是一些显示所有接收内容，并且能设置新 cookie 的 cookie 范例。攻击者将这些公关和部署在 Tomcat 实例中的另一个应用中的漏洞相结合，就能获取原本根本不可能得到的信息。
由于 Manager 应用允许远程部署 Web 应用，所以经常被攻击者利用，因为应用的密码普遍强度不够，而且大多在 Manager 应用中启用了 Tomcat 实例可公开访问的功能。Manager 应用默认是不能访问的，因为没有配置能够执行这种访问的用户。如果启用 Manager 应用，就应该遵循 保证管理型应用的安全性 一节中的指导原则。
Host Manager 应用能够创建并管理虚拟主机，包括启用虚拟主机的 Manager 应用。Host Manager 应用默认是不能访问的，因为没有配置能够执行这种访问的用户。如果启用 Host Manager 应用，就应该遵循 保证管理型应用的安全性 一节中的指导原则。
在配置能够为 Tomcat 实例提供管理功能的 Web 应用时，需要遵循下列指导原则：
启用安全管理器能让 Web 应用运行在沙盒中，从而极大限制 Web 应用执行恶意行为的能力——比如调用 System.exit()，在 Web 应用根目录或临时目录外建立网络连接或访问文件系统。但应注意的是，有些恶意行为是安全管理器所无法阻止的，比如利用无限循环产生 CPU 极大开销。
启用安全管理器经常用来限制潜在影响，比如防止攻击者通过某种方式危害受信任的 Web 应用。安全管理器也可能被用来减少运行不受信任的 Web 应用（比如在托管环境中）所带来的风险，但它只能减少这种风险，并不能终止不受信任的 Web 应用。如果运行多个不受信任的 Web 应用，强烈建议将每个应用都部署为独立的 Tomcat 实例（理想情况下还需要部署在独立的主机上），以便尽量减少恶意 Web 应用对其他应用产生的危害。
Tomcat 已经过安全管理器的测试。但大多数 Tomcat 用户却没有运行过安全管理器，所以 Tomcat 也没有相关的用户测试过的配置。现在已经（并会继续）报告指出了一些关于运行安全管理器时产生的 Bug。
安全管理器在运行时所暴露出的限制可能在于中断很多应用。所以，在未经大量测试前，还是不要使用它为好。理想情况下，安全管理器应该在开发前期使用，因为对于一个成熟的应用来说，启用安全管理器后，记录修补问题会极大浪费时间。
启用安全管理器会改变下列设置的默认值：