Retour de pentest & choix réglages d’instance

[Hamza]

Bonjour,

Suite à un pentest sur notre application basée sur la version v6.2, nous avons traité la majorité des points.
Il reste deux constats classés LOW pour lesquels nous souhaitons nous assurer que les pratiques sont alignées avec les recommandations de sécurité.

1) API interne – erreur Java 500 et fuite d’information

Ce comportement expose des détails internes de la stack Java, ce qui peut être considéré comme une fuite d’information technique selon les standards OWASP.En altérant une requête, la plateforme répond HTTP 500 avec un message Java.

1. S’agit-il d’un comportement connu sur certaines routes (/ui/json…) ? Un patch/build existe-t-il pour normaliser en 4xx sans message interne ?
   2.Y a-t-il une meilleure pratique côté Simplicité (filtre/exception mapper conseillé) pour sécuriser ces cas d’entrée invalides ?
2. Existe-t-il une configuration ou un mécanisme pour désactiver l’affichage des messages d’exception Java dans les réponses HTTP ?

2) Ajout d’en-têtes HTTP (impact)

Le rapport demande d’ajouter/forcer certains en-têtes de sécurité. Ces en-têtes sont recommandés par OWASP et les standards modernes pour renforcer la sécurité des applications web.

Cible demandée par l’audit :
Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Cache-Control
(optionnel : Referrer-Policy, Permissions-Policy, et politique sur X-XSS-Protection).

1. Préconisez-vous de les ajouter côté instance (mécanisme supporté : paramètre, filtre/servlet, extension) ou exclusivement au niveau reverse proxy ?
   2.Existe-t-il une documentation ou un exemple de configuration type pour sécuriser les headers dans une instance Simplicité ?

Merci par avance pour vos recommandations !

Technical information

Instance /health

[Platform]
Status=OK
Version=6.2.10
BuiltOn=2025-05-23 10:17
Git=6.2/db71f45b7b47f1aea2d669dc5b22c5369ec75d92
Encoding=UTF-8
EndpointIP=100.88.67.16
EndpointURL=http://lbc-77449-app-6785f9bc8c-9nwjc:8080
TimeZone=Europe/Paris
SystemDate=2025-08-13 16:38:16

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=https://ldm-app.ext.gke2.int.gcp.renault.com
ActiveSessions=0
TotalUsers=137
EnabledUsers=50
LastLoginDate=2025-08-13 16:15:02

[Server]
ServerInfo=Apache Tomcat/9.0.105
ServerType=WEB
ServerDevMode=false
ServerCompiler=true
ServerActiveSessions=0
ServerSessionTimeout=30
CronStarted=true```

Simplicité logs

---paste the content of the **relevant** server-side logs---

Browser logs

---paste content of the **relevant** browser-side logs---

Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

[david (David AZOULAY)]

Les pages d’erreur renvoient volontairement un minimum d’information mais effectivement une erreur 500, qui correspond à des cas d’exception non prévus, renvoie le message texte brut de l’exception, ce qui reste généralement assez léger comme “information” (à part effectivement de savoir que le serveur est en Java dans certains cas de messages d’erreur)

Le platform hook customErrorResponse existe en tout état de cause (depuis la 6.1, cf. sa release note) si vous voulez avoir un traitement et/ou un format et/ou un contenu spécifique

Le param système HTTP_HEADERS permet d’ajouter ou de customiser des headers statiques HTTP au niveau applicatif:

Cela dit, il est aussi possible et très classique de gérer ce genre de choses au niveau du reverse proxy en amont de Tomcat.

De manière plus générale: avant de réaliser des audits de sécurité, pentests, etc., il est toujours préférable de consulter et d’appliquer tout ou partie des points décrits dans les guidelines de sécurité conformément à vos besoins et à votre contexte d’usage. Et si besoin consultez nous aussi en amont de ces tests afin qu’on vous apporte des conseils plus personnalisés.