Sicurezza

Foto, video e altri contenuti caricati su Sweetly non passano attraverso i nostri server applicativi durante il caricamento. Il tuo browser o la tua app richiede al backend un URL di caricamento firmato e a scadenza breve, e carica il file direttamente sul servizio di storage a oggetti (compatibile con lo standard S3). Questo riduce la superficie di attacco: il server applicativo non gestisce mai il file grezzo in transito, e un URL intercettato smette di funzionare dopo pochi minuti.

Anche la lettura funziona con lo stesso meccanismo: quando un contenuto privato viene mostrato, generiamo un URL di lettura firmato con validità di pochi minuti (tipicamente 5), invece di esporre un collegamento permanente al file. I contenuti pubblici sono invece serviti tramite CDN per velocità di caricamento, ma restano fisicamente sullo stesso storage a oggetti.

I documenti caricati per la verifica dell'età e dell'identità (necessari per registrarsi come performer, in conformità con 18 U.S.C. § 2257 — vedi la nostra informativa dedicata) sono trattati con un livello di isolamento superiore rispetto agli altri contenuti:

• sono archiviati in un bucket separato dal resto dei contenuti della piattaforma, con proprie credenziali dedicate;
• non hanno mai un indirizzo pubblico: non esiste un URL che li renda accessibili senza passare dal nostro sistema di autorizzazione, nemmeno per errore di configurazione;
• lo staff può visualizzarli solo attraverso un permesso specifico assegnato a livello di ruolo — non è sufficiente essere amministratori generici della piattaforma;
• ogni singola visualizzazione da parte dello staff viene registrata, con l'identità della persona che l'ha effettuata e il momento in cui è avvenuta;
• anche per lo staff autorizzato, ogni visualizzazione genera un nuovo collegamento temporaneo: non conserviamo collegamenti permanenti al documento, nemmeno per uso interno.

Le password non vengono mai salvate in chiaro. Usiamo Argon2id — l'algoritmo di hashing per password raccomandato dalle linee guida OWASP — con parametri intenzionalmente costosi dal punto di vista computazionale (costo di memoria e numero di iterazioni), scelti per rendere impraticabile un tentativo di indovinare le password anche partendo da una copia del database.

Una sessione attiva è composta da due elementi distinti: un token di accesso firmato, di breve durata, usato per le richieste correnti, e un token di refresh opaco che permette di ottenerne uno nuovo senza richiedere di nuovo la password. Il token di refresh non viene mai salvato in chiaro nemmeno lato server: conserviamo solo la sua impronta crittografica (hash), così che nemmeno un accesso al nostro database esponga token utilizzabili. Puoi terminare una sessione in qualsiasi momento — la revoca è immediata, non aspetta la scadenza naturale del token.

Login, registrazione e recupero password sono protetti da limiti di frequenza calcolati per indirizzo IP e per il valore specifico coinvolto (ad esempio l'indirizzo email usato): questo rallenta sia chi tenta un attacco a tappeto da un singolo indirizzo, sia chi tenta ripetutamente l'accesso a un singolo account da indirizzi diversi. A questo si aggiunge un limite generale di richieste applicato a tutta la piattaforma, a protezione da abusi su larga scala.

Il numero della tua carta, la data di scadenza e il codice di sicurezza non arrivano mai ai nostri server, in nessun momento. Quando acquisti token o attivi un abbonamento, ti reindirizziamo alla pagina sicura del gestore di pagamento, che si occupa interamente della raccolta e della elaborazione dei dati della carta secondo gli standard di sicurezza del settore (PCI DSS). Il nostro sistema riceve solo una conferma dell'esito dell'operazione, firmata dal gestore di pagamento, senza mai entrare in possesso dei dati sensibili della carta.

Le coordinate bancarie o di pagamento che una performer registra per ricevere i propri guadagni sono cifrate a livello di singolo campo nel database, con AES-256-GCM — una cifratura autenticata, con un vettore di inizializzazione distinto generato per ogni valore salvato. Anche in caso di accesso non autorizzato al solo database, queste informazioni resterebbero illeggibili senza la chiave di cifratura, custodita separatamente.

Il nostro staff non ha un accesso indifferenziato a tutti i dati della piattaforma. Ogni account interno ha permessi granulari assegnati in base al ruolo, e le operazioni su dati sensibili — come la revisione di un documento di verifica o di una richiesta di rimozione contenuti — restano vincolate al permesso specifico necessario, con tracciamento di chi ha fatto cosa.

In produzione, tutto il traffico tra il tuo browser e Sweetly viaggia su connessione cifrata (HTTPS/TLS): i cookie di sessione sono contrassegnati come sicuri e non vengono mai trasmessi su una connessione non cifrata.

Se hai individuato una falla di sicurezza su Sweetly, ti chiediamo di segnalarcela in modo responsabile prima di renderla pubblica, così da darci il tempo di risolverla: scrivi a [email protected] con i dettagli necessari a riprodurre il problema. Non useremo la segnalazione contro di te se fatta in buona fede e senza accedere a dati che non ti appartengono oltre il minimo indispensabile a dimostrare la falla.