Affermazioni verificabili.

La password serve solo ad aprire la prima connessione SSH e a installare un utente di servizio. Viene passata come autenticazione SSH per la nostra connessione — non come argomento di uno script o variabile d'ambiente. Il nostro database non ha un campo per essa; non entra negli ambienti di esecuzione degli script e non viene scritta nei log (gli errori di connessione contengono solo l'indirizzo e la porta, mai la password). In memoria viene cancellata (best-effort) dopo l'uso — è difesa in profondità, non una garanzia: Go potrebbe mantenere copie del valore nell'heap fino alla garbage collection.

Riserva onesta: questa resta la password di root sul tuo server. Dopo l'installazione disabilitiamo l'accesso via SSH con password e come root, ma non cambiamo la password stessa — cambiala tu se vuoi. «Non la conserviamo» è vero; «ha smesso di essere un segreto» no.

PasswordAuthentication no, PermitRootLogin no, SSH spostato su una porta non standard (12011 per impostazione predefinita), fail2ban attivo (ban di un'ora dopo 5 tentativi falliti), accesso solo con chiave. La chiave pubblica viene validata rigorosamente prima dell'uso: vengono rifiutati i ritorni a capo (protezione contro l'inserimento di chiavi extra in authorized_keys) e le chiavi sintatticamente non valide.

Anti-lockout: la porta 22 non viene chiusa finché il kernel non conferma (tramite ss) che la nuova porta SSH è effettivamente in ascolto; la configurazione viene verificata con sshd -t e la regola sudo con visudo -cf, entrambe annullate in caso di errore.

Il pannello non lavora con la tua password ma con una chiave separata (ed25519) che genera da sé. La parte privata risiede nel database cifrata con AES-256-GCM. La chiave di cifratura (KEK) è conservata separatamente dal database — in una variabile d'ambiente del server — e in produzione è obbligatoria (non esiste un valore predefinito insicuro: senza una KEK il sottosistema crittografico semplicemente non si avvia). La stessa cifratura protegge i segreti pesanti nel database — password/token/JWT dell'admin Marzban, chiavi Reality, chiavi dei fornitori di pagamento, la cache delle credenziali proxy, la configurazione dei backup.

La cifratura non si limita a nascondere ma autentica i dati (auth tag GCM): la manomissione di un campo cifrato viene rilevata alla decifratura e rifiutata. Ogni campo è cifrato con un nonce casuale nuovo; il valore della KEK non raggiunge mai i log — solo il suo id breve.

Sui token di autorizzazione: il token di sottoscrizione /sub è un segreto al portatore. Per la ricerca conserviamo solo il suo SHA-256, mentre la copia necessaria a rimostrare un link già emesso è mantenuta come testo cifrato AES-GCM. I vecchi record in chiaro vengono migrati al nuovo formato, in modalità fail-closed, prima che il server HTTP si avvii. L'identificatore URL del webhook di pagamento è conservato in chiaro ma di per sé non autentica un evento: l'autenticità è verificata separatamente da una firma HMAC.

La chiave viene decifrata solo sul server, in memoria; le API ordinarie non la restituiscono mai. L'unico modo per ottenerla è una funzione di export deliberata («prendi la tua chiave»), protetta dall'accesso più un codice email monouso (il codice è conservato solo come hash HMAC, confrontato in tempo costante, TTL di 10 minuti, 5 tentativi). Quindi la chiave può essere recuperata intenzionalmente, ma non può «trapelare» attraverso una richiesta normale.

Prima che lo stato del server cambi e prima di qualsiasi operazione di rete in background, i campi che contengono la chiave di gestione vengono azzerati in modo sincrono. Se il database non conferma la cancellazione, l'operazione restituisce un errore e può essere ritentata. L'eliminazione resta «soft»: la riga e i dati di servizio non segreti vengono preservati. Questo non significa la cancellazione fisica dei backup già creati — il loro ciclo di vita è regolato dalla policy di retention dei backup.

Le route partner sottoposte ad audit autorizzano tramite partner_id, che il server ricava dal token di login firmato — non da ciò che il client ha inviato nel path o nel body. Prima di restituire o modificare qualsiasi cosa, il sistema riverifica che il server, il cluster, l'inbound, la route, l'utente VPN o il pagamento richiesti appartengano al tuo account; le relative query al database sono vincolate dal tuo partner_id e lo schema (chiavi uniche composite più chiavi esterne composite) rifiuta i collegamenti incrociati non validi tra partner. L'isolamento è a più livelli: applicazione, riverifica nello usecase, un filtro partner_id e lo schema.

Riserva onesta: questo è verificato tramite un audit del codice lungo tutto il percorso della richiesta, non da un penetration test pubblico — quindi SR-16, come il resto, è aperto alla confutazione nel bug bounty.

Per configurare tutto automaticamente (installare Xray+Reality, applicare la configurazione, leggere le metriche) il pannello detiene l'accesso amministrativo completo sul server (equivalente a root, tramite un utente di servizio con sudo senza password). È necessario per la gestione, e NON lo chiamiamo «limitato».

Cosa riduce il rischio: i segreti vengono passati al server solo tramite lo stdin del processo (non come argomenti da riga di comando — non sono visibili nell'elenco dei processi); dopo l'installazione iniziale, ogni connessione di gestione verifica la host key fissata (pinned) del server — uno scambio del server «nel mezzo» viene rifiutato. Cosa controlli tu: l'accesso poggia su una chiave che puoi revocare in qualsiasi momento — eliminando il server (la chiave viene azzerata) o semplicemente eliminando la VPS presso il tuo host (allora sparisce tutto).

Gli account VPN stessi (VLESS/Reality) vengono creati e risiedono in Marzban sul tuo server master. Centralmente conserviamo solo ciò che serve a emettere un link di sottoscrizione: un token di sottoscrizione casuale e uno snapshot cifrato delle credenziali proxy (una cache; la fonte di verità è il tuo Marzban). Non abbiamo alcuno storico di traffico, IP o visite degli utenti.

Ecco un elenco onesto dei punti in cui l'email di un utente finale passa effettivamente attraverso il nostro database centrale: l'email con il codice di accesso la inviamo noi, quindi l'indirizzo passa attraverso la nostra coda di invio (per qualsiasi accesso alla vetrina, incluso quello gratuito); al pagamento, l'email dell'acquirente arriva nel webhook di pagamento ed entra nel registro dei pagamenti; al collegamento di Telegram, l'email viene salvata nel profilo. Questi sono gli unici punti di contatto — di servizio e per necessità; nessuno di essi riguarda il traffico o il comportamento degli utenti.

Conserviamo questi dati di servizio solo per il tempo necessario e li cancelliamo automaticamente: l'email viene rimossa dalla coda di invio subito dopo l'invio, il corpo di un evento di pagamento dopo l'elaborazione, e gli eventi in attesa di un nuovo tentativo entro una finestra di 90 giorni. Puoi eliminare il tuo account insieme ai dati associati contattando l'assistenza (per i dettagli, vedi il rischio 7). Lo dichiariamo apertamente anziché nasconderlo dietro formulazioni vaghe.

La piattaforma CreateYourVPN non riceve né conserva informazioni su quali siti visiti tu o i tuoi utenti. Lo schema di ingest delle metriche è chiuso: fisicamente non ha campi per IP, domini o visite — solo aggregati (conteggio unici online, byte totali, CPU/RAM/carico). Ogni nodo si autentica con un token HMAC legato al proprio id e può scrivere metriche solo per sé stesso. Il bilanciatore sul nodo (HAProxy) funziona come router TCP basato su SNI e non decifra il traffico. Sul server stesso, i journal di sistema vengono conservati per non più di circa un'ora e non vengono inoltrati a syslog.

Oltre al livello della piattaforma, nemmeno i server tengono un registro delle visite: il logging degli accessi di Xray viene forzatamente disattivato a ogni invio della configurazione (la piattaforma imposta log.access su none), quindi il proxy di bordo non registra a quali indirizzi si connettono gli utenti. Questo è imposto nel codice e distribuito all'intera flotta.

Per capire come vengono usati il sito e il pannello utilizziamo Google Analytics (il banner dei cookie avvisa della raccolta di cookie e statistiche; i dettagli sono nell'Informativa sulla privacy). Non ci sono altri tracker di terze parti: nessun Sentry, PostHog, Mixpanel o pixel pubblicitario (verificato cercando in entrambi i frontend). Il backend non ha alcuna telemetria di terze parti. La vetrina per l'utente finale non è affatto coperta da analitiche — nessun GA, nessun tracker (verificabile dai suoi sorgenti).

Riserva: GA riceve il tuo IP (dal lato di Google) e gli indirizzi delle pagine del pannello visitate; gli URL del pannello contengono solo un identificatore di cluster, non un'email.

Il pagamento e tutti i dati della carta sono gestiti dal lato del fornitore (Tribute / Lemon Squeezy). Riceviamo solo un webhook firmato (HMAC-SHA256, confronto in tempo costante, verificato prima che il body venga analizzato e prima di qualsiasi scrittura nel database: senza conoscere il segreto, un evento non supera la verifica). Non riceviamo il numero completo della carta (PAN) né il CVV. La riconsegna dello stesso webhook (retry del fornitore) non provoca una doppia concessione — gli eventi sono deduplicati.

Riserva: il fornitore può includere nel body del webhook metadati della carta (circuito e ultime 4 cifre) e il nome e l'email del pagante. Il body originale serve al worker fino al completamento dell'elaborazione; dopo un'elaborazione riuscita viene eliminato insieme all'indizio dell'email. Gli eventi in attesa di retry o di revisione manuale mantengono il body originale solo fino alla fine della finestra di retention (90 giorni senza attività), dopodiché i metadati della carta e l'email del pagante vengono cancellati automaticamente. «Non c'è il numero completo della carta» è vero, ma è una proprietà dei fornitori (non filtriamo noi stessi il body); «non vediamo assolutamente nulla della carta» no.

Email (necessaria per l'accesso), ora dell'ultimo accesso, modalità dell'interfaccia; per la fatturazione — saldo e Telegram (per le ricariche). L'IP del partner non è conservato nel database, e non teniamo alcuno storico di clic o azioni nel pannello (a parte un breve access log in caso di errori).

Il firewall nega il traffico in ingresso per impostazione predefinita. Aperti verso l'esterno: 443 (VPN, Xray+Reality), SSH su una porta non standard (12011 per impostazione predefinita) e — sul server master — la porta del pannello admin di Marzban, solo per gli IP del control-plane. La porta 80 viene aperta separatamente solo in modalità Let's Encrypt per HTTP-01. La porta 22 viene chiusa dopo lo spostamento di SSH.

Le porte di gestione del nodo sono aperte solo all'IP del server master, non verso l'esterno (un fallimento di questo binding interrompe l'installazione). Se il firewall non diventa attivo, l'installazione fallisce. L'echo ICMP è limitato solo per IPv4; non promettiamo che il server sia «invisibile», e l'ICMP IPv6 è preservato affinché IPv6 funzioni correttamente.

Gli unattended upgrades installano automaticamente gli aggiornamenti dei pacchetti di sicurezza. Riserva: il riavvio automatico è deliberatamente disabilitato (così un kernel non verificato non si riavvia da solo) — il che significa che le correzioni che richiedono un riavvio (kernel, a volte OpenSSH) si applicano solo dopo un riavvio manuale o pianificato. L'«auto-patching» è vero per lo userland, non per ciò che richiede un riavvio.

NON affermiamo che il server sia «invisibile» o «non scansionabile». La porta 443 è aperta e risponde a una connessione TCP come qualsiasi server web. La proprietà «con una connessione errata appare come un comune sito web non correlato» è fornita dal protocollo Reality all'interno di Xray — un componente separato che non trasformiamo in un assoluto.

L'accesso del partner avviene tramite un codice monouso di 6 cifre inviato via email. Non esiste una password dell'account. Questo non vale per le credenziali interne dei componenti gestiti, come la password admin di Marzban generata. I codici sono generati da un generatore crittografico; viene conservato solo il loro hash HMAC, e il confronto è in tempo costante. Il codice è monouso: in caso di successo viene eliminato immediatamente (nessun replay); dopo 5 tentativi errati viene disattivato in anticipo. Il limite di frequenza di emissione è conteggiato per email, non per IP — non può essere aggirato cambiando indirizzo.

Il token di sessione risiede in un cookie HttpOnly e Secure (JS non può leggerlo), verificato sul backend (non solo all'edge). L'idle timeout e il logout automatico per inattività sono implementati sul client, non sul server. Il token è firmato con HS256; in fase di verifica rifiutiamo rigorosamente qualsiasi altro algoritmo (incluso «none») — il classico attacco di scambio di algoritmo non passa. Il token della vetrina e il token del pannello partner sono separati per audience: un token di utente finale tecnicamente non può raggiungere l'API partner (e viceversa). Un partner eliminato viene rifiutato anche con un token valido.

Riserva: la revoca è implementata verificando che il partner esista a ogni richiesta, non invalidando il token stesso; il logout elimina il cookie, ma un token emesso resta crittograficamente valido fino alla scadenza (fino a un'ora). Non esiste ancora una lista di revoca centralizzata (una semplificazione consapevole dell'MVP).

Non ci sono token nel local storage del browser (solo le impostazioni dell'interfaccia); nessun segreto né l'indirizzo dell'API finiscono nel bundle client. Solo il server (Next.js) inserisce il token in un cookie HttpOnly. Il browser comunica con il core solo tramite il server (Server Actions): il frontend non chiama l'API direttamente dal browser, e CORS non consente al browser di leggere le risposte dell'API da altre origini.

Chiarimento al posto di un ex assoluto: il dominio dell'API è di per sé un host pubblico — tecnicamente puoi aprirlo da un browser, ma senza una sessione non restituisce alcun dato autorizzato.

I domini pubblici di CreateYourVPN sono serviti tramite HTTPS con HSTS (max-age due anni, includeSubDomains). Sia il frontend web sia il dominio dell'API inviano un insieme rigoroso di intestazioni di sicurezza: una Content-Security-Policy restrittiva, X-Content-Type-Options: nosniff, X-Frame-Options e una Referrer-Policy blindata (no-referrer sull'API; strict-origin-when-cross-origin sul frontend, che invia anche una Permissions-Policy restrittiva).

Questo è attivo in produzione su entrambi i domini ed è verificabile in modo indipendente — con qualsiasi ispettore di intestazioni HTTP o un servizio come SSL Labs.