Quando você lança uma UI polida para exibir PDFs, PPTs ou notas fiscais, costuma focar na estética, responsividade e tempo de carregamento. O que costuma ser negligenciado, porém, é como os documentos viajam do seu servidor para o navegador do usuário. Um único passo em falso pode transformar uma aplicação sólida em um vetor de vazamento de dados.

Neste guia vamos percorrer as sete capacidades focadas em segurança que você deve incorporar — prontas para uso — ao integrar um visualizador de documentos orientado à privacidade. A lista de verificação foi escrita para engenheiros front‑end que desejam fortalecer suas incorporações sem adicionar complexidade desnecessária.

1. Criptografia de Ponta a Ponta do Fluxo de Documentos

Por que importa

Mesmo que você sirva arquivos via HTTPS, o documento bruto pode ser interceptado por uma extensão de navegador comprometida ou um script malicioso que lê a resposta antes que ela chegue ao visualizador.

Como implementar

Etapa	Ação
Criptografia no servidor	Criptografe o arquivo (AES‑256‑GCM é uma escolha sólida) antes de armazená‑lo ou transmiti‑lo.
Segurança de transporte	Entregue o blob criptografado via TLS 1.3.
Descriptografia no cliente	Inicie um Web Worker que recebe o fluxo criptografado, descriptografa‑o na memória e alimenta o texto puro diretamente ao canvas do visualizador.
Nunca exponha a chave	Mantenha a chave de descriptografia em um token de curta duração, gerado pelo servidor (veja o Recurso #4).

No momento em que o visualizador renderiza, o documento nunca foi exposto em texto puro na rede ou na thread principal.

2. Lista de Permissões da Content‑Security‑Policy (CSP)

O risco

Uma CSP frouxa permite que um atacante injete scripts maliciosos ou carregue recursos fraudulentos que poderiam ler os dados do canvas do visualizador.

Pontos‑chave

‘unsafe‑inline’ e ‘unsafe‑eval’ são proibidos para scripts.
Apenas o CDN do visualizador (ou o bundle auto‑hospedado) tem permissão para servir JavaScript.
Frames são restritos ao domínio confiável do visualizador.

Uma CSP rigorosa reduz drasticamente a superfície de ataque da página que hospeda a incorporação.

3. Isolamento de Same‑Origin via `iframe` Sandbox

Por que usar sandbox?

Mesmo com CSP, uma página comprometida poderia tentar acessar o DOM do visualizador. Um <iframe> isolado cria uma gaiola de segurança que a página hospedeira não pode romper sem permissão explícita.

Flags de sandbox a evitar

allow-top-navigation – impede que o visualizador sequestre a janela de nível superior.
allow-popups – bloqueia pop‑ups inesperados que poderiam ser usados para phishing.

Se o visualizador precisar se comunicar com a página pai (por exemplo, para sincronizar a UI), use postMessage com verificação explícita da origem.

4. Controle de Acesso Baseado em Token

O problema dos URLs diretos

URLs públicos e estáticos permitem que qualquer pessoa com o link baixe o arquivo indefinidamente.

Como o token é assinado no servidor, qualquer adulteração invalida a requisição, e o visualizador recusa o carregamento.

5. Marcação d'Água & Sobreposições Dinâmicas

Finalidade

Uma marca d'água dinâmica, gerada no cliente, adiciona uma camada de responsabilização sem alterar o arquivo original.

Dicas de implementação

Renderize a marca d'água em uma sobreposição de canvas que fica acima das páginas do PDF.
Use o e‑mail da sessão ou um UUID aleatório para que cada instância do visualizador seja única.
Ative ou desative a sobreposição com uma simples flag para manter a sobrecarga de desempenho mínima.

Se um documento vazado aparecer, o identificador embutido aponta diretamente para a origem.

6. Restrições de Download & Impressão

Padrões dos navegadores

A maioria dos navegadores exibe um menu de contexto ao clicar com o botão direito que pode salvar o canvas como imagem, efetivamente exportando a página.

O que um visualizador pode e não pode fazer

Um SDK de visualizador de documentos pode ocultar ações de exportação da barra de ferramentas, e o catálogo de recursos da Doconut lista impressão no navegador e exportação de PDF entre as capacidades que você decide apresentar. Verifique os nomes das opções na documentação da versão que você instalou, pois as chaves de configuração mudam entre versões.

Mais importante é a parte que nenhuma configuração de barra de ferramentas cobre. Ocultar um botão é uma escolha de fluxo de trabalho, não um controle de acesso. O servidor ainda deve autorizar cada página, miniatura, exportação, download e solicitação de impressão individualmente, pois esses endpoints podem ser chamados diretamente. E, uma vez que os pixels estão na tela, capturas de tela, câmeras e ferramentas de acessibilidade existem; um visualizador que promete o contrário está oferecendo algo que não pode cumprir.

7. Registro de Auditoria & Ganchos de Evento

O valor da visibilidade

Mesmo o visualizador mais reforçado pode ser usado indevidamente. Registrar quem abriu qual documento, quando e quais ações foram realizadas cria um rastro forense.

Com logs em tempo real você pode detectar padrões anômalos — como um único usuário abrindo dezenas de PDFs confidenciais em segundos — e disparar alertas ou revogações.

Conclusão

Incorporar um visualizador de documentos é uma responsabilidade de segurança, não apenas de UI. Criptografia do fluxo de documentos, uma Content‑Security‑Policy rigorosa, um sandbox de iframe isolado, controle de acesso baseado em token, marcas d'água dinâmicas, restrições de exportação tratadas como UX e não como proteção, e registro de auditoria são os elementos que separam uma incorporação que você pode defender de uma que não pode.

Dois desses sete são seus, independentemente do visualizador escolhido: autorização e auditoria. Nenhum componente pode tomar essa decisão por sua locação.

Pronto para construir a incorporação?

Comece pela documentação do fornecedor para a versão que você instalou. Para Doconut, isso está em doconut.com — pacotes, guias de configuração e exemplos. Copiar chaves de configuração de artigos é como as integrações quebram na atualização.
Inclua a lista de verificação de sete pontos no seu modelo de pull‑request para que a revisão de segurança aconteça antes da mesclagem, não após o incidente.
Teste primeiro os casos negativos: identificador de documento de outro locatário, sessão expirada, requisição direta a uma página ou endpoint de exportação. Esses são os testes que revelam falhas reais.