Sécurité.

Nausika prend la sécurité au sérieux. Cette page est le lieu de référence pour les chercheurs en sécurité, les développeurs de clients IA et les utilisateurs connectés afin de comprendre comment signaler une vulnérabilité, quelle réponse attendre, et ce qui entre ou sort du périmètre. Le contact lisible par machine vit sur /.well-known/security.txt.

Signaler une vulnérabilité

Écrivez à [email protected] avec autant de détail que possible : l'endpoint ou l'outil touché, une recette de reproduction, l'impact observé et si vous estimez que la faille est exploitable en production. Nous accusons réception de chaque rapport sous 2 jours ouvrés.

Nous n'offrons pas de chiffrement PGP pour le moment. Envoyez l'email en clair et, si le rapport contient du matériel sensible à exposer en transit, nous reviendrons coordonner un canal sûr. Nous ne tenons pas de bug bounty rémunéré.

Merci de ne pas tester les vulnérabilités de façon à dégrader le service pour d'autres utilisateurs (déni de service, scan automatisé à fort débit, tentatives d'accès aux données d'autres utilisateurs). Si vous trouvez un problème en utilisant Nausika normalement et le découvrez par accident, c'est bon — signalez-le.

SLA de réponse aux correctifs

La sévérité est évaluée par le mainteneur en dialogue avec l'auteur du rapport, selon des critères de triage standard (raisonnement de type CVSS, focalisé sur l'impact réel pour le modèle de données et la surface de menace de Nausika).

• Critique — exécution de code à distance, contournement d'authentification sur l'endpoint MCP, exfiltration de données cross-tenant, prise de contrôle d'un compte utilisateur existant : patch sous 7 jours ; hotfix déployé sur mcp.nausika.app le jour même si possible.
• Élevée — élévation de privilèges (par exemple utilisateur → admin), fuite de données sensibles (jetons OAuth, cookies de session), injection persistante (stored XSS dans l'admin UI) : patch sous 14 jours.
• Moyenne — déni de service via un appel d'outil unique, divulgation d'informations non personnelles, injection reflected : patch sous 30 jours.
• Faible — déviations des best practices sans exploit démontrable, durcissement, problèmes théoriques : traités dans une release régulière, généralement sous 90 jours.

Divulgation coordonnée

Nous préférons la divulgation coordonnée. Une fois la vulnérabilité confirmée, nous demandons aux auteurs de rapport de retenir la divulgation publique pendant au moins 30 jours à compter de la confirmation (ou jusqu'au déploiement du correctif, selon ce qui arrive en premier), pour que les utilisateurs connectés ne soient pas exposés à de l'exploitation en production avant qu'un correctif soit disponible.

Nous créditerons l'auteur du rapport sur /log au moment de la divulgation, sauf demande contraire. Les rapports anonymes sont les bienvenus et nous les traitons avec la même discipline de triage que les autres.

Versions supportées

Nausika est servie depuis un endpoint public unique sur mcp.nausika.app, déployée depuis la version la plus récente de main. Seule la version actuellement déployée est supportée ; il n'y a pas de branche de maintenance parallèle ni de distribution on-premise. Quand un patch sort, il sort pour tout le monde simultanément.

Les forks self-hosted ou déploiements non officiels sont hors périmètre du SLA ci-dessus — le code source est privé et nous ne le distribuons pas pour le moment.

Hors périmètre

• Vulnérabilités dans les services tiers dont nous dépendons — Railway, Cloudflare, Resend, GitHub OAuth, Google OAuth, Open-Meteo, NOAA, Wikimedia, OpenStreetMap. Signalez directement au fournisseur en amont ; si le problème vient de la façon dont Nausika s'intègre avec eux (par exemple un contrôle redirect-URI manquant de notre côté), alors c'est dans le périmètre.
• Rapports nécessitant un accès physique à l'appareil de l'utilisateur ou un navigateur/OS compromis, sauf si un comportement spécifique de Nausika aggrave la situation.
• Absence de rate-limit sur les endpoints en lecture seule en dessous des limites de service documentées — ils sont traités comme du travail de performance, pas comme des problèmes de sécurité.
• "Findings" de best practices sans impact démontrable (en-têtes de sécurité manquants sur des actifs statiques, divulgation de version sur des bibliothèques tierces que nous patchons déjà à cadence régulière, etc.) — nous les lisons et les considérons, mais ils n'entrent pas dans le SLA ci-dessus.

Ce que nous protégeons, en termes clairs

Deux classes distinctes d'actifs informent notre triage :

• Données utilisateur — votre email de compte, jetons OAuth, profil de bateau, routes enregistrées, notes, favoris, propositions soumises. L'accès cross-tenant à n'importe lequel de ces éléments est traité comme critique.
• Données publiques mais soignées — lieux, attributs, métadonnées d'attribution, images. La falsification qui affecte ce que voient d'autres utilisateurs (par exemple écritures non autorisées sur places) est traitée comme élevée ; l'accès en lecture est ouvert par conception.

Nausika ne stocke pas de données de paiement, de santé, de documents d'identité ou biométriques. Voir Confidentialité pour le modèle de données complet et la politique de rétention.

Posture de durcissement

Pour la transparence : les choses que nous faisons en continu, pas en réaction à des rapports spécifiques.

• OAuth 2.1 avec PKCE pour les clients publics ; jetons bearer opaques stockés sous forme hachée dans notre base de données (aucun secret JWT à laisser fuir).
• Validation anti-SSRF sur chaque fetch depuis des URLs fournies par l'utilisateur (proxy d'images, propositions de lieux).
• Allow-list CORS stricte sur l'endpoint MCP ; exigence same-origin sur les icônes du connecteur selon la spec MCP.
• Accès à la base de données strictement via requêtes paramétrées (tagged template literals) ; aucune SQL concaténée dans le code request-scoped.
• Rétention de 90 jours sur les logs complets de requêtes, 30 jours sur les logs opérationnels, nettoyage automatique via job planifié. Voir Confidentialité.
• Schema-version guard sur le service MCP : le connecteur public refuse de démarrer contre une base de données plus ancienne que le schéma qu'il attend, prévenant les pièges de déploiement périmé.

Maintenance et rétrocompatibilité

Les correctifs de sécurité demandent parfois des changements cassants. Quand cela arrive nous suivons les règles de préavis décrites dans la roadmap : 60 jours de préavis sur /log pour les changements d'interface cassants, à l'exception de l'exploitation active, où nous livrons le correctif immédiatement et expliquons le changement a posteriori.

L'engagement plus large à maintenir Nausika — disponibilité du service, préavis de fermeture, log public — vit dans la roadmap.