Sicurezza

Autenticazione

• Le password sono cifrate con scrypt e un sale per ogni utente.
• L'accesso confronta con un hash fittizio quando l'indirizzo è sconosciuto, così un tentativo fallito impiega lo stesso tempo che l'account esista o no.
• Le sessioni sono token casuali opachi in un cookie httpOnly, SameSite=Lax (Secure in produzione). Lato server viene conservato solo un hash SHA-256.
• Cambiare o reimpostare una password revoca ogni sessione su ogni dispositivo.
• I token di verifica e di reimpostazione sono monouso, cifrati a riposo e scadono (rispettivamente dopo 24 ore e 1 ora).
• L'accesso con Google verifica un parametro di stato CSRF e rifiuta di collegare un indirizzo Google non verificato a un account esistente.

Autorizzazione

• Controllo degli accessi basato sui ruoli, con una tabella di permessi invece di confronti di ruolo sparsi nel codice. Ruoli: USER, AGENT_BUILDER, SUPPORT, MANAGER, ADMIN, SUPER_ADMIN.
• Ogni query che legge dati di un cliente è limitata all'id dell'utente, così un identificatore di un altro account porta a un 404 invece che a una fuga di dati.
• Le rotte di amministrazione verificano il permesso specifico che richiedono, indipendentemente dal layout che rende la pagina.
• Nessuno può cambiare il proprio ruolo o stato, né concedere un ruolo superiore al proprio.

Protezione delle richieste

• CSRF: le operazioni di modifica autenticate tramite cookie richiedono la corrispondenza dell'Origin e un token a doppio invio.
• Limitazione della frequenza su accesso, registrazione, reimpostazione della password, esecuzioni di agenti, moduli pubblici e webhook.
• Convalida dell'input con Zod a ogni confine dell'API. Un input non valido restituisce errori per campo, mai una traccia di stack.
• L'accesso al database passa da Prisma con query parametrizzate; non c'è SQL costruito concatenando stringhe.
• Le richieste in uscita da agenti e nodi dei flussi di lavoro rifiutano loopback e intervalli di rete privati, bloccando il SSRF.

Segreti

• Le credenziali delle integrazioni e i token OAuth sono cifrati con AES-256-GCM prima di essere salvati e non vengono mai inviati a un browser.
• Le chiavi API sono conservate come hash SHA-256. La chiave in chiaro compare esattamente una volta, nella risposta alla creazione.
• Le chiavi API dei provider vivono solo nelle variabili d'ambiente del server. Tutte le chiamate ai modelli avvengono lato server.
• I log passano attraverso un filtro di redazione che elimina i campi che hanno la forma di una credenziale.

Esecuzione degli agenti

• Gli strumenti dichiarano un livello di rischio: READ, WRITE o DESTRUCTIVE. La versione di un agente dichiara il livello più alto che può compiere automaticamente.
• Una chiamata oltre quel limite viene rifiutata, registrata come in attesa di approvazione e riportata al modello come non eseguita.
• Le esecuzioni sono delimitate dal numero di passaggi, da un budget di token e da un timeout sul tempo reale.
• Ogni passaggio viene salvato con il proprio input, output, durata e livello di rischio.

Pagamenti

• PROMIVO non vede né conserva mai i dati della carta. Se ne occupa da un capo all'altro il nostro fornitore di pagamenti.
• Le firme dei webhook vengono verificate prima che il payload venga letto come dato.
• Ogni evento viene salvato con un vincolo di unicità, così una riconsegna viene riconosciuta e saltata invece di essere applicata due volte.
• I diritti vengono concessi solo dal gestore dei webhook, mai da un reindirizzamento di successo lato client.

Segnalare una vulnerabilità

Contattaci indicando i passaggi per riprodurla. Ti chiediamo di darci un margine ragionevole per correggerla prima di divulgarla pubblicamente.