Tema 11
Toda aplicación web termina procesando información que puede ser privada, confidencial, financiera, médica, comercial o estratégica. Proteger esos datos no consiste solo en controlar accesos: también implica decidir qué guardar, cómo cifrarlo, dónde almacenarlo y cómo evitar exponerlo innecesariamente.
En muchas aplicaciones el valor principal está en los datos: identidad de usuarios, historiales, transacciones, documentos, información médica, registros internos, preferencias, números de contacto o credenciales. Si esa información se expone o altera, el impacto puede ser técnico, legal, reputacional y económico al mismo tiempo.
Por eso la seguridad de datos no se reduce a “poner contraseña al sistema”. Una aplicación madura necesita saber qué datos maneja, cuál es su sensibilidad, qué protección requiere cada tipo y por cuánto tiempo es realmente necesario conservarlo.
La mejor protección muchas veces empieza antes del cifrado: empieza cuando se cuestiona si ese dato debería existir en el sistema.
Se consideran sensibles aquellos datos cuyo acceso, exposición o alteración puede causar daño relevante a personas, organizaciones o procesos. La sensibilidad no depende solo del formato técnico, sino del contexto de negocio y del impacto de una filtración.
Ejemplos frecuentes:
No todos los datos necesitan el mismo nivel de protección. Una práctica útil es clasificarlos según sensibilidad y criticidad. Esto ayuda a decidir:
Uno de los principios más efectivos de protección es la minimización: recolectar, guardar y exponer solo lo estrictamente necesario para la finalidad del sistema.
Esto implica preguntarse:
Cuantos menos datos sensibles existan, menor será el impacto ante una brecha.
Muchas aplicaciones no “filtran” datos por una intrusión compleja, sino porque devuelven más información de la necesaria en respuestas, APIs, paneles o logs. Esta exposición excesiva es un error muy frecuente.
Algunos ejemplos:
El cifrado en tránsito protege los datos mientras viajan entre cliente y servidor o entre componentes del sistema. En la web, esto se logra principalmente con HTTPS y TLS.
Su función es reducir la posibilidad de que un tercero observe o modifique el contenido durante la comunicación. Es esencial para credenciales, sesiones, formularios, APIs y cualquier información sensible que se transmita.
Sin cifrado en tránsito, incluso una buena autenticación o una sesión segura pueden quedar expuestas al interceptarse el tráfico.
El cifrado en reposo protege datos almacenados en discos, bases de datos, backups o repositorios persistentes. Su objetivo es dificultar el acceso a la información si el medio es robado, copiado o expuesto indebidamente.
Es importante entender que no reemplaza el control de acceso de la aplicación. Ambos se complementan: uno protege el almacenamiento, el otro protege el uso legítimo del dato.
Estos conceptos suelen confundirse, pero sirven para propósitos distintos:
Por ejemplo, una contraseña no debería cifrarse para luego descifrarla, sino almacenarse mediante mecanismos de hashing diseñados para credenciales.
Las contraseñas merecen un tratamiento distinto del resto de los datos. No deberían guardarse de forma recuperable. La aplicación no necesita conocer la contraseña original, solo verificar que la proporcionada por el usuario coincida con la representación segura almacenada.
Esto implica usar funciones de hashing adecuadas para contraseñas, con costo apropiado y salt. Guardarlas en texto plano o cifradas de forma reversible es una práctica grave.
Además de datos de usuario, una aplicación también necesita proteger secretos internos: claves API, credenciales de base de datos, secretos de firma, tokens de integración, certificados o configuraciones críticas.
Errores comunes incluyen:
El cifrado es tan fuerte como la protección de sus claves. Si la clave está expuesta junto con los datos, el beneficio práctico cae drásticamente. Por eso la gestión de claves debe considerarse parte central del diseño de seguridad.
Algunos principios útiles:
No siempre hace falta mostrar un dato completo. En muchos casos es preferible aplicar técnicas de minimización visual, como truncar, enmascarar o mostrar solo partes relevantes.
Ejemplos:
Esto reduce exposición innecesaria sin impedir la operación legítima.
Los logs son fundamentales para detectar incidentes, pero si se diseñan mal pueden convertirse en una fuente de filtración. Registrar cuerpos completos, tokens, cookies, claves o datos personales innecesarios crea nuevos riesgos.
Una estrategia madura busca registrar suficiente contexto para operar y auditar, pero evitando volcar información más sensible de la necesaria.
Las copias de seguridad también contienen información sensible. Muchas veces se protegen menos que el sistema principal y, sin embargo, concentran grandes volúmenes de datos históricos.
Por eso los backups deben considerarse parte del mismo problema de seguridad:
Guardar datos indefinidamente “por las dudas” incrementa riesgo y complejidad. Una política madura define cuánto tiempo se conserva cada tipo de información y cómo se elimina de manera consistente cuando ya no hace falta.
Esto reduce superficie y también ayuda en cumplimiento normativo y en gestión de incidentes.
Imaginemos una plataforma de salud que devuelve en una API todos los campos del paciente, aunque la pantalla solo use nombre y próxima cita. Si un usuario logra un acceso indebido por un error de autorización, la exposición será mucho mayor de la necesaria porque la aplicación ya estaba devolviendo datos médicos completos sin necesidad funcional.
Este ejemplo muestra que proteger datos también implica diseñar respuestas mínimas y no solo “cerrar bien” la base de datos.
Una estrategia madura suele combinar varias capas:
La protección de datos sensibles no depende de una única tecnología, sino de una cadena de decisiones responsables sobre qué información existe, cómo circula y cómo se conserva. Cuanto mejor diseñada esté esa cadena, menor será el impacto si falla otra capa como autenticación, autorización o sesión.
En el próximo tema veremos configuración segura, cabeceras HTTP y hardening de la aplicación, para seguir reforzando la superficie de defensa desde el despliegue y la respuesta del servidor.