Security Considerations（安全考虑事项）是任何系统、应用、协议或业务流程设计阶段都必须纳入的核心环节

在当今数字化时代，无论是软件系统、网络架构、产品设计还是业务运营，安全考量（Security Considerations）都成为至关重要的环节。它涉及对潜在威胁的识别、风险评估、防护措施制定以及持续监控等一系列过程，旨在保护资产（如数据、系统、用户隐私等）免受未授权访问、破坏、泄露或滥用。以下从核心维度、常见场景、实施框架及趋势等方面进行详细分析。

一、安全考量的核心维度

安全考量需覆盖多个层面，不同场景下侧重点可能不同，但核心维度通常包括以下几个方面：

1. 资产识别与分类

• 核心目标：明确需要保护的对象及其价值，为后续风险评估提供基础。
• 关键资产类型：
  • 数据资产：用户隐私数据（如身份证号、手机号）、商业机密（如源代码、交易数据）、知识产权等。
  • 系统资产：服务器、网络设备、应用软件、云服务资源等。
  • 实体资产：物理设备（如终端电脑、IoT设备）、办公场所等。
  • 声誉资产：品牌形象、用户信任度等（间接但影响深远）。
• 分类原则：根据资产的敏感性（如公开、内部、机密、高度机密）、完整性要求（如不可篡改）、可用性需求（如7x24小时服务）进行分级。

2. 威胁建模与识别

• 威胁定义：可能利用系统漏洞导致资产受损的行为或事件（人为、自然、技术故障等）。
• 常见威胁类型：
  • 网络攻击：DDoS攻击、SQL注入、钓鱼攻击、勒索软件等。
  • 内部风险：员工误操作、恶意泄露数据、权限滥用等。
  • 物理威胁：设备被盗、自然灾害（火灾、洪水）导致系统中断。
  • 供应链风险：第三方组件（如开源库）存在漏洞、供应商数据泄露。
• 威胁建模方法：如STRIDE模型（Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege），用于系统性梳理威胁场景。

3. 风险评估与优先级排序

• 风险计算公式：风险 = 威胁发生的可能性 × 威胁造成的影响（定量或定性分析）。
• 评估维度：
  • 影响程度：财务损失、法律责任（如违反《GDPR》《个人信息保护法》）、声誉损害、业务中断时长等。
  • 可能性：威胁发生的概率（如高、中、低），需结合历史数据、行业趋势判断。
• 优先级排序：聚焦高风险场景（如“高可能性+高影响”），优先分配资源进行防护。

4. 防护措施设计与实施

针对识别的风险，需从技术、管理、流程等层面制定防护策略：

• 技术防护：
  • 网络安全：防火墙、入侵检测系统（IDS）、加密技术（传输加密TLS、存储加密AES）、VPN、零信任架构。
  • 应用安全：代码审计、漏洞扫描、输入验证、权限最小化设计、安全开发流程（SDL）。
  • 数据安全：数据脱敏、访问控制（RBAC/ABAC）、数据备份与恢复、数据泄露检测。
  • 终端安全： antivirus软件、终端检测与响应（EDR）、设备加密。
• 管理与流程防护：
  • 安全政策：制定明确的安全规范（如密码策略、数据处理流程）。
  • 人员管理：安全培训（提升员工防钓鱼意识）、背景调查、权限生命周期管理（离职员工权限回收）。
  • 应急响应：制定安全事件响应计划（IRP），明确应急步骤、责任人、恢复目标（RTO/RPO）。
  • 合规管理：定期审计以满足行业法规（如金融行业PCI DSS、医疗行业HIPAA）。

5. 监控、检测与响应

• 持续监控：通过日志分析（如SIEM系统）、流量监控、异常行为检测（如用户登录地点异常）实时追踪系统状态。
• 快速检测：建立威胁情报库，利用自动化工具识别潜在攻击（如异常流量峰值、可疑API调用）。
• 应急响应：遵循“发现-遏制-根除-恢复-总结”流程，最小化攻击影响（如隔离受感染服务器、发布漏洞补丁）。

6. 安全合规与法律要求

• 核心合规框架：
  • 全球：GDPR（欧盟）、ISO 27001（信息安全管理体系）。
  • 中国：《网络安全法》《数据安全法》《个人信息保护法》《关键信息基础设施安全保护条例》。
  • 行业特定：金融行业《网络安全等级保护基本要求》、医疗行业《医疗卫生机构网络安全管理办法》。
• 合规要求：数据本地化存储、跨境数据传输审批、用户知情同意、数据泄露通知义务（如GDPR要求72小时内报告）等。

二、不同场景下的安全考量重点

1. 软件与应用开发

• 需在设计阶段嵌入安全（左移安全），而非上线后修补。
• 重点关注：第三方依赖漏洞（如Log4j事件）、认证授权缺陷、输入验证不足导致的注入攻击。
• 工具支持：静态应用安全测试（SAST）、动态应用安全测试（DAST）、软件成分分析（SCA）。

2. 云计算与云服务

• 责任共担模型：云厂商负责基础设施安全（如AWS/Azure的数据中心），用户负责应用层、数据安全（如配置错误导致的S3桶泄露）。
• 重点关注：云配置安全（如开放不必要的端口）、共享责任边界模糊、云服务商合规性。

3. 物联网（IoT）设备

• 设备资源受限（算力、存储低），传统安全措施难以直接应用。
• 重点关注：固件漏洞、弱密码（如默认密码未修改）、缺乏远程更新机制导致漏洞无法修复。

4. 人工智能（AI）系统

• 新型安全风险：模型投毒（训练数据被篡改）、对抗性攻击（输入微小变化导致模型误判）、模型泄露（窃取训练数据或模型参数）。
• 伦理风险：算法偏见可能间接导致歧视，需纳入安全考量。

三、安全考量的实施挑战

1. 成本与收益平衡：高强度安全防护可能增加系统复杂度和成本，需在安全需求与用户体验、业务效率间找到平衡。
2. 威胁动态变化：攻击手段不断升级（如AI生成钓鱼邮件），静态防护措施难以应对，需持续迭代。
3. 内部风险难管控：员工安全意识不足或恶意行为，可能成为最薄弱环节。
4. 合规复杂性：不同地区、行业的法规要求差异大，跨国业务需满足多重合规标准。

四、未来趋势与建议

1. 自动化与智能化：利用AI、机器学习提升威胁检测效率（如异常行为识别）、自动化漏洞修复。
2. 零信任架构普及：摒弃“内部网络可信”假设，所有访问请求均需验证，降低内部风险。
3. 隐私计算技术：在数据可用不可见的前提下实现数据分析（如联邦学习、同态加密），平衡安全与业务需求。
4. 安全左移与DevSecOps：将安全融入开发全流程，实现“安全即代码”。

总结建议

• 安全考量需贯穿全生命周期（设计、开发、运行、退役），而非一次性项目。
• 建立“风险驱动”思维，优先解决高影响风险，而非追求“绝对安全”。
• 定期进行安全演练（如红队攻击演练）和审计，发现潜在漏洞。
• 加强跨团队协作（开发、运维、安全、业务），形成安全文化。

通过系统性的安全考量，组织可以有效降低安全事件发生概率，减少损失，保护核心资产与用户信任，为业务可持续发展提供保障。

Security Considerations（安全考虑事项）是任何系统、应用、协议或业务流程设计阶段都必须纳入的核心环节。以下我将从“分析框架”和“常见风险域”两个维度，为你提供一份结构化、可落地的“Security Considerations 分析”指南。

一、分析框架：7 步闭环模型

1. 资产梳理（Asset Inventory）

   • 明确需要保护的对象：数据（用户数据、配置、密钥）、功能（API、管理后台）、资源（算力、带宽、存储）、品牌信誉等。
   • 输出：资产清单 + 分级（公开/内部/机密/绝密）。

2. 威胁建模（Threat Modeling）

   • 常用方法：STRIDE、PASTA、Kill Chain、ATT&CK。
   • 核心问题：
     • 谁可能攻击？（内部员工、外部黑客、供应链）
     • 攻击路径？（网络、物理、社工、供应链）
     • 攻击动机？（数据窃取、勒索、破坏、间谍）

3. 风险识别（Risk Identification）

   • 结合 OWASP Top 10、CWE/SANS 25、云原生风险（如容器逃逸、K8s 错误配置）。
   • 工具：静态代码扫描（SAST）、依赖漏洞扫描（SCA）、动态测试（DAST）、渗透测试。

4. 风险评估（Risk Assessment）

   • 计算：Risk = Likelihood × Impact。
   • 输出：风险矩阵（高/中/低），优先处理高风险（如 RCE、未授权访问）。

5. 控制措施设计（Controls Design）

   • 分层防御：
     • 预防：最小权限、输入校验、加密、WAF、RASP。
     • 检测：IDS/IPS、日志审计、UEBA、蜜罐。
     • 响应：IR 流程、备份恢复、故障切换。
   • 参考标准：NIST SP 800-53、ISO 27001、CIS Controls。

6. 验证与测试（Validation & Testing）

   • 方法：渗透测试、红蓝对抗、Bug Bounty、混沌工程。
   • 关键指标：MTTD（平均检测时间）、MTTR（平均修复时间）。

7. 持续改进（Continuous Improvement）

   • 建立 Security Champions 机制；
   • 定期复评（每季度/每次大版本）；
   • 跟踪新漏洞（CVE、0day）和合规变化（GDPR、CCPA、等保 2.0）。

二、常见风险域：9 大高频场景

三、实战案例：Web 应用安全考虑清单（精简版）

1. 认证

   • 强制 HTTPS + HSTS；
   • 密码策略（长度>12，加盐哈希 Argon2/bcrypt）；
   • 登录失败锁定 + 图形验证码。

2. 授权

   • 每个 API 校验权限（避免 IDOR）；
   • 管理后台强制 2FA + IP 白名单。

3. 输入输出

   • 全局输入过滤（XSS/SQLi）；
   • 输出编码（模板引擎自动转义）。

4. 数据

   • 敏感字段加密（AES-256-GCM）；
   • 数据库连接启用 TLS；
   • 日志脱敏（邮箱、身份证掩码）。

5. 基础设施

   • 定期补丁（OS、中间件）；
   • 关闭不必要的端口和服务；
   • 使用 WAF（如 Cloudflare、ModSecurity）。

四、工具推荐

• 威胁建模：Microsoft TMT、OWASP Threat Dragon
• 漏洞扫描：Trivy（容器）、ZAP（Web）、Semgrep（SAST）
• 合规检查：ScoutSuite（多云）、Prowler（AWS）
• 监控响应：Wazuh（SIEM）、Falco（运行时）

五、总结

Security Considerations 不是一次性任务，而是贯穿 设计→开发→部署→运维→退役 的全生命周期过程。关键点：

• 左移安全：在需求/设计阶段就介入（如威胁建模）。
• 自动化：CI/CD 中嵌入 SAST/SCA/DAST。
• 量化风险：用数据说话（漏洞数量、修复时长、合规分数）。
• 文化：培养“安全是每个人的责任”意识。

如需针对某一具体场景（如 SaaS、IoT、区块链）做深度分析，可再告诉我！

Tomcat is configured to be reasonably secure for most use cases by default. Some environments may require more, or less, secure configurations. This page is to provide a single point of reference for configuration options that may impact security and to offer some commentary on the expected impact of changing those options. The intention is to provide a list of configuration options that should be considered when assessing the security of a Tomcat installation.

Note: Reading this page is not a substitute for reading and understanding the detailed configuration documentation. Fuller descriptions of these attributes may be found in the relevant documentation pages.
Non-Tomcat settings

Tomcat configuration should not be the only line of defense. The other components in the system (operating system, network, database, etc.) should also be secured.

Tomcat should not be run under the root user. Create a dedicated user for the Tomcat process and provide that user with the minimum necessary permissions for the operating system. For example, it should not be possible to log on remotely using the Tomcat user.

File permissions should also be suitably restricted. In the .tar.gz distribution, files and directories are not world readable and the group does not have write access. On Unix like operating systems, Tomcat runs with a default umask of 0027 to maintain these permissions for files created while Tomcat is running (e.g. log files, expanded WARs, etc.).

Taking the Tomcat instances at the ASF as an example (where auto-deployment is disabled and web applications are deployed as exploded directories), the standard configuration is to have all Tomcat files owned by root with group Tomcat and whilst owner has read/write privileges, group only has read and world has no permissions. The exceptions are the logs, temp and work directory that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they can’t change the Tomcat configuration, deploy new web applications or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.

At the network level, consider using a firewall to limit both incoming and outgoing connections to only those connections you expect to be present.
JMX

The security of the JMX connection is dependent on the implementation provided by the JRE and therefore falls outside the control of Tomcat.

Typically, access control is very limited (either read-only to everything or read-write to everything). Tomcat exposes a large amount of internal information and control via JMX to aid debugging, monitoring and management. Given the limited access control available, JMX access should be treated as equivalent to local root/admin access and restricted accordingly.

The JMX access control provided by most (all?) JRE vendors does not log failed authentication attempts, nor does it provide an account lock-out feature after repeated failed authentications. This makes a brute force attack easy to mount and difficult to detect.

Given all of the above, care should be taken to ensure that, if used, the JMX interface is appropriately secured. Options you may wish to consider to secure the JMX interface include:

configuring a strong password for all JMX users;
binding the JMX listener only to an internal network;
limiting network access to the JMX port to trusted clients; and
providing an application specific health page for use by external monitoring systems.

Default web applications
General

Tomcat ships with a number of web applications that are enabled by default. Vulnerabilities have been discovered in these applications in the past. Applications that are not required should be removed so the system will not be at risk if another vulnerability is discovered.
ROOT

The ROOT web application presents a very low security risk but it does include the version of Tomcat that is being used. The ROOT web application should normally be removed from a publicly accessible Tomcat instance, not for security reasons, but so that a more appropriate default page is shown to users.
Documentation

The documentation web application presents a very low security risk but it does identify the version of Tomcat that is being used. It should normally be removed from a publicly accessible Tomcat instance.
Examples

The examples web application should always be removed from any security sensitive installation. While the examples web application does not contain any known vulnerabilities, it is known to contain features (particularly the cookie examples that display the contents of all received and allow new cookies to be set) that may be used by an attacker in conjunction with a vulnerability in another application deployed on the Tomcat instance to obtain additional information that would otherwise be unavailable.
Manager

The Manager application allows the remote deployment of web applications and is frequently targeted by attackers due to the widespread use of weak passwords and publicly accessible Tomcat instances with the Manager application enabled. The Manager application is not accessible by default as no users are configured with the necessary access. If the Manager application is enabled then guidance in the section Securing Management Applications section should be followed.
Host Manager

The Host Manager application allows the creation and management of virtual hosts - including the enabling of the Manager application for a virtual host. The Host Manager application is not accessible by default as no users are configured with the necessary access. If the Host Manager application is enabled then guidance in the section Securing Management Applications section should be followed.
Securing Management Applications

When deploying a web application that provides management functions for the Tomcat instance, the following guidelines should be followed:

Ensure that any users permitted to access the management application have strong passwords.
Do not remove the use of the LockOutRealm which prevents brute force attacks against user passwords.
Configure the RemoteAddrValve in the context.xml file for the management application which limits access to localhost by default. If remote access is required, limit it to specific IP addresses using this valve.

Security manager

Enabling the security manager causes web applications to be run in a sandbox, significantly limiting a web application’s ability to perform malicious actions such as calling System.exit(), establishing network connections or accessing the file system outside of the web application’s root and temporary directories. However, it should be noted that there are some malicious actions, such as triggering high CPU consumption via an infinite loop, that the security manager cannot prevent.

Enabling the security manager is usually done to limit the potential impact, should an attacker find a way to compromise a trusted web application . A security manager may also be used to reduce the risks of running untrusted web applications (e.g. in hosting environments) but it should be noted that the security manager only reduces the risks of running untrusted web applications, it does not eliminate them. If running multiple untrusted web applications, it is recommended that each web application is deployed to a separate Tomcat instance (and ideally separate hosts) to reduce the ability of a malicious web application impacting the availability of other applications.

Tomcat is tested with the security manager enabled; but the majority of Tomcat users do not run with a security manager, so Tomcat is not as well user-tested in this configuration. There have been, and continue to be, bugs reported that are triggered by running under a security manager.

The restrictions imposed by a security manager are likely to break most applications if the security manager is enabled. The security manager should not be used without extensive testing. Ideally, the use of a security manager should be introduced at the start of the development cycle as it can be time-consuming to track down and fix issues caused by enabling a security manager for a mature application.

Enabling the security manager changes the defaults for the following settings:

The default value for the deployXML attribute of the Host element is changed to false.

server.xml
General

The default server.xml contains a large number of comments, including some example component definitions that are commented out. Removing these comments makes it considerably easier to read and comprehend server.xml.

If a component type is not listed, then there are no settings for that type that directly impact security.
Server

Setting the port attribute to -1 disables the shutdown port.

If the shutdown port is not disabled, a strong password should be configured for shutdown.
Listeners

The APR Lifecycle Listener is not stable if compiled on Solaris using gcc. If using the APR/native connector on Solaris, compile it with the Sun Studio compiler.

The JNI Library Loading Listener may be used to load native code. It should only be used to load trusted libraries.

The Security Lifecycle Listener should be enabled and configured as appropriate.
Connectors

By default, a non-TLS, HTTP/1.1 connector is configured on port 8080. Connectors that will not be used should be removed from server.xml.

AJP Connectors should only be used on trusted networks or be appropriately secured with a suitable secret attribute.

AJP Connectors block forwarded requests with unknown request attributes. Known safe and/or expected attributes may be allowed by configuration an appropriate regular expression for the allowedRequestAttributesPattern attribute.

The address attribute may be used to control which IP address a connector listens on for connections. By default, a connector listens on all configured IP addresses.

The allowTrace attribute may be used to enable TRACE requests which can be useful for debugging. Due to the way some browsers handle the response from a TRACE request (which exposes the browser to an XSS attack), support for TRACE requests is disabled by default.

The discardFacades attribute set to true will cause a new facade object to be created for each request. This reduces the chances of a bug in an application exposing data from one request to another.

The encodedSolidusHandling attribute allows non-standard parsing of the request URI. Setting this attribute to a non-default value when behind a reverse proxy may enable an attacker to bypass any security constraints enforced by the proxy.

The maxPostSize attribute controls the maximum size of a POST request that will be parsed for parameters. The parameters are cached for the duration of the request so this is limited to 2MB by default to reduce exposure to a DOS attack.

The maxSavePostSize attribute controls the saving of POST requests during FORM and CLIENT-CERT authentication. The parameters are cached for the duration of the authentication (which may be many minutes) so this is limited to 4KB by default to reduce exposure to a DOS attack.

The maxParameterCount attribute controls the maximum number of parameter and value pairs (GET plus POST) that can be parsed and stored in the request. Excessive parameters are ignored. If you want to reject such requests, configure a FailedRequestFilter.

The xpoweredBy attribute controls whether or not the X-Powered-By HTTP header is sent with each request. If sent, the value of the header contains the Servlet and JSP specification versions, the full Tomcat version (e.g. Apache Tomcat/9.0), the name of the JVM vendor and the version of the JVM. This header is disabled by default. This header can provide useful information to both legitimate clients and attackers.

The server attribute controls the value of the Server HTTP header. The default value of this header for Tomcat 4.1.x to 8.0.x is Apache-Coyote/1.1. From 8.5.x onwards this header is not set by default. This header can provide limited information to both legitimate clients and attackers.

The SSLEnabled, scheme and secure attributes may all be independently set. These are normally used when Tomcat is located behind a reverse proxy and the proxy is connecting to Tomcat via HTTP or HTTPS. They allow Tomcat to see the SSL attributes of the connections between the client and the proxy rather than the proxy and Tomcat. For example, the client may connect to the proxy over HTTPS but the proxy connects to Tomcat using HTTP. If it is necessary for Tomcat to be able to distinguish between secure and non-secure connections received by a proxy, the proxy must use separate connectors to pass secure and non-secure requests to Tomcat. If the proxy uses AJP then the SSL attributes of the client connection are passed via the AJP protocol and separate connectors are not needed.

The tomcatAuthentication and tomcatAuthorization attributes are used with the AJP connectors to determine if Tomcat should handle all authentication and authorisation or if authentication should be delegated to the reverse proxy (the authenticated user name is passed to Tomcat as part of the AJP protocol) with the option for Tomcat to still perform authorization.

The requiredSecret attribute in AJP connectors configures shared secret between Tomcat and reverse proxy in front of Tomcat. It is used to prevent unauthorized connections over AJP protocol.
Host

The host element controls deployment. Automatic deployment allows for simpler management but also makes it easier for an attacker to deploy a malicious application. Automatic deployment is controlled by the autoDeploy and deployOnStartup attributes. If both are false, only Contexts defined in server.xml will be deployed and any changes will require a Tomcat restart.

In a hosted environment where web applications may not be trusted, set the deployXML attribute to false to ignore any context.xml packaged with the web application that may try to assign increased privileges to the web application. Note that if the security manager is enabled that the deployXML attribute will default to false.
Context

This applies to Context elements in all places where they can be defined: server.xml file, default context.xml file, per-host context.xml.default file, web application context file in per-host configuration directory or inside the web application.

The crossContext attribute controls if a context is allowed to access the resources of another context. It is false by default and should only be changed for trusted web applications.

The privileged attribute controls if a context is allowed to use container provided servlets like the Manager servlet. It is false by default and should only be changed for trusted web applications.

The allowLinking attribute of a nested Resources element controls if a context is allowed to use linked files. If enabled and the context is undeployed, the links will be followed when deleting the context resources. Changing this setting from the default of false on case insensitive operating systems (this includes Windows) will disable a number of security measures and allow, among other things, direct access to the WEB-INF directory.

The sessionCookiePathUsesTrailingSlash can be used to work around a bug in a number of browsers (Internet Explorer, Safari and Edge) to prevent session cookies being exposed across applications when applications share a common path prefix. However, enabling this option can create problems for applications with Servlets mapped to /*. It should also be noted the RFC6265 section 8.5 makes it clear that different paths should not be considered sufficient to isolate cookies from other applications.
Valves

It is strongly recommended that an AccessLogValve is configured. The default Tomcat configuration includes an AccessLogValve. These are normally configured per host but may also be configured per engine or per context as required.

Any administrative application should be protected by a RemoteAddrValve (this Valve is also available as a Filter). The allow attribute should be used to limit access to a set of known trusted hosts.

The default ErrorReportValve includes the Tomcat version number in the response sent to clients. To avoid this, custom error handling can be configured within each web application. Alternatively, you can explicitly configure an ErrorReportValve and set its showServerInfo attribute to false. Alternatively, the version number can be changed by creating the file CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties with content as follows:

server.info=Apache Tomcat/9.0.x

Modify the values as required. Note that this will also change the version number reported in some of the management tools and may make it harder to determine the real version installed. The CATALINA_HOME/bin/version.bat|sh script will still report the correct version number.

The default ErrorReportValve can display stack traces and/or JSP source code to clients when an error occurs. To avoid this, custom error handling can be configured within each web application. Alternatively, you can explicitly configure an ErrorReportValve and set its showReport attribute to false.

The RewriteValve uses regular expressions and poorly formed regex patterns may be vulnerable to “catastrophic backtracking” or “ReDoS”. See Rewrite docs for more details.
Realms

The MemoryRealm is not intended for production use as any changes to tomcat-users.xml require a restart of Tomcat to take effect.

The JDBCRealm is not recommended for production use as it is single threaded for all authentication and authorization options. Use the DataSourceRealm instead.

The UserDatabaseRealm is not intended for large-scale installations. It is intended for small-scale, relatively static environments.

The JAASRealm is not widely used and therefore the code is not as mature as the other realms. Additional testing is recommended before using this realm.

By default, the realms do not implement any form of account lock-out. This means that brute force attacks can be successful. To prevent a brute force attack, the chosen realm should be wrapped in a LockOutRealm.
Manager

The manager component is used to generate session IDs.

The class used to generate random session IDs may be changed with the randomClass attribute.

The length of the session ID may be changed with the sessionIdLength attribute.

The persistAuthentication controls whether the authenticated Principal associated with the session (if any) is included when the session is persisted during a restart or to a Store.
Cluster

The cluster implementation is written on the basis that a secure, trusted network is used for all of the cluster related network traffic. It is not safe to run a cluster on a insecure, untrusted network.

If you are operating on an untrusted network or would prefer to exercise an over-abundance of caution, you can use the EncryptInterceptor to encrypt traffic between nodes.
System Properties

The org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH and org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH system properties allow non-standard parsing of the request URI. Using these options when behind a reverse proxy may enable an attacker to bypass any security constraints enforced by the proxy.

The org.apache.catalina.connector.Response.ENFORCE_ENCODING_IN_GET_WRITER system property has security implications if disabled. Many user agents, in breach of RFC2616, try to guess the character encoding of text media types when the specification-mandated default of ISO-8859-1 should be used. Some browsers will interpret as UTF-7 a response containing characters that are safe for ISO-8859-1 but trigger an XSS vulnerability if interpreted as UTF-7.
web.xml

This applies to the default conf/web.xml file, the /WEB-INF/tomcat-web.xml and the /WEB-INF/web.xml files in web applications if they define the components mentioned here.

The DefaultServlet is configured with readonly set to true. Changing this to false allows clients to delete or modify static resources on the server and to upload new resources. This should not normally be changed without requiring authentication.

The DefaultServlet is configured with listings set to false. This isn’t because allowing directory listings is considered unsafe but because generating listings of directories with thousands of files can consume significant CPU leading to a DOS attack.

The DefaultServlet is configured with showServerInfo set to true. When the directory listings is enabled the Tomcat version number is included in the response sent to clients. To avoid this, you can explicitly configure a DefaultServlet and set its showServerInfo attribute to false. Alternatively, the version number can be changed by creating the file CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties with content as follows:

server.info=Apache Tomcat/9.0.x

Modify the values as required. Note that this will also change the version number reported in some of the management tools and may make it harder to determine the real version installed. The CATALINA_HOME/bin/version.bat|sh script will still report the correct version number.

The CGI Servlet is disabled by default. If enabled, the debug initialisation parameter should not be set to 10 or higher on a production system because the debug page is not secure.

When using the CGI Servlet on Windows with enableCmdLineArguments enabled, review the setting of cmdLineArgumentsDecoded carefully and ensure that it is appropriate for your environment. The default value is secure. Insecure configurations may expose the server to remote code execution. Further information on the potential risks and mitigations may be found by following the links in the CGI How To.

FailedRequestFilter can be configured and used to reject requests that had errors during request parameter parsing. Without the filter the default behaviour is to ignore invalid or excessive parameters.

HttpHeaderSecurityFilter can be used to add headers to responses to improve security. If clients access Tomcat directly, then you probably want to enable this filter and all the headers it sets unless your application is already setting them. If Tomcat is accessed via a reverse proxy, then the configuration of this filter needs to be co-ordinated with any headers that the reverse proxy sets.
General

BASIC and FORM authentication pass user names and passwords in clear text. Web applications using these authentication mechanisms with clients connecting over untrusted networks should use SSL.

The session cookie for a session with an authenticated user are nearly as useful as the user’s password to an attacker and in nearly all circumstances should be afforded the same level of protection as the password itself. This usually means authenticating over SSL and continuing to use SSL until the session ends.

Tomcat Home
The Apache Software Foundation
Apache Tomcat 9
Version 9.0.34, Apr 3 2020
Links

Docs Home
FAQ
User Comments

User Guide

1) Introduction
2) Setup
3) First webapp
4) Deployer
5) Manager
6) Host Manager
7) Realms and AAA
8) Security Manager
9) JNDI Resources
10) JDBC DataSources
11) Classloading
12) JSPs
13) SSL/TLS
14) SSI
15) CGI
16) Proxy Support
17) MBeans Descriptors
18) Default Servlet
19) Clustering
20) Load Balancer
21) Connectors
22) Monitoring and Management
23) Logging
24) APR/Native
25) Virtual Hosting
26) Advanced IO
27) Mavenized
28) Security Considerations
29) Windows Service
30) Windows Authentication
31) Tomcat's JDBC Pool
32) WebSocket
33) Rewrite
34) CDI 2 and JAX-RS
35) GraalVM Support

Reference

Release Notes
Configuration
Tomcat Javadocs
Servlet 4.0 Javadocs
JSP 2.3 Javadocs
EL 3.0 Javadocs
WebSocket 1.1 Javadocs
JASPIC 1.1 Javadocs
Common Annotations 1.3 Javadocs
JK 1.2 Documentation

Apache Tomcat Development

Building
Changelog
Status
Developers
Architecture
Functional Specs.
Tribes

Security Considerations
Table of Contents

Introduction
Non-Tomcat settings
    JMX
Default web applications
    General
    ROOT
    Documentation
    Examples
    Manager
    Host Manager
    Securing Management Applications
Security manager
server.xml
    General
    Server
    Listeners
    Connectors
    Host
    Context
    Valves
    Realms
    Manager
    Cluster
System Properties
web.xml
General