Politique de divulgation des vulnérabilités

Version 1.1 · Date d'entrée en vigueur : 14 octobre 2026 · Dernière mise à jour : 11 octobre 2026

Traduction fournie à titre d'information et de commodité. Seule la version anglaise de ce document a force juridique ; en cas de divergence, d'ambiguïté ou de contradiction, le texte anglais prévaut.

Nous accueillons favorablement les signalements des chercheurs en sécurité. Si vous pensez avoir découvert une vulnérabilité dans LiKE, merci de nous en informer.

Comment signaler

Envoyez un e-mail à [email protected], un e-mail par problème, en anglais ou en russe, comprenant :

une description du problème et de son impact ;
les étapes pour le reproduire (une courte vidéo ou des captures d'écran sont utiles) ;
l'URL ou l'endpoint concerné ;
votre nom ou pseudonyme, si vous souhaitez figurer sur cette page.

Veuillez ne pas inclure de données personnelles d'autres personnes dans votre signalement.

Nous examinons tous les signalements que nous recevons. Nous pouvons vous contacter si nous avons besoin d'informations supplémentaires.

Ce qui nous importe le plus

l'accès aux données de l'espace de travail ou de l'organisation d'un autre client ;
le contournement de l'authentification ou la prise de contrôle du compte d'un autre utilisateur ;
les failles d'autorisation dans notre API ;
le fait d'amener nos fonctionnalités d'IA à révéler des données d'un espace de travail auquel vous n'avez pas accès.

Périmètre

Dans le périmètre : lynkora.pro et ses sous-domaines exploités par Lynkora, y compris les espaces de travail des clients (*.lynkora.pro), ainsi que notre API.

Hors périmètre : les services tiers que nous utilisons (par exemple, les prestataires de paiement en ligne et d'envoi d'e-mails), ainsi que tout système non exploité par Lynkora.

Règles

Effectuez vos tests uniquement avec des comptes et des espaces de travail qui vous appartiennent. Créez votre propre compte sur lynkora.pro pour vos tests.
Pour nous aider à distinguer vos tests de l'activité réelle, veuillez vous inscrire avec une balise +security dans votre adresse e-mail si votre fournisseur le permet (par exemple, [email protected] — les e-mails arrivent toujours dans votre boîte de réception habituelle) et inclure « test » dans le nom de votre espace de travail. Veuillez supprimer vos comptes de test une fois vos tests terminés.
N'accédez pas aux données appartenant à d'autres personnes, et ne les modifiez ni ne les supprimez. Si vous accédez par accident aux données de quelqu'un d'autre, arrêtez-vous, n'en conservez pas de copie et informez-nous.
N'effectuez pas d'attaques par force brute sur les mots de passe, n'utilisez pas d'identifiants divulgués et ne créez pas plus de quelques comptes.
Lorsque vous testez les limites de débit (rate limits), n'envoyez pas plus de 10 requêtes. C'est suffisant pour démontrer le problème.
N'effectuez pas de tests de déni de service ou de charge, de scans automatisés à volume élevé, d'ingénierie sociale, de phishing ni d'attaques physiques.
N'effectuez pas de paiements réels ou frauduleux.
Ne divulguez pas publiquement le problème avant que nous ayons publié un correctif (période de non-divulgation de 90 jours).

Signalements non acceptés

Nous n'acceptons pas les signalements portant sur :

des problèmes déjà connus de nous ou signalés précédemment ;
des problèmes théoriques sans preuve de concept ;
des résultats de scanners automatisés sans impact démontré ;
l'absence d'en-têtes de sécurité ou d'attributs de cookies sans attaque fonctionnelle ;
le clickjacking sur des pages sans actions sensibles ;
la configuration SPF, DKIM ou DMARC ;
le déni de service, les tests de charge ou les limites de débit sur des endpoints autres que ceux d'authentification ;
l'ingénierie sociale ou les attaques physiques ;
l'énumération de comptes ou d'adresses e-mail ;
la politique de mots de passe (longueur ou complexité) ;
la divulgation de versions logicielles, le banner grabbing ou les pages d'erreur détaillées sans données sensibles ;
des problèmes nécessitant un appareil compromis, une position de man-in-the-middle ou une interaction improbable de l'utilisateur ;
le self-XSS, le CSRF de déconnexion ou le CSRF sur des formulaires sans actions sensibles ;
les moyens de dépasser les limites d'un forfait (par exemple, les limites de tokens d'IA ou de sièges) sans accès aux données d'autres clients ;
le comportement des modèles d'IA, tel que les jailbreaks, la prompt injection ou les réponses inexactes, sauf s'il expose des données d'un espace de travail auquel vous n'avez pas accès.

Récompenses

Nous ne gérons pas de programme de bug bounty rémunéré et ne payons pas pour les signalements. Avec votre consentement, nous pouvons mentionner votre nom sur cette page pour des découvertes valides et dans le périmètre, une fois celles-ci corrigées.

Bonne foi

Nous considérons comme autorisées les recherches menées de bonne foi et conformément à ces règles.

Remerciements

Nous remercions les chercheurs suivants d'avoir signalé des problèmes de manière responsable :

(aucun pour l'instant)

---

Nous pouvons mettre à jour cette politique de temps à autre.