Questa pagina descrive le misure a cui rinvia l'accordo sul trattamento dei dati. È scritta per essere verificabile: ogni misura indica cosa la applica, così la revisione di sicurezza di un potenziale cliente può controllare invece di fidarsi.

Cifratura

Tutto il traffico passa su TLS. I token OAuth di terze parti (Shopify, Google, Meta, Klaviyo, Notion, Figma) sono cifrati a riposo con AES-256-GCM con una chiave che può essere ruotata: una copia del database non restituisce quindi credenziali utilizzabili. I report di verifica dell'identità sono cifrati con lo stesso sistema e non vengono mai mostrati nel prodotto.

Isolamento dei dati dei clienti

Ogni query che accede ai dati di un'organizzazione o di un negozio è filtrata in base all'appartenenza, e questo filtro è coperto da test che bloccano la build, non affidato alla sola disciplina delle revisioni. I ruoli sono Proprietario, Admin, Membro e Osservatore, e i permessi vengono verificati lato server a ogni richiesta, mai nel client.

Autenticazione

L'accesso avviene con un codice monouso di sei cifre inviato via email. Non c'è quindi nessuna password che possa trapelare né alcun link magico da inoltrare. Le sessioni sono conservate in un cookie con prefisso __Secure-, scadono dopo 30 giorni e si riducono a 24 ore quando accedi senza chiedere di ricordare il dispositivo.

Registro di audit

Gli eventi di sicurezza e di fatturazione sono scritti in un registro in sola aggiunta, consultabile nell'attività del tuo account. Le azioni amministrative della piattaforma sono registrate a parte. I dati grezzi dei webhook vengono eliminati prima degli eventi stessi: il registro resta, i dati grezzi no.

Segreti

Nessuna credenziale viene salvata nel repository. La dashboard operatore che riporta la configurazione dell'ambiente indica solo se una chiave è impostata, mai il suo valore. Un test rifiuta qualsiasi valore che somigli a un segreto nel file di configurazione MCP versionato.

Integrità e gestione delle modifiche

Le modifiche allo schema del database sono derivate automaticamente e applicate in modo idempotente, con un controllo che rifiuta qualsiasi modifica che potrebbe fallire in produzione quando una tabella contiene già delle righe. Prima che una modifica arrivi al repository remoto, un hook di pre-push esegue controlli offline rapidi (schema, affermazioni della documentazione, testi, versioni). Lint, controllo dei tipi e l'intera suite di test girano in integrazione continua su ogni pull request. La documentazione che stai leggendo è a sua volta controllata: i dati pubblicati vengono confrontati con il codice che li implementa.

Infrastruttura

La piattaforma è ospitata su Vercel, con un database PostgreSQL gestito su Neon, che offre backup continui e il ripristino a un momento preciso. Cache e code girano su Upstash. I pagamenti non passano mai dai nostri server: i dati della carta sono trattati da Stripe. La regione di ciascun fornitore è pubblicata nella pagina dei sub-responsabili.

Monitoraggio

La piattaforma pubblica una pagina di stato in tempo reale con 90 giorni di storico e un resoconto mensile della disponibilità. Gli incidenti vengono dichiarati lì, con un feed RSS e l'iscrizione via email. I problemi a livello di piattaforma (iscrizioni, pagamenti non riusciti) vengono riassunti all'operatore ogni ora.

Segnalare una vulnerabilità

Scrivi a contact@boostecom.app con dettagli sufficienti a riprodurre il problema. Confermiamo la ricezione entro tre giorni lavorativi. Non intraprenderemo azioni legali per ricerche in buona fede che rispettino la privacy degli utenti, evitino la distruzione di dati e non degradino il servizio. Ti chiediamo di non fare test sull'account o sul negozio di un altro utente.

Ultimo aggiornamento 12 settembre 2026