Cifrado del lado del cliente vs del servidor explicado con modelos de amenaza y compensaciones de UX para almacenar contratos, identificaciones y archivos médicos en una app de negocio.
Si tu app permite que la gente suba archivos, no estás guardando solo “documentos”. A menudo guardas una segunda identidad del usuario: contratos firmados, fotos de pasaporte o licencia, formularios médicos y resultados de laboratorio. Los archivos son pequeños. El riesgo asociado no lo es.
Un contrato filtrado puede desencadenar consecuencias legales y financieras: precios que se hacen públicos, firmas que se copian y disputas que se vuelven feas rápido. Una copia de un documento de identidad robada puede llevar a robo de identidad y toma de cuentas. Los documentos médicos pueden exponer detalles privados de salud que la gente nunca esperó compartir fuera de un círculo pequeño. Un error puede dañar la confianza durante años.
Los equipos suelen decir “almacenamiento cifrado” queriendo decir cosas diferentes. A veces se refieren a que la conexión de subida está cifrada (HTTPS). Otras, a que el archivo está cifrado en disco (cifrado en reposo). Otras, a que el archivo se cifra antes de salir del dispositivo del usuario, de modo que el servidor nunca ve el texto plano (cifrado del lado del cliente). No son intercambiables. Protegen frente a fallos distintos.
Las decisiones de seguridad también moldean la usabilidad y soporte diario. Más privacidad puede significar más fricción: pasos extra para ver un archivo, compartir más complicado, búsqueda y vistas previas limitadas y recuperación dolorosa cuando alguien pierde un dispositivo o una clave. El acceso más fácil permite indexado, escaneo antivirus, vistas previas y restablecimiento de contraseñas, pero también aumenta lo que tu servidor (y quien lo comprometa) puede ver.
Imagina una pequeña clínica subiendo IDs de seguro y PDFs médicos. El personal necesita encontrar el archivo correcto rápido, pero la clínica también quiere reducir el daño si se hackea una cuenta administrativa. El “modelo correcto” depende de qué fallo dolerá más y de la incomodidad que los usuarios tolerarán.
La pregunta práctica es simple: ¿cuándo se cifra el archivo y quién puede descifrarlo después?
Cifrado del lado del servidor significa que el archivo llega a tu backend en forma legible y tu servidor lo cifra antes de guardarlo. Esto es cifrado en reposo: si alguien roba un disco o obtiene acceso bruto a un bucket de almacenamiento, verá datos encriptados. Tu servidor aún puede descifrar el archivo cuando hace falta.
Cifrado del lado del cliente significa que el archivo se cifra en el dispositivo del usuario (navegador o móvil) antes de subirlo. Tu servidor almacena solo el texto cifrado. En la operación normal, el servidor no puede leer el documento a menos que también tenga acceso a la clave de descifrado.
La propiedad de las claves es la verdadera línea divisoria:
En ambos modelos, todavía necesitas autenticación y permisos. El cifrado no sustituye al control de acceso.
La gente también usa “cifrado de extremo a extremo” para decir: el archivo se cifra en el dispositivo del remitente, permanece cifrado en el servidor y se descifra solo en el dispositivo de un destinatario aprobado. Eso puede mejorar la confidencialidad, pero hace que las vistas previas en el servidor, la búsqueda de texto completo, el escaneo antivirus y la recuperación fácil sean mucho más difíciles salvo que cambies el modelo de amenaza.
El cifrado solo ayuda cuando eres claro sobre los riesgos que quieres reducir. “Nadie excepto el usuario previsto puede leer el archivo” lleva a elecciones distintas que “reducir el daño si se filtra el almacenamiento”.
Amenazas comunes para apps que almacenan contratos, IDs o documentos médicos incluyen:
También ayuda separar dónde puede ocurrir la exposición:
Aquí está la diferencia central. Con cifrado del lado del servidor, tu sistema puede descifrar, por lo que puede generar vistas previas, escanear y indexar. Con cifrado del lado del cliente, el servidor almacena ciphertext y no puede leer el contenido sin las claves del usuario. Eso normalmente reduce el radio de impacto de compromisos del servidor y del acceso interno.
El cifrado no lo evita todo. Si un dispositivo está infectado, el malware puede capturar el archivo antes de cifrarlo o después de descifrarlo. Si alguien puede ver un documento, aún puede hacer una captura de pantalla, volver a compartirlo o imprimirlo.
Una forma útil de comparar es preguntar: ¿quién puede ver el archivo en texto plano en algún momento? Esa respuesta da forma al impacto de una brecha, al riesgo interno y a la seguridad de los backups.
Con cifrado del lado del servidor, una brecha del servidor puede seguir exponiendo mucho. El backend normalmente tiene acceso a las claves de descifrado (o puede solicitarlas) porque necesita generar vistas previas, ejecutar antivirus, soportar búsqueda o manejar compartición. En el peor caso, un atacante que obtiene datos y acceso a las claves puede descifrar todo.
Con cifrado del lado del cliente, un atacante que compromete tu infraestructura suele robar blobs cifrados. Sin claves en manos del atacante, esos blobs son mucho menos útiles.
El acceso interno es donde la diferencia se vuelve más visible. Con cifrado del lado del servidor, un empleado privilegiado, admin de la nube o una cuenta de soporte comprometida suele poder acceder a documentos al suplantar la app o consultar el almacenamiento. Con cifrado del lado del cliente, tu infraestructura puede almacenar y mover archivos, pero no puede leerlos a menos que se proporcionen las claves.
El cifrado del lado del cliente no arregla un dispositivo hackeado. Para subidas de alto riesgo como IDs y PDFs médicos, la seguridad del dispositivo y la protección de cuentas importan tanto como el cifrado del almacenamiento.
También vigila las fugas fuera del “almacenamiento de archivos”. Muchos incidentes ocurren por:
La mayor diferencia no es la matemática. Es lo que los usuarios pueden hacer fácilmente y lo que se vuelve difícil.
El cifrado del lado del servidor suele ser invisible. Los usuarios inician sesión, suben y ven vistas previas inmediatamente. El soporte puede restablecer accesos. Los supervisores suelen poder reasignar permisos cuando alguien está de baja.
El cifrado del lado del cliente cambia la incorporación y el trabajo diario. Los usuarios pueden necesitar una frase de paso más fuerte, una clave local guardada en un dispositivo o un paso extra para desbloquear. Cambiar de dispositivo, limpiar un navegador o reinstalar una app puede romper el acceso a menos que planifiques copia y recuperación de claves.
La recuperación de cuentas sorprende a muchos equipos. Si solo el usuario tiene la clave de descifrado, “Olvidé mi contraseña” puede convertirse en “accso perdido”. Puedes añadir una clave de recuperación o un flujo de custodia, pero debes ser honesto sobre lo que eso implica y explicarlo claramente.
Compartir también se complica. Con cifrado del lado del servidor, compartir suele ser cuestión de permisos. Con cifrado del lado del cliente, compartir normalmente implica compartir claves también, junto con decisiones sobre revocación y qué ocurre con copias antiguas.
La búsqueda y las funciones de conveniencia pueden forzar descifrado en algún lugar. Búsqueda de texto completo, vistas previas y OCR son más fáciles cuando el servidor puede leer el archivo. Si quieres privacidad estilo extremo a extremo, quizá necesites OCR del lado del cliente, indexado local o búsqueda limitada (por ejemplo, solo nombres de archivo y etiquetas).
Ejemplo: una clínica sube PDFs de laboratorio y quiere OCR para encontrar nombres de pacientes dentro de escaneos. El cifrado del lado del servidor facilita OCR y búsqueda rápidas. El cifrado del lado del cliente empuja ese trabajo a los dispositivos de los usuarios, lo que puede ser más lento y difícil de soportar en web y móvil.
La mejor elección depende menos del tipo de archivo y más del flujo de trabajo: quién necesita leerlo, con qué rapidez, con qué frecuencia y por cuánto tiempo.
Los contratos suelen implicar revisión, marcas, aprobaciones y pistas de auditoría. Los equipos también quieren búsqueda fiable, compartición y reglas de retención.
Si tu app soporta revisión colaborativa dentro del producto, el cifrado del lado del servidor suele ser el valor práctico por defecto porque el sistema puede renderizar vistas previas, ejecutar búsqueda y aplicar acceso basado en roles sin pedir a los usuarios que gestionen claves.
El cifrado del lado del cliente puede encajar si la app es principalmente una bóveda, por ejemplo para almacenar PDFs firmados finales para un pequeño grupo directivo. La contrapartida es menor conveniencia integrada a menos que añadas herramientas del lado del cliente.
Las IDs son de alto riesgo pero a menudo de vida corta. Muchos equipos solo las necesitan el tiempo suficiente para verificar a una persona y luego las eliminan. El flujo de trabajo es visualización rápida y manejo estricto, no colaboración.
Un enfoque común es cifrado del lado del servidor combinado con control de acceso estricto, registros de auditoría fuertes y retención corta. El cifrado del lado del cliente puede encajar si el personal de soporte nunca debe poder ver las IDs, pero entonces necesitas otra manera de completar la verificación.
Los registros médicos llevan expectativas de privacidad más fuertes. Los usuarios suelen asumir que solo un conjunto mínimo de personas puede verlos.
El cifrado del lado del cliente puede reducir la exposición si se compromete el servidor o se abusa del acceso administrativo. Pero también puede crear problemas reales de UX y operativos: restablecimientos de contraseña, cambios de dispositivo y acceso de emergencia se vuelven complicados.
Antes de elegir, mapea cada tipo de documento al flujo de trabajo:
Empieza escribiendo qué guardas y quién lo toca. Una carpeta llamada “uploads” no es una política.
Lista roles y responde dos preguntas: ¿quién debe poder abrir el archivo? y ¿quién nunca debe poder abrirlo (incluyendo admins)? Incluye la retención mientras lo haces.
Sé directo sobre contra qué te defiendes.
Luego presiónate con la experiencia:
Recuperación y soporte: ¿Qué pasa si alguien olvida la contraseña o pierde un teléfono? Si debes recuperar el acceso, el cifrado puramente del lado del cliente puede no encajar.
Funciones imprescindibles: ¿Necesitas vistas previas, búsqueda, OCR, firma electrónica o procesamiento vía API? Muchas de estas son más sencillas cuando el servidor puede leer el archivo.
Auditoría y cumplimiento: ¿Necesitas registros claros de quién accedió qué y cuándo? Ambos modelos pueden registrar accesos, pero los diseños del lado del cliente requieren cuidado extra para evitar resultados de “no podemos ayudarte”.
La mayoría de equipos acaban con un híbrido: cifrado del lado del servidor para la mayoría de documentos y cifrado del lado del cliente para un pequeño conjunto de subidas “nunca visibles para el personal”.
La mayor trampa es tratar al cifrado como toda la historia. La privacidad y el cumplimiento también dependen de quién puede acceder a los datos, cómo se aprueba el acceso, qué se registra, cuánto se conserva y cómo se gestionan las solicitudes de eliminación.
Un segundo gran fallo es construir cifrado del lado del cliente sin un plan de recuperación. Si un usuario pierde un dispositivo, olvida una frase de paso o abandona la empresa, ¿puedes restaurar el acceso sin romper tu promesa de seguridad? “No podemos ayudarte” puede ser aceptable para una bóveda personal, pero suele fracasar en apps de negocio.
Estos errores provocan fugas reales y soluciones improvisadas:
Ejemplo: una clínica cifra formularios de admisión, luego el personal exporta un informe de facturación que crea una carpeta local sin cifrar. Esa carpeta se copia en una unidad compartida. La filtración ocurre en el flujo de trabajo, no en la criptografía.
Escribe una oración clara: quién debería poder leer estos archivos y quién nunca debería poder hacerlo, incluso si alguien obtiene acceso a tus servidores.
Luego comprueba:
Una pequeña clínica tiene una app donde el personal sube referencias de pacientes (PDFs) y fotos de IDs de seguro. El objetivo es mover documentos a las personas correctas rápidamente, reduciendo daño por dispositivos perdidos, cuentas comprometidas o errores en la nube.
Un enfoque viable es cifrado del lado del servidor con roles estrictos. Los archivos se cifran en reposo y el acceso se controla por permisos: recepción puede subir, facturación puede ver IDs y clínicos pueden ver referencias. Esto suele ser más sencillo en el día a día porque el personal abre documentos en escritorio o móvil sin pasos extra y los supervisores pueden reasignar accesos durante ausencias.
Otra opción usa cifrado del lado del cliente para los ítems más sensibles. El archivo se cifra en el dispositivo antes de subirlo, de modo que el servidor almacena ciphertext. Esto puede reducir el impacto de brechas de servidor y del acceso interno, pero cambia operaciones:
Los usuarios notan fricción al compartir, acceder desde móvil y recuperar acceso tras perder un teléfono. Esos detalles importan tanto como el modelo de cifrado en sí.
Empieza por escribir tus suposiciones de amenaza en lenguaje claro. Elige el enfoque más simple que satisfaga tu riesgo y endurece solo donde los documentos realmente lo justifiquen.
Pon la decisión en un conjunto corto de reglas internas que la gente pueda seguir:
Luego diseña la implementación en torno a esas reglas: comprobaciones de rol, acciones auditadas (ver, descargar, compartir), vistas seguras y manejo cuidadoso de claves.
Si construyes sobre una plataforma sin código como AppMaster (appmaster.io), ayuda modelar roles y flujos de aprobación temprano y luego ajustarlos según cambien los requisitos sin reescribir toda la app. Lo importante es hacer que la ruta segura sea la ruta fácil para usuarios reales.
When should I choose client-side encryption instead of server-side encryption?Usa server-side encryption cuando necesites vistas previas fluidas, OCR, escaneo antivirus y recuperación de cuenta sencilla. Usa client-side encryption cuando reducir el riesgo interno y limitar lo que tus servidores pueden leer sea más importante que la comodidad.
Is HTTPS the same as “encrypted storage” for uploads?No. HTTPS protege el archivo en tránsito mientras viaja por la red. Aún necesitas encryption at rest y un buen control de accesos para proteger los archivos en almacenamiento, copias de seguridad y sistemas internos.
What does server-side encryption actually protect against?El cifrado del lado del servidor protege principalmente si alguien obtiene acceso bruto al almacenamiento (por ejemplo, un bucket filtrado, un disco robado o una copia de seguridad expuesta). No impide que alguien que tenga acceso al backend o a las claves descifre los archivos.
What does client-side encryption actually protect against?El cifrado del lado del cliente ayuda especialmente cuando tu servidor, administradores o cuenta en la nube podrían verse comprometidos, porque el servidor solo almacena datos cifrados. No protege si el dispositivo del usuario está infectado o si el usuario comparte el archivo ya descifrado.
How do I handle password resets and device loss with client-side encryption?Si no diseñas una recuperación, los usuarios pueden perder el acceso de forma permanente tras la pérdida de un dispositivo, un restablecimiento del navegador o una frase de paso olvidada. Un buen punto de partida es definir un método de recuperación claro (como una clave de recuperación o un flujo de custodia aprobado) y explicar honestamente las compensaciones.
How does encryption choice affect sharing files with coworkers?El cifrado del lado del servidor mantiene el intercambio mayormente en permisos, porque el servidor puede descifrar para usuarios autorizados. El cifrado del lado del cliente suele requerir intercambio de claves y reglas de revocación, lo que añade complejidad al acceso en grupo y al offboarding.
Will client-side encryption break OCR and full-text search?Normalmente sí, porque OCR y búsqueda de texto completo requieren leer el contenido del documento. Con cifrado del lado del cliente, o bien haces ese trabajo en el dispositivo (más difícil de soportar) o aceptas una búsqueda limitada (por ejemplo, solo nombres de archivo y etiquetas).
What’s the best approach for storing passport or driver’s license uploads?Por defecto, opta por cifrado del lado del servidor con roles estrictos, retención corta y auditoría fuerte si el personal debe ver las IDs rápidamente. Considera el cifrado del lado del cliente solo si el personal nunca debe poder ver las IDs y dispones de un flujo alternativo para verificar identidades.
How should I treat contracts compared to other document types?Si necesitas flujos de equipo (revisión, aprobaciones, auditoría, vistas previas), el cifrado del lado del servidor suele ser la base práctica. Si es más bien una bóveda privada para un grupo pequeño, el cifrado del lado del cliente puede funcionar, pero espera fricción adicional en acceso y compartición.
What’s a simple way to decide on an encryption model for my app?Empieza listando quién debe poder abrir cada tipo de documento y quién nunca debe poder hacerlo, incluso con acceso de administrador. Luego decide dónde se permite el descifrado (servidor, cliente o ambos), define la retención y asegúrate de que tus registros capturen eventos de vista y descarga.
27 ene 2026
8 min
26 ene 20268 min
21 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
