Quando rilasci un’interfaccia utente curata per visualizzare PDF, PPT o fatture, di solito ti concentri su estetica, reattività e tempi di caricamento. Ciò che viene trascurato, però, è come i documenti viaggiano dal tuo server al browser dell’utente. Un singolo passo falso può trasformare un’applicazione altrimenti solida in un vettore di perdita di dati.

In questa guida percorreremo le sette capacità focalizzate sulla sicurezza che dovresti incorporare—pronte all’uso—quando integri un visualizzatore di documenti orientato alla privacy. La checklist è scritta per ingegneri front‑end che vogliono rafforzare i propri embed senza aggiungere complessità inutile.

1. Crittografia End‑to‑End del Flusso del Documento

Perché è importante

Anche se servi i file tramite HTTPS, il documento grezzo può essere intercettato da un’estensione del browser compromessa o da uno script malevolo che legge la risposta prima che raggiunga il visualizzatore.

Come implementare

Passo	Azione
Crittografia lato server	Cifra il file (AES‑256‑GCM è una scelta solida) prima di archiviarlo o trasmetterlo.
Sicurezza del trasporto	Consegna il blob cifrato tramite TLS 1.3.
Decrittazione lato client	Avvia un Web Worker che riceve il flusso cifrato, lo decripta in memoria e invia il testo in chiaro direttamente al canvas del visualizzatore.
Non esporre mai la chiave	Mantieni la chiave di decrittazione in un token a breve durata generato dal server (vedi Funzione #4).

Entro il momento in cui il visualizzatore rende il documento, questo non è mai stato esposto in chiaro sulla rete né nel thread principale.

2. Whitelisting della Content‑Security‑Policy (CSP)

Il rischio

Una CSP permissiva consente a un aggressore di iniettare script malevoli o caricare risorse non autorizzate che potrebbero leggere i dati del canvas del visualizzatore.

Punti chiave

‘unsafe‑inline’ e ‘unsafe‑eval’ sono vietati per gli script.
Solo il CDN del visualizzatore (o il bundle auto‑ospitato) è autorizzato a servire JavaScript.
I frame sono limitati al dominio fidato del visualizzatore.

Una CSP rigorosa riduce drasticamente la superficie di attacco della pagina che ospita l’embed.

3. Isolamento Same‑Origin tramite sandbox `iframe`

Perché la sandbox?

Anche con la CSP, una pagina compromessa potrebbe tentare di accedere al DOM del visualizzatore. Un <iframe> isolato crea una gabbia di sicurezza che la pagina host non può violare senza permesso esplicito.

Flag della sandbox da evitare

allow-top-navigation – impedisce al visualizzatore di dirottare la finestra di livello superiore.
allow-popups – blocca popup inaspettati che potrebbero essere usati per phishing.

Se il visualizzatore deve comunicare con la pagina genitore (ad es. per sincronizzare l’interfaccia), usa postMessage con un controllo esplicito dell’origine.

4. Controllo Accesso Basato su Token

Il problema con gli URL diretti

Gli URL pubblici e statici consentono a chiunque abbia il collegamento di scaricare il file indefinitamente.

Poiché il token è firmato lato server, qualsiasi manomissione invalida la richiesta e il visualizzatore rifiuta il caricamento.

5. Filigrane e Sovrapposizioni Dinamiche

Scopo

Una filigrana dinamica lato client aggiunge un livello di responsabilità senza modificare il file originale.

Suggerimenti per l'implementazione

Renderizza la filigrana su una sovrapposizione canvas che si trova sopra le pagine PDF.
Usa l’email della sessione o un UUID casuale in modo che ogni istanza del visualizzatore sia unica.
Attiva/disattiva la sovrapposizione con un semplice flag per mantenere al minimo l’overhead di performance.

Se dovesse emergere un documento trapelato, l’identificatore incorporato punta direttamente alla fonte.

6. Restrizioni su Download e Stampa

Impostazioni predefinite del browser

La maggior parte dei browser espone un menu contestuale con tasto destro che può salvare il canvas come immagine, esportando di fatto la pagina.

Cosa può e non può fare un visualizzatore

Un SDK per visualizzatori di documenti può nascondere le azioni di esportazione dalla barra degli strumenti, e il catalogo delle funzionalità di Doconut elenca la stampa del browser e l’esportazione PDF tra le capacità che decidi se presentare. Controlla i nomi delle opzioni rispetto alla documentazione della versione che installi, non rispetto a un articolo, incluso questo: le chiavi di configurazione cambiano tra versioni.

Più importante è la parte che nessuna impostazione della barra degli strumenti copre. Nascondere un pulsante è una scelta di flusso di lavoro, non un controllo di accesso. Il server deve comunque autorizzare ogni pagina, miniatura, esportazione, download e stampa autonomamente, perché quegli endpoint possono essere chiamati direttamente. E una volta che i pixel sono sullo schermo, esistono screenshot, fotocamere e strumenti di accessibilità; un visualizzatore che promette il contrario ti sta vendendo qualcosa che non può fornire.

7. Log di Audit e Hook di Evento

Il valore della visibilità

Anche il visualizzatore più rinforzato può essere abusato. Registrare chi ha aperto quale documento, quando e quali azioni ha eseguito crea una traccia forense.

Con i log in tempo reale puoi rilevare pattern anomali—ad esempio un singolo utente che apre decine di PDF riservati in pochi secondi—e attivare avvisi o revoche.

Conclusione

Incorporare un visualizzatore di documenti è una responsabilità di sicurezza, non solo di UI. La crittografia del flusso del documento, una Content‑Security‑Policy rigorosa, un iframe sandbox isolato, l’accesso basato su token, le filigrane dinamiche, le restrizioni di esportazione trattate come UX piuttosto che come protezione e i log di audit sono gli elementi che distinguono un embed difendibile da uno vulnerabile.

Due di queste sette sono tue, indipendentemente dal visualizzatore scelto: autorizzazione e audit. Nessun componente può prendere quella decisione per la tua tenancy.

Pronto a costruire l’embed?

Inizia dalla documentazione ufficiale del fornitore per la versione che installi. Per Doconut, è doconut.com — pacchetti, guide di installazione e esempi. Copiare le chiavi di configurazione da articoli è il modo in cui le integrazioni si rompono durante gli aggiornamenti.
Inserisci la checklist a sette punti nel tuo modello di pull‑request così la revisione di sicurezza avviene prima del merge, non dopo l’incidente.
Testa prima i casi negativi: l’identificatore di documento di un altro tenant, una sessione scaduta, una richiesta diretta a una pagina o a un endpoint di esportazione. Questi sono i test che scoprono le vere vulnerabilità.