Protéger les applications web Tomcat

tomcat transforme un WAR en une base Tomcat autonome. Il s'appuie sur les composants Tomcat intégrés à l'empaqueteur et ne touche jamais à l'installation Tomcat de votre machine.

1. Dans l'interface graphique

  1. Sur la page du type d'application, choisissez Tomcat WAR.

    Choisir Tomcat WAR

  2. Sélectionnez le WAR d'entrée, la version de Java à embarquer et les plates-formes cibles, puis choisissez le mode simple ou avancé.

    Choisir l'entrée, la version de Java, la plate-forme cible et le mode

  3. En mode avancé, choisissez Tomcat 9 ou 10.1, ou laissez la détection automatique, et réglez au besoin le chemin de contexte, les options JVM et les règles d'exclusion. Le mode simple détermine la version de Tomcat à partir de l'analyse de compatibilité. Le sens de chaque option figure dans Réglages du mode avancé de Protector4J.

    Configurer la version de Tomcat, le chemin de contexte et les règles d'exclusion

  4. Choisissez le répertoire de sortie, vérifiez le récapitulatif et cliquez sur Exécuter la protection.

    Choisir le répertoire de sortie et lancer la protection

2. Exemples en ligne de commande

Indiquer le chemin de contexte :

p4j tomcat app.war dist --context /app

Analyse de compatibilité et application automatique des recommandations :

p4j tomcat app.war --compat-scan
p4j tomcat app.war dist --compat-apply --context /app

Les deux options ne peuvent pas être employées ensemble. Voici ce qui les distingue :

OptionEffetQuand l'utiliser
--compat-scanAnalyse le WAR d'entrée, affiche les risques et les recommandations de configuration, puis s'arrête. Rien n'est encodé et aucun dist n'est produit : aucun répertoire de sortie n'est requis.Lisez d'abord le rapport lors de la première protection, après une mise à jour de dépendances liées à Tomcat, après un changement d'étendue ou de réglages JSP, et lors de la recherche d'un problème de compatibilité.
--compat-applyAnalyse, intègre les recommandations prudentes, puis poursuit l'encodage et écrit la sortie. Un répertoire de sortie est donc nécessaire.Pour terminer l'empaquetage une fois le résultat de l'analyse lu et les recommandations acceptées. Convient aussi aux constructions répétées et aux chaînes d'intégration continue dont les règles sont déjà validées.

Pour tomcat, --compat-apply peut ajouter des règles d'exclusion à partir de l'analyse et ajuster la version de Tomcat, la superposition ZIP et le suffixe d'archive. Pour ces trois derniers, une valeur donnée explicitement en ligne de commande l'emporte. Les exclusions recommandées sont fusionnées par défaut avec vos propres motifs --exclude ; ajoutez --no-compat-excludes si vous ne le souhaitez pas. Le scanner ne fait qu'une analyse heuristique statique : les problèmes qui exigent une modification du code ne sont pas corrigés par --compat-apply, et l'application empaquetée nécessite toujours des tests de non-régression sur la plate-forme cible.

Les autres commandes, la liste complète des options, les variables d'environnement et les exemples d'automatisation figurent dans la Référence de la ligne de commande.

--tomcat-version vaut auto par défaut. Passez-la à 9 ou 10.1 pour la fixer :

p4j tomcat app.war dist --context /app --tomcat-version 10.1

3. Structure de la sortie

dist/
├── bin/
│   ├── catalina.sh
│   ├── startup.sh
│   ├── shutdown.sh
│   └── *.bat
├── conf/p4jx/
│   ├── contexts.list
│   ├── protected-classes.list
│   └── allowed-prefixes.list
├── protected/
│   └── app.p4jx
├── lib/
│   ├── p4jx-tomcat-runtime.jar
│   └── tomcat-runtime-deps.jar
├── vlxjre/
├── run.sh
└── run.bat

Aucun WAR physique n'est produit par défaut. Le web.xml, les ressources statiques, les classes non protégées, les ébauches de métadonnées et les implémentations protégées se trouvent tous dans protected/<contexte>.p4jx, présenté à Tomcat via le WebResourceSet de P4JX.

4. Démarrage et arrêt

Au premier plan :

./run.sh

En arrière-plan, à la manière de Tomcat :

./bin/startup.sh
./bin/shutdown.sh

Sous Windows, utilisez les .bat correspondants. Les journaux sont écrits dans le répertoire logs/ de la sortie.

Pour les cibles Windows, vous pouvez aussi produire un lanceur natif qui démarre le Tomcat intégré au premier plan — voir Créer un lanceur EXE Windows.

Options de démarrage JVM

À l'empaquetage, saisissez une option par ligne dans Options de démarrage JVM dans l'interface graphique, ou indiquez-les en ligne de commande :

p4j tomcat app.war dist \
  --context /app \
  --jvm-option -Xms1g \
  --jvm-option -Xmx2g

Pour les modifier dans un paquet déjà déployé :

  • macOS et Linux : modifiez bin/catalina.sh et ajoutez JVM_OPTS+=("-Xms1g" "-Xmx2g") après la ligne JVM_OPTS=(...) située dans run_java(). Cela vaut pour l'exécution au premier plan comme pour le démarrage en arrière-plan par startup.sh.
  • Windows, premier plan : modifiez bin\catalina.bat et ajoutez set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g" après la ligne set "JVM_OPTS=..." existante.
  • Windows, arrière-plan : ajoutez set "APP_JAVA_OPTS=-Xms1g -Xmx2g" dans bin\startup.bat avant l'appel à catalina.bat. S'il vous faut un jeu d'options permanent couvrant les deux cas, il est plus simple de régénérer le paquet depuis l'interface ou la ligne de commande.

Vous pouvez aussi placer APP_JAVA_OPTS devant la commande pour n'agir que sur une exécution. Les exemples complets pour CMD, PowerShell et les scripts figurent dans Options de démarrage JVM.

5. Choisir la version de Tomcat

Espace de noms de l'API dans le WARTomcatJava requis
javax.servlet.*Tomcat 9Java 8, 11, 17, 21 ou 25
jakarta.servlet.*Tomcat 10.1Java 11, 17, 21 ou 25

La détection automatique identifie d'abord l'espace de noms à partir des classes de l'application et des descripteurs de déploiement ; les noms des JAR ne servent que d'indice secondaire. Si javax et jakarta coexistent, l'outil refuse de deviner.

6. JSP

Lorsqu'un WAR contient des fichiers JSP, ils sont précompilés en classes de servlet et en correspondances d'URL pendant l'encodage. Compiler les JSP à l'exécution reviendrait à définir de nouvelles classes depuis le répertoire de travail de Tomcat, hors de la limite que le runtime protégé autorise pour la définition de classes.

Vous pouvez le régler explicitement :

--precompile-jsp
--no-precompile-jsp

Conservez la précompilation par défaut en production. La désactiver peut empêcher le chargement des pages d'une application fondée sur les JSP.

7. Étendue de la protection et règles d'exclusion

Par défaut, les classes d'application situées sous WEB-INF/classes sont protégées, et WEB-INF/lib ne l'est pas. Les classes exposées au web peuvent être exclues :

p4j tomcat app.war dist \
  --context /app \
  --exclude 'com.example.web.**,com.example.dto.**'

Excluez d'abord les servlets, les filtres et les écouteurs, ainsi que les DTO, les classes de configuration, les entités, les classes passerelles JNI et tout ce que le conteneur doit améliorer. L'analyse de compatibilité formule des recommandations prudentes.

8. Ajouter une autre application au même paquet Tomcat

p4j tomcat second.war dist \
  --append-app \
  --context /second

Contraintes :

  • le chemin de contexte ne doit pas entrer en conflit avec une application existante ;
  • l'application existante et la nouvelle doivent partager la même version majeure de Tomcat, la même version de Java et la même plate-forme cible ;
  • sans --append-app, l'outil refuse d'écrire dans un paquet Tomcat existant ;
  • dans l'interface graphique, cochez Ajouter une application à un dossier Tomcat existant et désignez le répertoire déjà en place.

9. Remarque à propos de Java 8

Pour les cibles Java 8, la superposition ZIP est activée automatiquement afin que le WebResourceSet de Tomcat puisse ouvrir l'archive protégée.