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.

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.

Les routes partenaires auditées autorisent par partner_id, que le serveur dérive du jeton de connexion signé — et non de ce que le client a envoyé dans le chemin ou le corps. 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 demandés appartiennent à ton compte ; les requêtes de base de données correspondantes sont cantonnées par ton partner_id, et le schéma (clés uniques composites plus clés étrangères composites) rejette les liens croisés invalides entre partenaires. L’isolation est en couches : application, revérification dans le usecase, un filtre partner_id, et le schéma.

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.

Voici une liste honnête des endroits où l'e-mail d'un utilisateur final transite effectivement par notre base de données centrale : l'e-mail contenant le code de connexion est envoyé par nous, l'adresse passe donc par notre file d'envoi (pour toute connexion à la boutique, y compris gratuite) ; au moment du paiement, l'e-mail de l'acheteur arrive dans le webhook de paiement et entre dans le journal des paiements ; lors de la liaison de Telegram, l'e-mail est enregistré dans le profil. Ce sont les seuls points de contact — utilitaires et par nécessité ; aucun d'eux ne concerne le trafic ni le comportement des utilisateurs.

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 votre compte ainsi que les données associées en contactant le support (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é). Il n’y a pas d’autres traqueurs tiers : pas de Sentry, PostHog, Mixpanel, ni de pixels publicitaires (vérifié en cherchant dans les deux frontends). Le backend n’a aucune télémétrie tierce. La vitrine destinée à l’utilisateur final n’est couverte par aucune analytique — pas de GA, pas de traqueurs (vérifiable depuis ses sources).

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 (Tribute / Lemon Squeezy). Nous ne recevons qu’un webhook signé (HMAC-SHA256, comparaison en temps constant, vérifié avant que le corps ne soit analysé et avant toute écriture en base de données : sans connaître le secret, un événement échoue à la vérification). Nous ne recevons pas le numéro de carte complet (PAN) ni le CVV. La relivraison du même webhook (nouvelles tentatives du fournisseur) 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.

E-mail (nécessaire pour la connexion), heure de la dernière connexion, mode de l’interface ; pour la facturation — solde et Telegram (pour les recharges). L’IP du partenaire n’est pas stockée dans la base de données, et nous ne conservons aucun historique de clics ou d’actions dans le panneau (hormis un court journal d’accès en cas d’erreurs).

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 de Marzban généré. 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. Le code est à usage unique : en cas de succès, il est supprimé immédiatement (pas de rejeu) ; après 5 tentatives erronées, il est neutralisé par anticipation. La limite de fréquence d’émission est comptée par e-mail, pas par IP — elle ne peut pas être contournée en changeant d’adresse.

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.

Réserve : la révocation est implémentée en vérifiant que le partenaire existe à chaque requête, non en invalidant le jeton lui-même ; la déconnexion supprime le cookie, mais un jeton émis reste cryptographiquement valide jusqu’à son expiration (jusqu’à une heure). Il n’y a pas encore de liste de révocation centralisée (une simplification consciente de MVP).

Il n’y a aucun jeton dans le local storage du navigateur (seulement les réglages d’interface) ; aucun secret ni l’adresse de l’API ne se retrouvent dans le bundle client. Seul le serveur (Next.js) place le jeton dans un cookie HttpOnly. Le navigateur communique avec le cœur uniquement via le serveur (Server Actions) : le frontend n’appelle pas l’API directement depuis le navigateur, et CORS n’autorise pas le navigateur à lire les réponses de l’API depuis d’autres origines.

Clarification à la place d’un ancien absolu : le domaine de l’API est lui-même un hôte public — techniquement, tu peux l’ouvrir depuis un navigateur, mais sans session, il ne renvoie aucune donnée autorisée.

Les domaines publics de CreateYourVPN sont servis via HTTPS avec HSTS (max-age de deux ans, includeSubDomains). Le frontend web comme le domaine de l'API envoient un ensemble strict d'en-têtes de sécurité : une Content-Security-Policy restrictive, 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 le frontend, qui envoie aussi une Permissions-Policy restrictive).

Cela fonctionne en production sur les deux domaines et est vérifiable de manière indépendante — avec n'importe quel inspecteur d'en-têtes HTTP ou un service comme SSL Labs.