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.

I segreti delle chiavi dell'API partner sono conservati in forma irreversibile: la chiave completa viene mostrata una sola volta al momento dell'emissione, mentre nel database resta l'hash SHA-256 della sua parte segreta. Neanche gli access token e i refresh token delle IA collegate sono conservati in chiaro; il collegamento è limitato al livello di accesso scelto e può essere revocato dal proprietario dell'account.

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.

Nelle route del pannello il partner_id viene ricavato dalla sessione firmata; nell'API partner, da una chiave API verificata o da un collegamento OAuth di un'IA. L'identificatore del proprietario non viene preso dal path, dai parametri query o dal body della richiesta. Le chiavi API sono inoltre limitate per scope, periodo di validità e piano; per un'IA collegata, l'insieme dei permessi viene calcolato a ogni richiesta in base al livello scelto dal proprietario.

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 appartengano a questo account. Le query al database sono vincolate dal partner_id, e le chiavi uniche ed esterne composite rifiutano i collegamenti incrociati non validi tra partner. La matrice di autorizzazione nei test richiede uno scenario IDOR esplicito per ogni endpoint con un identificatore di risorsa.

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.

L'indirizzo e-mail di un utente finale non viene conservato da noi: il nome del suo account è derivato in modo irreversibile e non contiene alcun indirizzo. L'e-mail con il codice di accesso la inviamo noi, quindi l'indirizzo passa dalla nostra coda di invio e ne viene rimosso subito dopo l'invio: per riconoscere un utente che torna resta soltanto un'impronta irreversibile, dalla quale l'indirizzo non è ricostruibile. L'unico caso in cui un indirizzo resta comunque registrato lo nominiamo apertamente: al pagamento arriva nel webhook di pagamento ed entra nel registro dei pagamenti con un periodo di conservazione limitato.

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 in autonomia il tuo account insieme a tutti i suoi dati, nella sezione «Impostazioni avanzate», confermando con un codice ricevuto via email (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). Sulle pagine di consenso OAuth le analitiche non vengono caricate in alcun caso: l'URL contiene un identificatore di breve durata della richiesta di collegamento di un'IA, che non deve essere trasmesso a terzi. Non ci sono altri tracker di terze parti: nessun Sentry, PostHog, Mixpanel o pixel pubblicitario. Il backend non ha telemetria di terze parti, e le vetrine per gli utenti finali non sono coperte da analitiche.

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 collegato (lava.top). Riceviamo solo un evento webhook verificato: la sua autenticità viene stabilita con il metodo supportato dal singolo fornitore, prima di qualsiasi modifica al saldo o all'accesso. Non riceviamo il numero completo della carta (PAN) né il CVV. La riconsegna dello stesso evento 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.

Per l'account sono conservati l'email, l'ora dell'ultimo accesso, la modalità dell'interfaccia e le impostazioni; per la fatturazione — il saldo e Telegram, se indicato per le ricariche. Per proteggere l'account, una sessione attiva contiene l'ora di creazione e dell'ultima attività, l'indirizzo IP e lo user-agent. La cronologia dei tentativi di accesso riusciti e falliti, con gli stessi attributi tecnici, è conservata per 90 giorni.

Non esiste uno storico generale dei clic nel pannello. A parte esistono registri mirati: richieste all'API partner — non più delle ultime 500 voci e circa 25 ore; eventi dell'infrastruttura e risultati della diagnostica — non più di 7 giorni; azioni delle IA collegate — per tutta la durata dell'account. Prima di registrare le azioni dell'IA, password, token, chiavi e link di abbonamento vengono rimossi, e le email degli utenti vengono mascherate.

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 generata del server. I codici sono generati da un generatore crittografico; viene conservato solo il loro hash HMAC, e il confronto è in tempo costante. In caso di successo il codice viene eliminato immediatamente, e dopo 5 tentativi errati viene disattivato in anticipo. Il limite di frequenza di emissione è conteggiato sia sull'indirizzo completo sia sulla casella di posta fisica: il cambio di IP, i punti negli indirizzi Gmail e i plus tag non danno un limite separato.

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.

Ogni sessione partner ha un identificatore stabile lato server, che si mantiene quando il token viene rinnovato. La normale disconnessione revoca l'intera sessione corrente, non solo una singola emissione del token. Nella sezione «Sessioni dell’account» sono visibili il dispositivo, l'indirizzo IP, l'ora di accesso e l'ultima attività; ogni sessione può essere chiusa singolarmente. L'azione «Esci ovunque» chiude tutte le sessioni e scollega le IA collegate.

La cronologia degli accessi è conservata per 90 giorni e mostra gli accessi riusciti, i codici errati e scaduti e il superamento del numero di tentativi. In presenza di segni di riutilizzo di un'emissione del token già scambiata, il sistema considera la sessione copiata, chiude tutte le sessioni e i collegamenti delle IA e invia una notifica al proprietario.

Non ci sono token di sessione nel local storage del browser, solo le impostazioni dell'interfaccia. Il token nel cookie HttpOnly viene impostato dal livello server di Next.js; il browser non riceve l'indirizzo interno del backend e lo raggiunge tramite le Server Actions. CORS non consente ad altre origini di leggere le risposte dell'API con dati autorizzati.

Esistono eccezioni intenzionali, gestite dal proprietario stesso: l'export della chiave SSH privata dopo il codice ricevuto via email (SR-4) e una nuova chiave dell'API partner, il cui segreto completo viene mostrato nel browser una sola volta al momento della creazione. Dopodiché non è possibile recuperarlo dal database — lì resta solo l'hash. Il dominio pubblico dell'API è raggiungibile da internet come previsto, ma senza una sessione valida, una chiave API o un token OAuth non restituisce dati protetti.

Gli host pubblici di CreateYourVPN sono serviti in HTTPS con HSTS (max-age due anni, includeSubDomains). Tutti i frontend web che ospitiamo — il sito della piattaforma, il pannello partner e le vetrine dei partner, sia sui nostri sottodomini sia sul dominio proprio del partner — e il dominio API inviano lo stesso insieme di header di sicurezza: una Content-Security-Policy (default-src 'none' sull'API; sui frontend vieta l'inserimento in un iframe e blocca base-uri e form-action), X-Content-Type-Options: nosniff, X-Frame-Options e una Referrer-Policy blindata (no-referrer sull'API; strict-origin-when-cross-origin sui frontend, che inviano anche una Permissions-Policy restrittiva).

È attivo in produzione su tutti questi host ed è verificabile in modo indipendente — con qualsiasi ispettore di header HTTP o un servizio come SSL Labs.

L'app di IA si collega tramite OAuth e non riceve i cookie del tuo pannello. Nella pagina di consenso scegli uno dei tre livelli: solo visualizzazione; visualizzazione e configurazione; eliminazione e concessione dell'accesso. I permessi vengono verificati dal server a ogni chiamata. Le eliminazioni critiche richiedono un ulteriore codice monouso ricevuto via email, e l'intero collegamento può essere revocato nella sezione «IA collegate».

Ogni chiamata a uno strumento finisce in un registro visibile al proprietario, con il risultato e una copia sicura degli argomenti. Password, token, chiavi API, chiavi private e link di abbonamento vengono rimossi prima della registrazione; le email degli utenti vengono mascherate. L'app di IA scelta resta comunque un servizio di terze parti: i dati che le hai consapevolmente chiesto di leggere o modificare vengono trattati anche secondo le regole del suo fornitore.