在开发一个Web应用后，常见的交付方式是将项目打包成WAR文件，然后部署到Tomcat服务器上。这个过程看起来简单，但实际操作中稍有疏忽，就可能带来安全隐患，比如暴露管理后台、引入恶意代码。
准备环境：确认Tomcat正常运行
假设你已经有一台Linux服务器，安装了Tomcat。可以通过访问 http://your-server:8080 看到Tomcat的欢迎页面，说明服务已启动。如果没有，先检查Java环境和Tomcat的启动脚本。
上传并部署WAR包
将本地打包好的 myapp.war 上传到服务器的 webapps 目录下。可以直接使用scp命令：
scp myapp.war user@server:/opt/tomcat/webapps/上传完成后，Tomcat会自动解压并部署这个应用。几秒后，你就能通过 http://your-server:8080/myapp 访问它。
手动部署：更可控的方式
有时候你不希望自动部署，或者想先验证WAR包的安全性。可以先把WAR包传到临时目录，检查内容。
jar -tf myapp.war | head -20这能列出WAR包前20个文件，看看有没有可疑路径，比如 /META-INF/context.xml 中是否配置了危险的数据库连接，或者是否存在 shell.jsp 这类明显异常的文件。
关闭自动部署功能
生产环境中，建议关闭自动部署。编辑 conf/server.xml，找到 Host 标签，设置 autoDeploy="false"：
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false">
<!-- 其他配置 -->
</Host>这样即使有人上传了WAR包，也不会被自动加载，减少攻击面。
避免使用默认管理后台
很多人习惯用Tomcat自带的Manager App来部署，但这需要用户名密码，一旦弱口令或泄露，整个服务器可能被控制。更安全的做法是通过脚本或CI/CD流程部署，而不是开放管理页面给公网。
如果你必须使用Manager，至少要做三件事：改掉默认账户、限制IP访问、启用HTTPS。
定期清理未使用的应用
测试时部署的WAR包，比如 test.war，往往会被遗忘。这些应用可能包含调试接口或日志输出，成为突破口。每次上线后，检查 webapps 目录，删掉不用的WAR和对应文件夹。
权限最小化原则
确保运行Tomcat的系统用户不是root。创建一个专用用户 tomcat，只赋予必要权限。这样即使应用被攻破，攻击者也无法轻易操作系统。
同时，WAR包解压后的目录权限应限制写入，防止上传JSP后门。
监控部署行为
在企业环境中，可以在 webapps 目录设置inotify监控，一旦有新文件写入立即告警。结合日志分析，能快速发现异常部署尝试。
比如，凌晨三点突然上传了一个WAR包，而团队没人值班，那很可能是扫描器或黑客在试探。