Protéger les applications Spring Boot

springboot protège les applications Spring Boot et prend en charge BOOT-INF/classes, BOOT-INF/lib, le chargeur Spring Boot et le balayage du framework.

1. Dans l'interface graphique

1. Sur la page du type d'application, choisissez Spring Boot.

   

2. Sélectionnez l'application Spring Boot à protéger, la version de Java à embarquer et les plates-formes cibles, puis choisissez le mode simple ou avancé.

   

3. En mode avancé, choisissez la disposition de sortie, les JAR de dépendances à protéger, les paramètres JavaFX, les options JVM et les règles d'exclusion. Le mode simple déduit la disposition et les exclusions de l'analyse de compatibilité. Le sens de chaque option figure dans Réglages du mode avancé de Protector4J.

   

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

   

2. Exemples en ligne de commande

La forme la plus courte :

p4j springboot app.jar dist

La disposition p4jx-fat est utilisée par défaut. Pour en choisir une autre explicitement :

p4j springboot app.jar dist --layout fat
p4j springboot app.jar dist --layout separate

Ne protéger qu'une partie de l'application :

p4j springboot app.jar dist \
  --protect 'com.example.service.impl.**' \
  --exclude 'com.example.dto.**,com.example.config.**'

3. Structure de la sortie et dispositions

p4jx-fat : la disposition par défaut, une seule archive protégée

dist/
├── app.p4jx              # devient app.jar avec le suffixe jar
├── vlxjre/
├── run.sh
├── run.command
└── run.bat

Caractéristiques :

• l'application entière est livrée sous forme d'une seule archive P4JX ;
• le fichier physique n'est pas un ZIP par défaut ;
• les ressources Spring Boot, les dépendances imbriquées et les métadonnées passent par une vue JAR virtuelle ;
• l'étendue de protection est la plus large ; convient aux applications qui ne dépendent pas de scanners de classpath tiers.

fat : disposition de compatibilité Spring Boot

dist/
├── app.jar
├── app.p4jx              # devient app-protected.jar avec le suffixe jar
├── vlxjre/
└── run.*

Caractéristiques :

• app.jar conserve la structure physique standard de BOOT-INF ;
• les implémentations réelles des classes protégées se trouvent dans l'archive P4JX voisine ;
• convient aux applications qui doivent balayer la structure physique du JAR Spring Boot, par exemple avec ClassGraph ou Reflections ;
• les deux fichiers dépendent l'un de l'autre et doivent être mis à jour et livrés ensemble.

separate : disposition de compatibilité éclatée

dist/
├── plain-launcher.jar
├── app.p4jx
├── lib/
├── vlxjre/
└── run.*

Caractéristiques :

• le chargeur Spring Boot, les classes non protégées et les dépendances sont séparés ;
• convient aux anciens environnements d'intégration qui exigent un classpath plat lib/* ;
• le lanceur produit précharge les classes protégées ;
• pour les nouveaux projets, préférez p4jx-fat, ou celle des deux (p4jx-fat ou fat) que recommande le scanner.

Choisir une disposition

La superposition ZIP n'aide que les outils qui lisent directement le répertoire central du ZIP. Elle ne remplace pas la structure physique Spring Boot dont ont besoin le ClassLoader et les scanners de classpath.

4. Démarrage

./run.sh --spring.profiles.active=prod

Sous Windows :

run.bat --spring.profiles.active=prod

Ne remplacez pas le répertoire vlxjre de la sortie par un JRE du système.

Pour les cibles Windows, vous pouvez aussi produire un lanceur natif. Il fonctionne avec les trois dispositions et coexiste avec les scripts de démarrage — voir Créer un lanceur EXE Windows.

Options de démarrage JVM

Vous pouvez fixer les options à l'empaquetage, soit une par ligne dans Options de démarrage JVM dans l'interface graphique, soit en ligne de commande :

p4j springboot app.jar dist \
  --jvm-option -Xms1g \
  --jvm-option -Xmx2g

Pour ajouter des options à un paquet déployé, le temps d'une exécution :

APP_JAVA_OPTS="-Duser.timezone=Europe/Paris" ./run.sh

Vous pouvez aussi modifier directement le script déployé :

• macOS et Linux : dans run.sh, ajoutez JVM_OPTS+=("-Xms1g" "-Xmx2g") après les lignes produites JVM_OPTS=(...) et JVM_OPTS+=(...).
• Windows : dans run.bat, ajoutez set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g" après la ligne produite set "JVM_OPTS=...".

Ne supprimez pas les options que l'empaqueteur a générées pour Spring Boot ou JavaFX, comme --add-opens et le chemin de modules. Un nouvel empaquetage écrase toute modification manuelle — voir Options de démarrage JVM.

5. Étendue de la protection

Par défaut, les classes d'application situées sous BOOT-INF/classes sont protégées. Ces classes liées à Spring valent mieux non protégées :

• classes @Controller, @RestController et @ControllerAdvice ;
• classes @Configuration, classes d'autoconfiguration et classes améliorées par AOT ou CGLIB ;
• DTO Jackson, entités JPA, records et modèles de validation ;
• le point d'entrée de l'application et toute classe que le framework construit ou place derrière un proxy directement ;
• classes nécessitant une amélioration du bytecode à l'exécution.

Protégez les implémentations de services et accédez-y par une façade ou une interface publique. Les règles acceptent les noms de classes exacts ainsi que pkg.* et pkg.**.

6. Protéger les JAR de dépendances

--protect-lib protège les dépendances correspondantes de BOOT-INF/lib et fonctionne avec les trois dispositions.

p4j springboot app.jar dist \
  --protect-lib 'company-core-*.jar,pricing-*.jar'

Ne protégez que vos propres dépendances à code fermé. Ne chiffrez pas les paquets de frameworks tiers comme Spring, Tomcat, les bibliothèques de journalisation ou les pilotes de bases de données dans l'idée de « protéger davantage ».

7. Analyse de compatibilité

p4j springboot app.jar --compat-scan
p4j springboot app.jar dist --compat-apply

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

Pour springboot, --compat-apply peut choisir la disposition, ajouter des règles d'exclusion et ajuster la superposition ZIP, JavaFX et le suffixe d'archive. Pour tout sauf les exclusions, 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.