Cuando lanzas una interfaz pulida para mostrar PDFs, PPTs o facturas, normalmente te centras en la estética, la capacidad de respuesta y el tiempo de carga. Lo que se pasa por alto, sin embargo, es cómo los documentos viajan desde tu servidor al navegador del usuario. Un solo paso en falso puede convertir una aplicación sólida en un vector de fuga de datos.
En esta guía repasaremos las siete capacidades centradas en la seguridad que deberías incorporar—listo para usar—al integrar un visor de documentos con enfoque de privacidad. La lista de verificación está escrita para ingenieros front‑end que desean reforzar sus incrustaciones sin añadir complejidad innecesaria.
1. Cifrado de Extremo a Extremo del Flujo del Documento
Por qué es importante
Incluso si sirves archivos mediante HTTPS, el documento sin procesar puede ser interceptado por una extensión de navegador comprometida o un script malicioso que lea la respuesta antes de que llegue al visor.
Cómo implementarlo
| Paso | Acción |
|---|---|
| Cifrado del lado del servidor | Cifra el archivo (AES‑256‑GCM es una buena opción) antes de almacenarlo o transmitirlo. |
| Seguridad del transporte | Entrega el blob cifrado mediante TLS 1.3. |
| Descifrado del lado del cliente | Inicia un Web Worker que reciba el flujo cifrado, lo descifre en memoria y alimente el texto plano directamente al canvas del visor. |
| Nunca expongas la clave | Mantén la clave de descifrado en un token de corta duración generado por el servidor (ver Característica #4). |
Para cuando el visor renderiza, el documento nunca ha sido expuesto en texto plano en la red ni en el hilo principal.
2. Lista Blanca de Content‑Security‑Policy (CSP)
El riesgo
Una CSP laxa permite que un atacante inyecte scripts maliciosos o cargue recursos fraudulentos que podrían leer los datos del canvas del visor.
Puntos clave
- ‘unsafe‑inline’ y ‘unsafe‑eval’ están prohibidos para scripts.
- Solo el CDN del visor (o el paquete auto‑alojado) está permitido para servir JavaScript.
- Los frames están restringidos al dominio de visor de confianza.
Una CSP estricta reduce drásticamente la superficie de ataque de la página que aloja la incrustación.
3. Aislamiento Same‑Origin mediante sandbox de iframe
¿Por qué sandbox?
Incluso con CSP, una página comprometida podría intentar acceder al DOM del visor. Un <iframe> aislado crea una cárcel de seguridad que la página anfitriona no puede romper sin permiso explícito.
Banderas de sandbox a evitar
allow-top-navigation– impide que el visor secuestre la ventana de nivel superior.allow-popups– bloquea pop‑ups inesperados que podrían usarse para phishing.
Si el visor necesita comunicarse con la página padre (p. ej., para sincronizar la UI), usa postMessage con una comprobación explícita del origen.
4. Control de Acceso Basado en Token
El problema con URLs directas
Los URLs públicos y estáticos permiten que cualquiera con el enlace descargue el archivo indefinidamente.
Como el token está firmado del lado del servidor, cualquier manipulación invalida la solicitud, y el visor se niega a cargar.
5. Marca de Agua y Superposiciones Dinámicas
Propósito
Una marca de agua dinámica del lado del cliente añade una capa de responsabilidad sin alterar el archivo original.
Consejos de implementación
- Renderiza la marca de agua en una superposición de canvas que se sitúe sobre las páginas del PDF.
- Usa el correo electrónico de la sesión o un UUID aleatorio para que cada instancia del visor sea única.
- Alterna la superposición con una bandera simple para mantener la sobrecarga de rendimiento mínima.
Si un documento filtrado aparece, el identificador incrustado apunta directamente a la fuente.
6. Restricciones de Descarga e Impresión
Valores predeterminados del navegador
La mayoría de los navegadores exponen un menú contextual de clic derecho que puede guardar el canvas como imagen, exportando efectivamente la página.
Lo que un visor puede y no puede hacer
Un SDK de visor de documentos puede ocultar acciones de exportación de la barra de herramientas, y el catálogo de características de Doconut enumera la impresión del navegador y la exportación a PDF entre las capacidades que decides presentar. Verifica los nombres de las opciones contra la documentación de la versión que instalas en lugar de contra cualquier artículo, incluido este: las claves de configuración cambian entre versiones.
Más importante es la parte que ninguna configuración de barra cubre. Ocultar un botón es una elección de flujo, no un control de acceso. El servidor debe seguir autorizando cada página, miniatura, exportación, descarga y solicitud de impresión por sí mismo, porque esos endpoints pueden llamarse directamente. Y una vez que los píxeles están en pantalla, existen capturas de pantalla, cámaras y herramientas de accesibilidad; un visor que promete lo contrario está vendiendo algo que no puede cumplir.
7. Registro de Auditoría y Ganchos de Eventos
El valor de la visibilidad
Incluso el visor más endurecido puede ser mal utilizado. Registrar quién abrió qué documento, cuándo y qué acciones realizó crea una pista forense.
Con registros en tiempo real puedes detectar patrones anómalos—como un solo usuario abriendo docenas de PDFs confidenciales en segundos—y activar alertas o revocaciones.
Conclusión
Incorporar un visor de documentos es una responsabilidad de seguridad, no solo de UI. El cifrado del flujo del documento, una Content‑Security‑Policy estricta, un sandbox de iframe aislado, control de acceso basado en token, marcas de agua dinámicas, restricciones de exportación tratadas como UX más que como protección, y registro de auditoría son lo que separa una incrustación que puedes defender de una que no.
Dos de esas siete son tuyas sin importar qué visor elijas: autorización y auditoría. Ningún componente puede tomar esa decisión por tu arrendamiento.
¿Listo para construir la incrustación?
- Comienza con la documentación del proveedor para la versión que instalas. Para Doconut, eso es doconut.com — paquetes, guías de configuración y ejemplos. Copiar claves de configuración de artículos es cómo las integraciones se rompen al actualizar.
- Incluye la lista de verificación de siete puntos en tu plantilla de pull‑request para que la revisión de seguridad ocurra antes del merge, no después del incidente.
- Prueba primero los casos negativos: el identificador de documento de otro inquilino, una sesión expirada, una solicitud directa a una página o endpoint de exportación. Esas son las pruebas que descubren agujeros reales.