Sicurezza

Ultimo aggiornamento: 31 August 2026

Questa pagina descrive le misure tecniche che Lavurà (lavura.app) applica ai dati che le affidi: la password del tuo account, le credenziali dei portali di lavoro, il tuo CV e i documenti generati.

Dice cosa il prodotto fa, non cosa promette. Ogni affermazione qui sotto corrisponde a un comportamento del codice e, dove una misura ha un limite, il limite è scritto: una pagina sulla sicurezza che tace i propri punti deboli non è prudente, è inutile.

Questa è una pagina tecnica. Cosa raccogliamo, su quale base giuridica, per quanto tempo e quali diritti hai è scritto nel documento Informativa privacy. I due documenti descrivono lo stesso sistema da due lati; se divergono, scrivici.

La password del tuo account

Conservata come hash, mai come testo. Viene trasformata con bcrypt a fattore di costo 12 prima di arrivare al database, e il sale viaggia dentro l'hash stesso. bcrypt è a senso unico: nessuna parte del prodotto riporta quel valore alla password di partenza. La colonna si chiama passwordHash.
Otto caratteri minimo, e nessun'altra regola. Registrazione e cambio password richiedono almeno 8 caratteri e ne accettano fino a 200. Nessuna classe di caratteri è obbligatoria: né maiuscole, né cifre, né simboli. La password non viene confrontata con elenchi di password diffuse o già trapelate, quindi la sua robustezza dipende interamente da te.
Cambiarla chiude tutte le sessioni aperte. Il cambio password richiede la password attuale. Un account creato solo con Google non ha password, quindi digita l'indirizzo email dell'account: è un controllo più debole, ed è scritto qui come tale. Accettato il cambio, il numero di versione della sessione aumenta e i token emessi prima smettono di essere accettati.

Credenziali dei portali di lavoro

Alcuni portali di lavoro non espongono alcuna interfaccia di programmazione, e l'unico modo di inviare la candidatura è accedere come faresti tu. Serve a questo la funzione facoltativa descritta qui, ed è la cosa più sensibile che il prodotto tratta.

Cifrate prima di essere scritte. Nome utente e password di un portale vengono cifrati con AES-256-GCM, una modalità autenticata: una manomissione del valore conservato viene rilevata, invece di produrre in silenzio dati senza senso. Ogni credenziale ha un proprio sale casuale di 16 byte e la chiave ne viene derivata con PBKDF2-SHA256 su 100.000 iterazioni. Nel database finiscono sale, vettore di inizializzazione, tag di autenticazione e testo cifrato. Le righe scritte prima che il sale venisse introdotto si decifrano ancora, con una derivazione più debole e senza sale, e nessun codice le riscrive.
La chiave non è nel database. È un valore di 64 caratteri esadecimali tenuto in una variabile d'ambiente del server. Se quella variabile manca, la cifratura solleva un errore invece di ripiegare su altro, quindi niente viene scritto in chiaro per sbaglio. Una copia del database presa da sola restituisce testo cifrato.
Possiamo rileggerle. È così che è progettato. Esiste un percorso di codice che riporta il testo cifrato in chiaro, perché un modulo non si compila con un testo cifrato. Chi ha insieme il database e la variabile d'ambiente può recuperare ogni password conservata. È una cifratura di cui noi teniamo la chiave, e nessuna frase di questa pagina la descrive come altro. La funzione è facoltativa: non viene conservato nulla finché non colleghi tu un portale.
L'interfaccia restituisce un booleano, non il segreto. L'endpoint delle credenziali risponde con hasPassword — vero o falso — e mai con il testo cifrato o con il sale, che restano sul server. L'indirizzo IP registrato al momento del consenso viene restituito troncato. Chi ruba una sessione valida può vedere che hai credenziali salvate; da questo endpoint non le ottiene.
Due consensi separati, e un registro di entrambi. L'automazione va attivata a livello generale e ogni collegamento a un portale chiede una propria spunta esplicita: senza quella la richiesta viene rifiutata. Ogni consenso lascia data, indirizzo IP troncato e user agent in una tabella che lo schema descrive come append-only. Quella tabella viene svuotata solo quando cancelli l'account, non dal ripristino dei dati.
Rimuovibili in qualsiasi momento. Puoi eliminare il collegamento a un singolo portale, e sia il ripristino dei dati sia la cancellazione dell'account rimuovono ogni riga di credenziali. La cancellazione ti chiede prima di digitare di nuovo la password.

Sessioni

Quanto dura una sessione. 30 giorni se chiedi di restare collegato, 2 ore se non lo chiedi. Questa pagina legge entrambi i numeri dallo stesso modulo di configurazione che usa il codice di autenticazione, quindi non possono allontanarsi da ciò che viene davvero emesso.
Le sessioni sono firmate, e il segreto di firma è obbligatorio. Una sessione è un token firmato, non una riga in una tabella. In produzione l'avvio viene rifiutato se il segreto di firma manca o è più corto di 32 caratteri: quel controllo solleva un errore all'avvio, non un avviso.
Cambiare password o email invalida i token precedenti. Ogni account ha un numero di versione che entra nei suoi token, e aumentarlo rende inaccettabile ogni token emesso prima. Il numero viene ricontrollato al massimo ogni cinque minuti, quindi un token vecchio smette di essere accettato entro cinque minuti dal cambio. Cambiare indirizzo email ne azzera anche lo stato di verifica, quindi il nuovo indirizzo va dimostrato di nuovo.
Uscire ti fa uscire da tutti i dispositivi. Non esiste un elenco lato server dei token attivi, quindi un logout non può scegliere un solo dispositivo. Aumenta invece il numero di versione, il che chiude la sessione su ogni dispositivo insieme. È una scelta precisa: l'alternativa sarebbe un registro dei token, e il prodotto non ne tiene uno.
Le richieste cross-site vengono rifiutate. Una richiesta che modifica lo stato viene confrontata con la sua intestazione Origin o Referer. Quando nessuna delle due è presente ma viaggia un cookie di sessione, la richiesta viene rifiutata invece di essere accettata nel dubbio.
Cosa è pubblico e cosa no. La dashboard e ogni interfaccia di programmazione dietro di essa richiedono una sessione. Le superfici di amministrazione richiedono in più un indirizzo presente in una lista fissa. Questa pagina e le pagine legali non richiedono nulla.

Tentativi di accesso

Il contatore viene consultato per primo. Il controllo di blocco gira prima che l'account venga cercato e prima di qualunque confronto di password, quindi un account bloccato non costa alcun lavoro crittografico. Un accesso riuscito azzera il contatore.
Cinque, poi otto, poi dieci. I fallimenti vengono contati dentro una finestra scorrevole di quindici minuti. Cinque fallimenti bloccano il tentativo per un minuto, otto per quindici minuti, dieci o più per un'ora.
Una sola persona non può bloccarti. Un blocco sull'intero account — distinto dal blocco sull'indirizzo che sta provando — scatta solo se i fallimenti arrivano da almeno due indirizzi IP diversi. Chi digita la tua email con password sbagliate da una sola macchina non può impedirti di accedere.
Anche registrazione e recupero sono limitati. Per indirizzo IP in quindici minuti: cinque registrazioni, cinque richieste di recupero password, tre rinvii della verifica. In più, tre per ciascun tipo per ogni indirizzo email in un'ora, quindi ruotare gli indirizzi non serve.
Le risposte non dicono se un account esiste. Il recupero password risponde allo stesso modo sia che l'indirizzo sia registrato sia che non lo sia. Un accesso fallito dà lo stesso messaggio per una password sbagliata e per un account inesistente, e i tentativi su account inesistenti vengono contati comunque. Chiedere il documento di un altro restituisce "non trovato" invece di "vietato". La registrazione è l'eccezione: deve dire che l'indirizzo è già usato, e così lo rivela.
Se il deposito condiviso non risponde, il limite si allarga. I contatori stanno in un deposito condiviso perché ogni istanza dell'applicazione veda lo stesso numero. Se quel deposito non è raggiungibile i contatori passano alla memoria della singola istanza e un avviso finisce nel log. Durante un'interruzione di questo tipo il limite effettivo è più largo di quello configurato, non più stretto. Abbiamo scelto questo invece di bloccare le persone fuori dal proprio account per un guasto di infrastruttura.

CV e documenti generati

Conservati in un object store privato. I documenti vengono scritti con accesso privato. Il riferimento conservato nel database è un identificatore interno, non un indirizzo scaricabile, e la chiave dell'oggetto contiene un segmento casuale di 12 byte non indovinabile. Nessun URL dell'oggetto viene mai consegnato a un browser.
Non cifriamo i byte dei documenti. Il tuo CV, le tue lettere di presentazione e i PDF generati vengono conservati così come sono. Nel codice applicativo questo prodotto cifra una cosa sola: le password che salvi per i portali e i siti di candidatura. Qui la protezione dei documenti è controllo degli accessi, non crittografia, e il controllo degli accessi è la più debole delle due: va chiamata con il suo nome.
Una sola rotta, con verifica della proprietà. Ogni download passa da un unico endpoint autenticato che verifica la sessione e che il documento sia tuo. Il documento di un altro risponde "non trovato", non "vietato", quindi l'endpoint non rivela quali identificatori esistono. Le risposte hanno cache no-store e nessuna ispezione del content-type, e un documento HTML non viene mai mostrato inline nel browser.

Link di recupero e di verifica

Il link in sé non viene conservato. Ne viene conservato solo il digest SHA-256. Una copia del database quindi non contiene alcun link di recupero o di verifica utilizzabile; il token esiste solo dentro l'email che ti è stata mandata. I token sono 32 byte casuali e chiederne uno nuovo elimina il precedente nella stessa transazione sul database.
A tempo, monouso, e la casella blocca l'accesso. Un token di recupero vale un'ora, un token di verifica ventiquattro, e ciascuno può essere consumato una volta sola. L'accesso resta bloccato finché la casella non è verificata: questo impedisce a qualcuno di registrare il tuo indirizzo con una password sua, e impedisce che un accesso con Google venga agganciato a un account il cui indirizzo non è mai stato dimostrato.

La tua casella Lavurà

La posta è ricevuta e consegnata da Resend. La posta al tuo indirizzo Lavurà viene ricevuta per nostro conto da Resend, e la posta delle tue candidature vi passa per l'invio (l'invio parte da AWS eu-west-1, in Irlanda; Resend è un'azienda statunitense e il trasferimento è coperto dalle clausole contrattuali standard). Gli esiti SPF, DKIM e DMARC della posta in arrivo sono conservati insieme al messaggio. Nessun account Google è collegato e nessun token Google esiste in questo prodotto.
I codici di verifica restano privati. Un codice viene letto dal messaggio conservato dall'automazione, digitato nel modulo del sito e segnato come consumato. Non viene mai registrato nei log, mai inoltrato alla tua casella e mai scritto nel registro degli invii; il campo per il codice manuale resta come alternativa.
Il contenuto dei messaggi viene eliminato dopo trenta giorni. Un job automatico giornaliero azzera il corpo conservato di ogni messaggio della casella più vecchio di trenta giorni, tenendo mittente e oggetto perché l'esito di una candidatura dipende da quelli. Né mittente né oggetto sono cifrati da noi finché restano.

Trasporto e intestazioni del browser

HTTPS obbligatorio per un anno. Ogni risposta contiene Strict-Transport-Security con durata di un anno e includeSubDomains. La connessione cifrata termina sulla piattaforma di hosting: non la configuriamo noi, quindi questa pagina non può dire quali versioni del protocollo o quali cipher suite accetta.
Il framing è bloccato due volte. X-Frame-Options: DENY e una Content-Security-Policy con frame-ancestors 'none' vengono inviati su ogni percorso, quindi questo sito non può essere incorporato in un frame su un altro sito — che è la condizione su cui si basa il clickjacking.
E altre più piccole. L'ispezione del content-type è disattivata, il referrer inviato ad altri siti è limitato all'origine, e camera, microfono, geolocalizzazione e argomenti di navigazione sono disattivati per policy.
La content policy è stretta, ed è un limite. Fissa il base URI, vieta gli oggetti incorporati, blocca il framing e chiede ai browser di aggiornare le richieste insicure. Non elenca quali origini possono servire script o fogli di stile, quindi non fermerebbe l'esecuzione di codice iniettato. È protezione dal clickjacking e qui non viene presentata come nulla di più.

Cancellazione e conservazione

Un job pianificato gira ogni giorno. Elimina i documenti generati più vecchi di dodici mesi, azzera i corpi dei messaggi email più vecchi di trenta giorni e rimuove code elaborate, claim di invio scaduti ed eventi di fatturazione già gestiti più vecchi di novanta. Risponde solo a un segreto bearer confrontato a tempo costante; senza quel segreto il job non fa nulla.
Prima i byte, poi le autorizzazioni remote, poi le righe. L'ordine non è accessorio. Rimuovere prima la riga dal database lascerebbe il file nell'object store senza più nulla che ci punti, e nessuna esecuzione successiva saprebbe di doverlo raccogliere. Eliminare i documenti conservati, chiudere le autorizzazioni remote e solo infine rimuovere le righe significa non lasciare niente di orfano.
La cancellazione chiede di nuovo la password. Sia il ripristino dei dati sia la cancellazione dell'account richiedono la password ancora una volta — oppure l'indirizzo email dell'account, per un account creato solo con Google. Con precisione: non è un secondo fattore di autenticazione in senso tecnico, è la stessa credenziale presentata due volte. Serve perché una cancellazione non possa partire da una sessione lasciata aperta che qualcun altro ha davanti.
Le sessioni sui portali vengono chiuse prima di qualunque cosa. Il ripristino aspetta che ogni sessione collegata a un portale venga chiusa sulla macchina che la ospita. Se quella conferma non arriva, la richiesta si ferma con un errore e non viene cancellato nulla: un ripristino parziale che lascia una credenziale viva su un sito terzo è peggio di nessun ripristino.

L'elenco completo di cosa conserviamo, per quanto tempo e perché è una tabella nel documento Informativa privacy. Resta lì e non viene copiato qui, perché due copie della stessa tabella prima o poi si contraddicono.

Cosa questo prodotto non ha

È elencato perché un lettore potrebbe ragionevolmente supporlo, e perché su una pagina come questa un'omissione è essa stessa un'affermazione.

Nessuna certificazione, e nessun test esterno. Nessun organismo indipendente ha certificato la sicurezza di questo prodotto e nessuna parte esterna è stata incaricata di attaccarlo. I controlli descritti sopra sono stati scritti e sono mantenuti dalle persone che hanno costruito il prodotto. È un limite reale alla garanzia che puoi ricavare da questa pagina.
Nessun secondo fattore di autenticazione. L'accesso è un indirizzo email e una password. Non c'è nessun codice temporaneo, nessuna applicazione che ne genera uno e nessuna chiave fisica. Se qualcuno ha la tua password e può leggere la tua casella, può accedere al posto tuo: usa una password che non usi da nessun'altra parte. Neanche il controllo prima di una cancellazione è un secondo fattore — è la stessa password digitata di nuovo.
Nessuna cifratura generale dei dati a riposo. Questa pagina non afferma che i tuoi dati siano cifrati mentre stanno nel deposito. Il codice applicativo cifra esattamente una cosa: le password che salvi per i portali e i siti di candidatura. Tutto il resto — il testo del tuo CV, il tuo profilo, lo storico delle candidature — è protetto da controllo degli accessi. La cifratura dei dischi sottostanti e del database appartiene alla piattaforma di hosting, e da qui non possiamo né descriverla né garantirla.
Non affermiamo nulla su terzi. Il prodotto dipende da altre società per hosting, database, storage, pagamenti ed email. Le loro certificazioni, i loro sub-responsabili e i loro controlli spettano a loro pubblicarli e questa pagina non parla per loro: descrive solo il nostro lato di ciascuna integrazione. L'elenco dei destinatari è nel documento Accordo sul Trattamento dei Dati, e lì c'è anche cosa ci deve ciascuno di loro se qualcosa va storto.
Nessuna garanzia di sicurezza assoluta. Nessun sistema collegato a una rete può essere dichiarato sicuro senza riserve, e questo non viene dichiarato tale. Le misure sopra riducono quanto è probabile un incidente e quanto danno farebbe; non eliminano né l'una né l'altro. Cosa ci impegniamo a fare se i dati personali vengono violati è scritto nella sezione 10 dell'Informativa privacy.

Segnalare un problema

Se trovi una vulnerabilità, o se credi che qualcuno abbia acceduto al tuo account o ai tuoi dati senza autorizzazione, scrivi a hello@lavura.app. Per qualsiasi questione che non sia di sicurezza, hello@lavura.appè l'indirizzo giusto. La procedura e i tempi per notificare una violazione di dati personali sono nella sezione 10 del documento Informativa privacy. Se segnali una vulnerabilità, ti chiediamo di non divulgarla pubblicamente prima che abbiamo avuto il tempo di verificarla e di correggerla.

Il titolare di questo servizio è Giacorn Industries, partita IVA IT04199790926, con sede in Cagliari, Italy.