Bonjour,
Je prépare la mise en production d’un client mobile maison connecté à l’API REST, et en auditant l’instance je suis tombé sur un point de configuration du bus d’événements (SockJS, /eventbus/…) que j’aimerais clarifier avec vous.
En clair, le comportement observé :
Quand un navigateur demande au bus « est-ce que j’ai le droit de te parler depuis ce site ? », le serveur répond « oui, quel que soit le site », et en plus « tu peux m’envoyer les identifiants de session ». Concrètement, l’en-tête Access-Control-Allow-Origin recopie l’origine de la requête, quelle qu’elle soit, avec Access-Control-Allow-Credentials: true (visible sur GET /eventbus/info comme sur le préflight OPTIONS). Les endpoints /api et le webmail, eux, n’émettent aucun en-tête CORS.
Pourquoi ça m’interpelle :
Normalement, autoriser les identifiants (Allow-Credentials: true) doit aller de pair avec une liste blanche d’origines précises, jamais avec « n’importe quelle origine ». En l’état, un site tiers visité par un utilisateur connecté pourrait tenter des requêtes authentifiées vers le bus depuis son navigateur. C’est la classe de problème décrite par CWE‑1385 (Missing Origin Validation in WebSockets).
Ce que je pense être la cause :
Ça ressemble au CORS par défaut de SockJS/Vert.x (io.vertx.ext.web.handler.sockjs.impl.BaseTransport#setCORS), qui recopie l’origine quand aucune liste blanche n’est configurée — donc un comportement du framework, pas propre à mon installation.
Mes questions :
- Existe-t-il une option supportée pour restreindre l’origine autorisée du bus à une liste de domaines, plutôt que de recopier n’importe laquelle ?
- Est-ce considéré comme sans risque parce que la connexion du bus s’authentifie par clé d’API à l’enregistrement (et non par cookie), ou recommandez-vous un durcissement ?
- Est-il prévu de verrouiller ce CORS par défaut dans une version à venir ?
En attendant, je l’ai restreint au niveau de mon reverse proxy (origine limitée à mon domaine). Merci d’avance pour vos retours.