Affirmations vérifiables.

Le mot de passe n’est nécessaire que pour ouvrir la première connexion SSH et installer un utilisateur de service. Il est transmis comme authentification SSH pour notre connexion — pas comme argument de script ni variable d’environnement. Notre base de données n’a aucun champ pour lui ; il n’entre pas dans les environnements d’exécution des scripts et n’est pas écrit dans les journaux (les erreurs de connexion ne contiennent que l’adresse et le port, jamais le mot de passe). En mémoire, il est effacé (best-effort) après usage — c’est de la défense en profondeur, pas une garantie : Go peut conserver des copies de la valeur sur le tas jusqu’au garbage collection.

Réserve honnête : cela reste le mot de passe root de ton serveur. Après l’installation, nous désactivons la connexion SSH par mot de passe et en root, mais nous ne changeons pas le mot de passe lui-même — change-le toi-même si tu le souhaites. « Nous ne le stockons pas » est vrai ; « il a cessé d’être un secret » ne l’est pas.

PasswordAuthentication no, PermitRootLogin no, SSH déplacé sur un port non standard (12011 par défaut), fail2ban activé (un bannissement d’une heure après 5 échecs), connexion par clé uniquement. La clé publique est strictement validée avant usage : les retours à la ligne (protection contre l’insertion de clés supplémentaires dans authorized_keys) et les clés syntaxiquement invalides sont rejetés.

Anti-verrouillage : le port 22 n’est pas fermé tant que le noyau n’a pas confirmé (via ss) que le nouveau port SSH écoute effectivement ; la configuration est vérifiée avec sshd -t et la règle sudo avec visudo -cf, toutes deux annulées en cas d’erreur.

Le panneau ne travaille pas avec ton mot de passe mais avec une clé distincte (ed25519) qu’il génère lui-même. La partie privée réside dans la base de données, chiffrée avec AES-256-GCM. La clé de chiffrement (KEK) est stockée séparément de la base de données — dans une variable d’environnement du serveur — et en production elle est obligatoire (il n’y a pas de valeur par défaut non sécurisée : sans KEK, le sous-système cryptographique ne démarre tout simplement pas). Le même chiffrement protège les secrets lourds de la base de données — le mot de passe/jeton/JWT admin de Marzban, les clés Reality, les clés des fournisseurs de paiement, le cache des identifiants proxy, la configuration des sauvegardes.

Le chiffrement ne fait pas que masquer, il authentifie les données (tag d’authentification GCM) : la falsification d’un champ chiffré est détectée au déchiffrement et rejetée. Chaque champ est chiffré avec un nonce aléatoire neuf ; la valeur de la KEK n’atteint jamais les journaux — seulement son identifiant court.

À propos des jetons de capacité : le jeton d’abonnement /sub est un secret au porteur. Pour la recherche, nous ne stockons que son SHA-256, tandis que la copie nécessaire pour réafficher un lien déjà émis est conservée sous forme de texte chiffré AES-GCM. Les anciens enregistrements en clair sont migrés vers le nouveau format, en fail-closed, avant le démarrage du serveur HTTP. L’identifiant d’URL du webhook de paiement est stocké en clair mais n’authentifie pas à lui seul un événement : l’authenticité est vérifiée séparément par une signature HMAC.

Les secrets des clés de l’API partenaire sont stockés de manière irréversible : la clé complète n’est affichée qu’une seule fois, lors de son émission, et la base de données conserve le SHA-256 de sa partie secrète. Les jetons access et refresh des IA connectées ne sont pas non plus stockés en clair ; la connexion est limitée au niveau d’accès choisi et peut être révoquée par le propriétaire du compte.

La clé n’est déchiffrée que sur le serveur, en mémoire ; les API ordinaires ne la renvoient jamais. Le seul moyen de l’obtenir est une fonction d’export délibérée (« récupère ta clé »), protégée par la connexion plus un code e-mail à usage unique (le code n’est stocké que sous forme de hash HMAC, comparé en temps constant, TTL de 10 minutes, 5 tentatives). La clé peut donc être récupérée intentionnellement, mais ne peut pas « fuiter » via une requête normale.

Avant que l’état du serveur ne change et avant toute opération réseau en arrière-plan, les champs contenant la clé de gestion sont remis à zéro de façon synchrone. Si la base de données ne confirme pas l’effacement, l’opération renvoie une erreur et peut être réessayée. La suppression reste « douce » : la ligne et les données de service non secrètes sont préservées. Cela ne signifie pas l’effacement physique des sauvegardes déjà créées — leur cycle de vie est régi par la politique de rétention des sauvegardes.

Dans les routes du panneau, le partner_id est dérivé de la session signée ; dans l’API partenaire, d’une clé API ou d’une connexion OAuth d’IA vérifiées. L’identifiant du propriétaire n’est pas tiré du chemin, des paramètres query ni du corps de la requête. Les clés API sont en outre limitées par leurs scopes, leur durée de validité et l’offre ; pour une IA connectée, l’ensemble des droits est calculé à chaque requête à partir du niveau choisi par le propriétaire.

Avant de renvoyer ou de modifier quoi que ce soit, le système revérifie que le serveur, le cluster, l’inbound, la route, l’utilisateur VPN ou le paiement appartiennent à ce compte. Les requêtes de base de données sont cantonnées par partner_id, et les clés uniques et étrangères composites rejettent les liens croisés invalides entre partenaires. La matrice d’autorisation des tests exige un scénario IDOR explicite pour chaque endpoint comportant un identifiant de ressource.

Réserve honnête : ceci est vérifié par un audit de code tout au long du chemin de la requête, non par un test d’intrusion public — donc SR-16, comme le reste, est ouvert à la réfutation dans le bug bounty.

Pour tout configurer automatiquement (installer Xray+Reality, appliquer la configuration, lire les métriques), le panneau détient un accès administratif complet sur le serveur (équivalent root, via un utilisateur de service avec sudo sans mot de passe). C’est nécessaire pour la gestion, et nous ne l’appelons PAS « limité ».

Ce qui réduit le risque : les secrets ne sont transmis au serveur que via le stdin du processus (pas comme arguments de commande — ils ne sont pas visibles dans la liste des processus) ; après l’installation initiale, chaque connexion de gestion vérifie la clé d’hôte épinglée (pinned) du serveur — un remplacement du serveur « au milieu » est rejeté. Ce que tu contrôles : l’accès repose sur une clé que tu peux révoquer à tout moment — en supprimant le serveur (la clé est remise à zéro) ou simplement en supprimant la VPS chez ton hébergeur (tout disparaît alors).

Les comptes VPN eux-mêmes (VLESS/Reality) sont créés et vivent dans Marzban sur ton serveur maître. De façon centralisée, nous ne stockons que ce qui est nécessaire pour émettre un lien d’abonnement : un jeton d’abonnement aléatoire et un instantané chiffré des identifiants proxy (un cache ; la source de vérité est ton Marzban). Nous n’avons aucun historique de trafic, d’IP ou de visites des utilisateurs.

L'adresse e-mail d'un utilisateur final n'est pas conservée chez nous : le nom de son compte est dérivé de façon irréversible et ne contient aucune adresse. L'e-mail contenant le code de connexion est envoyé par nous, l'adresse passe donc par notre file d'envoi et en est retirée juste après l'envoi — pour reconnaître un utilisateur qui revient, il ne reste qu'une empreinte irréversible, dont l'adresse ne peut pas être reconstituée. Le seul cas où une adresse s'installe malgré tout, nous le nommons directement : au moment du paiement, elle arrive dans le webhook de paiement et entre dans le journal des paiements avec une durée de conservation limitée.

Nous ne conservons ces données de service que le temps nécessaire et les effaçons automatiquement : l'e-mail est retiré de la file d'envoi juste après l'envoi, le corps d'un événement de paiement après traitement, et les événements en attente d'une nouvelle tentative dans une fenêtre de 90 jours. Vous pouvez supprimer vous-même votre compte avec toutes ses données, dans la section « Paramètres avancés », en confirmant avec un code reçu par e-mail (voir le risque 7 pour plus de détails). Nous le divulguons ouvertement plutôt que de le dissimuler derrière des formulations vagues.

La plateforme CreateYourVPN ne reçoit ni ne stocke d’informations sur les sites que tu visites, toi ou tes utilisateurs. Le schéma d’ingestion des métriques est fermé : il n’a physiquement aucun champ pour les IP, les domaines ou les visites — seulement des agrégats (nombre d’uniques en ligne, octets totaux, CPU/RAM/charge). Chaque nœud s’authentifie avec un jeton HMAC lié à son propre identifiant et ne peut écrire des métriques que pour lui-même. L’équilibreur de charge sur le nœud (HAProxy) fonctionne comme un routeur TCP par SNI et ne déchiffre pas le trafic. Sur le serveur lui-même, les journaux système sont conservés pendant environ une heure au maximum et ne sont pas transmis à syslog.

Au-delà du niveau de la plateforme, les serveurs ne tiennent pas non plus de journal de visites : la journalisation des accès de Xray est forcée à l’arrêt à chaque envoi de configuration (la plateforme règle log.access sur none), de sorte que le proxy de bordure n’enregistre pas les adresses auxquelles les utilisateurs se connectent. C’est appliqué dans le code et déployé sur l’ensemble du parc.

Pour comprendre comment le site et le panneau sont utilisés, nous employons Google Analytics (la bannière de cookies avertit de la collecte de cookies et de statistiques ; les détails sont dans la Politique de confidentialité). Sur les pages de consentement OAuth, le chargement de l’analytique est désactivé de force : l’URL contient un identifiant de courte durée de la demande de connexion d’IA, qui ne doit pas être transmis à un tiers. Il n’y a pas d’autres traqueurs tiers : pas de Sentry, PostHog, Mixpanel, ni de pixels publicitaires. Le backend n’a aucune télémétrie tierce, et les vitrines destinées aux utilisateurs finaux ne sont pas couvertes par l’analytique.

Réserve : GA reçoit ton IP (du côté de Google) et les adresses des pages du panneau consultées ; les URL du panneau ne contiennent qu’un identifiant de cluster, pas d’e-mail.

Le paiement et toutes les données de carte sont traités du côté du fournisseur connecté (lava.top). Nous ne recevons qu’un événement webhook vérifié : son authenticité est établie selon la méthode prise en charge par le fournisseur concerné, avant toute modification du solde ou de l’accès. Nous ne recevons pas le numéro de carte complet (PAN) ni le CVV. La relivraison du même événement ne provoque pas de double octroi : les événements sont dédupliqués.

Réserve : le fournisseur peut inclure dans le corps du webhook des métadonnées de carte (réseau et 4 derniers chiffres) ainsi que le nom et l’e-mail du payeur. Le corps original est nécessaire au worker jusqu’à la fin du traitement ; après un traitement réussi, il est supprimé avec l’indice de l’e-mail. Les événements en attente de nouvelle tentative ou de revue manuelle ne conservent le corps original que jusqu’à la fin de la fenêtre de rétention (90 jours sans activité), après quoi les métadonnées de la carte et l’e-mail du payeur sont effacés automatiquement. « Il n’y a pas de numéro de carte complet » est vrai, mais c’est une propriété des fournisseurs (nous ne filtrons pas nous-mêmes le corps) ; « nous ne voyons rien du tout sur la carte » ne l’est pas.

Pour le compte, nous stockons l’e-mail, l’heure de la dernière connexion, le mode de l’interface et les réglages ; pour la facturation — le solde et Telegram, s’il est indiqué pour les recharges. Pour protéger le compte, une session active contient l’heure de création et de dernière activité, l’adresse IP et le user-agent. L’historique des tentatives de connexion réussies et échouées, avec les mêmes caractéristiques techniques, est conservé 90 jours.

Il n’existe pas d’historique général des clics dans le panneau. Des journaux ciblés existent séparément : requêtes à l’API partenaire — au plus les 500 dernières entrées et environ 25 heures ; événements d’infrastructure et résultats de diagnostic — au plus 7 jours ; actions des IA connectées — conservées avec le compte. Avant l’enregistrement des actions de l’IA, les mots de passe, jetons, clés et liens d’abonnement sont supprimés, et les e-mails des utilisateurs sont masqués.

Le pare-feu refuse les entrées par défaut. Ouverts vers l’extérieur : 443 (VPN, Xray+Reality), SSH sur un port non standard (12011 par défaut) et — sur le serveur maître — le port du panneau admin de Marzban, uniquement pour les IP du control-plane. Le port 80 n’est ouvert séparément qu’en mode Let's Encrypt pour HTTP-01. Le port 22 est fermé après le déplacement de SSH.

Les ports de gestion du nœud ne sont ouverts qu’à l’IP du serveur maître, pas vers l’extérieur (un échec de cette liaison interrompt l’installation). Si le pare-feu ne devient pas actif, l’installation échoue. L’echo ICMP n’est limité que pour IPv4 ; nous ne promettons pas que le serveur soit « invisible », et l’ICMP IPv6 est préservé pour qu’IPv6 fonctionne correctement.

Les unattended upgrades installent automatiquement les mises à jour des paquets de sécurité. Réserve : le redémarrage automatique est délibérément désactivé (afin qu’un noyau non vérifié ne redémarre pas de lui-même) — ce qui signifie que les correctifs nécessitant un redémarrage (noyau, parfois OpenSSH) ne s’appliquent qu’après un redémarrage manuel ou planifié. L’« auto-patching » est vrai pour l’espace utilisateur, pas pour ce qui nécessite un redémarrage.

Nous ne prétendons PAS que le serveur est « invisible » ou « impossible à scanner ». Le port 443 est ouvert et répond à une connexion TCP comme n’importe quel serveur web. La propriété « lors d’une connexion incorrecte, il ressemble à un site web ordinaire sans rapport » est fournie par le protocole Reality au sein de Xray — un composant distinct que nous ne transformons pas en absolu.

La connexion du partenaire se fait par un code à usage unique de 6 chiffres envoyé par e-mail. Il n’y a pas de mot de passe de compte. Cela ne s’applique pas aux identifiants internes des composants gérés, comme le mot de passe admin généré du serveur. Les codes sont générés par un générateur cryptographique ; seul leur hash HMAC est stocké, et la comparaison se fait en temps constant. En cas de succès, le code est supprimé immédiatement, et après 5 tentatives erronées, il est neutralisé par anticipation. La limite de fréquence d’émission est comptée à la fois par adresse complète et par boîte aux lettres réelle : un changement d’IP, les points dans une adresse Gmail et les plus-tags ne donnent pas droit à une limite distincte.

Le jeton de session réside dans un cookie HttpOnly et Secure (le JS ne peut pas le lire), vérifié sur le backend (pas seulement à l’edge). Le délai d’inactivité et la déconnexion automatique en cas d’inactivité sont implémentés côté client, pas côté serveur. Le jeton est signé avec HS256 ; à la vérification, nous rejetons strictement tout autre algorithme (y compris « none ») — la classique attaque par échange d’algorithme ne passe pas. Le jeton de la vitrine et le jeton du panneau partenaire sont séparés par audience : un jeton d’utilisateur final ne peut techniquement pas atteindre l’API partenaire (et inversement). Un partenaire supprimé est rejeté même avec un jeton valide.

Chaque session partenaire possède un identifiant stable côté serveur, conservé lors du renouvellement du jeton. Une déconnexion normale révoque toute la session en cours, et pas seulement une émission de jeton. La section « Sessions du compte » affiche l’appareil, l’adresse IP, l’heure de connexion et la dernière activité ; chaque session peut être fermée individuellement. L’action « Se déconnecter partout » met fin à toutes les sessions et déconnecte les IA connectées.

L’historique des connexions est conservé 90 jours et affiche les connexions réussies, les codes erronés et expirés, ainsi que les dépassements du nombre de tentatives. En cas de signes de réutilisation d’une émission de jeton déjà échangée, le système considère la session comme copiée, met fin à toutes les sessions et connexions d’IA et envoie une notification au propriétaire.

Il n’y a aucun jeton de session dans le local storage du navigateur, seulement les réglages d’interface. Le jeton est placé dans un cookie HttpOnly par la couche serveur de Next.js ; le navigateur ne reçoit pas l’adresse interne du backend et s’adresse à lui via les Server Actions. CORS n’autorise pas d’autres origines à lire les réponses de l’API contenant des données autorisées.

Il existe des exceptions délibérées, contrôlées par le propriétaire lui-même : l’export de la clé SSH privée après saisie d’un code reçu par e-mail (SR-4) et une nouvelle clé de l’API partenaire, dont le secret complet est affiché une seule fois dans le navigateur lors de sa création. Ensuite, ce secret ne peut plus être récupéré depuis la base de données — seul un hash y reste. Le domaine public de l’API est accessible depuis Internet par conception, mais sans session valide, clé API ou jeton OAuth, il ne renvoie aucune donnée protégée.

Les hôtes publics de CreateYourVPN sont servis en HTTPS avec HSTS (max-age de deux ans, includeSubDomains). Tous les frontends web que nous hébergeons — le site de la plateforme, le panneau partenaire et les vitrines des partenaires, que ce soit sur nos sous-domaines ou sur le domaine propre du partenaire — ainsi que le domaine de l'API envoient le même ensemble d'en-têtes de sécurité : une Content-Security-Policy (default-src 'none' sur l'API ; sur les frontends, elle interdit l'insertion dans une iframe et verrouille base-uri et form-action), X-Content-Type-Options: nosniff, X-Frame-Options et une Referrer-Policy verrouillée (no-referrer sur l'API ; strict-origin-when-cross-origin sur les frontends, qui envoient également une Permissions-Policy restrictive).

C'est en production sur tous ces hôtes et vérifiable de façon indépendante — avec n'importe quel inspecteur d'en-têtes HTTP ou un service comme SSL Labs.

Une application d’IA se connecte via OAuth et ne reçoit pas les cookies de votre panneau. Sur la page de consentement, vous choisissez l’un des trois niveaux : consultation seule ; consultation et configuration ; suppression et octroi d’accès. Les droits sont vérifiés par le serveur à chaque appel. Les suppressions critiques exigent en plus un code à usage unique reçu par e-mail, et l’ensemble de la connexion peut être révoqué dans la section « IA connectées ».

Chaque appel d’outil est consigné dans un journal visible par le propriétaire, avec son résultat et une copie sûre des arguments. Les mots de passe, jetons, clés API, clés privées et liens d’abonnement sont retirés avant l’enregistrement ; les e-mails des utilisateurs sont masqués. L’application d’IA choisie reste toutefois un service tiers : les données que vous lui avez sciemment demandé de lire ou de modifier sont également traitées selon les règles de son fournisseur.