Cada aplicación web es, en la práctica, una puerta abierta al mundo. Puedes abrir la cerradura o dejar la llave debajo de la alfombra. La mayoría de equipos, sin darse cuenta, eligen la segunda opción, no por incompetencia, sino porque rara vez se trata la seguridad como un requisito desde el principio.
La pregunta que le hago a cualquier equipo es sencilla: si un atacante decidiera atacarte hoy, ¿cuánto tiempo tardaría? La respuesta honesta suele resultar incómoda. Y el problema casi nunca es la falta de tecnología. Es una falta de fundamento.
Este artículo trata sobre esos conceptos básicos. No se trata de la herramienta de moda, sino de los principios que sustentan una aplicación web que merece confianza.
Por qué la seguridad se ha convertido en un problema empresarial
Hubo un tiempo en el que la seguridad era un tema restringido al equipo de infraestructura. Hoy es un problema de CEO, junta directiva y reputación.
Una fuga de datos no es sólo un error. Es un titular, es una multa, es un cliente perdido. En Brasil, la LGPD trajo consecuencias concretas para quienes tratan datos personales de manera descuidada. Pero incluso sin regulación, el coste de un incidente siempre ha sido alto y sólo se ha vuelto más visible.
La cuestión es que la seguridad ha dejado de ser un detalle técnico y se ha convertido en una variable de negocio. Quienes lideran productos o tecnología deben entender esto para decidir dónde invertir.
La tesis: la seguridad es arquitectura, no barniz
Mi posición es sencilla. La seguridad no es una capa que se agrega una vez que el producto está listo. Es una propiedad que surge de las decisiones que tomas desde el principio.
Los equipos que tratan la seguridad como una tarea final, una revisión antes del lanzamiento, una prueba de penetración apresurada, simplemente están comprando la ilusión de protección. La prueba de la pluma encuentra los síntomas. La arquitectura define si la enfermedad existe.
Cuando la seguridad es fundamental, aparece en cómo modela los datos, en cómo autentica a los usuarios, en cómo confía (o desconfía) de las entradas. Cuando es barniz, aparece en un informe que nadie lee.
Los fundamentos que realmente importan
Seré pragmático. Hay docenas de temas posibles, pero unos pocos fundamentos resuelven la mayoría de los problemas reales.
Nunca confíes en la entrada del usuario
La mayoría de las vulnerabilidades clásicas, inyección SQL, cross-site scripting, manipulación de parámetros, nacen del mismo error: confiar en datos que provienen del exterior.
La regla es simple e innegociable: toda entrada es hostil hasta que se demuestre lo contrario. Validar en el servidor, siempre. La validación en el navegador es la experiencia del usuario, no la seguridad, y es trivialmente evitable.
Utilice consultas parametrizadas en la base de datos. Salidas de escape según el contexto. Trate las cargas de archivos como código potencialmente malicioso. Estas precauciones parecen obvias, pero siguen siendo causa de incidentes que son noticia.
La autenticación y la autorización son cosas diferentes
La autenticación responde "¿quién eres?". La autorización responde "¿qué puedes hacer?". Confundirlos es una receta para el desastre.
El error más común que veo: aplicaciones que verifican si el usuario ha iniciado sesión, pero no verifican si tiene permiso para acceder a ese recurso específico. El resultado es el problema clásico en el que el usuario A puede ver los datos del usuario B simplemente cambiando un número en la URL.
La autorización debe verificarse en el servidor, en cada solicitud confidencial, nunca se debe asumir en función de lo que muestra la interfaz. Ocultar un botón no protege nada.
Administrar secretos como secretos
Contraseñas, claves API, tokens de acceso. Estos datos no pertenecen al código fuente, no pertenecen al repositorio y definitivamente no pertenecen a un archivo de configuración versionado.
Las contraseñas de los usuarios deben almacenarse con algoritmos hash diseñados para tal fin, no con cifrado reversible y mucho menos en texto plano. Utilice bibliotecas consolidadas. El cifrado casero es una de las formas más rápidas de crear un problema que no detectará hasta que sea demasiado tarde.
El cifrado en tránsito no es opcional
Todo el tráfico debe utilizar HTTPS. Hoy en día no existe ninguna justificación razonable para lo contrario. Los datos que viajan sin cifrado pueden ser interceptados, y esto incluye las credenciales.
Pero tenga cuidado: HTTPS protege la ruta, no el destino. Una aplicación puede tener un candado verde en el navegador y aún almacenar contraseñas en texto sin formato. El cifrado en tránsito y en reposo son capas distintas y ambas importan.
Lo que nos enseña OWASP
Cuando alguien me pregunta por dónde empezar, mi respuesta casi siempre es la misma: empezar por OWASP.
El OWASP Top 10 es una lista de las vulnerabilidades más críticas en aplicaciones web, mantenida por la comunidad y actualizada periódicamente. No es un estándar burocrático, es un mapa de amenazas que realmente causan daño.
Su valor no está en memorizar la lista, sino en utilizarla como lenguaje común dentro del equipo. Cuando todos comprenden qué es un control de acceso roto o una configuración de seguridad fallida, las conversaciones técnicas se vuelven más objetivas y las decisiones se vuelven más informadas.
Recomiendo hacer que el Top 10 forme parte del proceso: una revisión ligera pero consistente que pregunte "¿estamos expuestos a alguno de estos riesgos?" antes de cada entrega relevante.
##Errores culturales que sabotean la seguridad
La parte más difícil de la seguridad no es técnica. Es cultural.
El primer error es tratar la seguridad como responsabilidad de una persona o de un equipo aislado. La seguridad es responsabilidad de quienes escriben el código, quienes diseñan los productos y quienes priorizan el trabajo pendiente. Cuando se convierte en el trabajo de alguien, no se convierte en el trabajo de nadie.
El segundo error es el teatro de seguridad: políticas extensas que nadie sigue, procesos que existen en el documento pero no a diario. La verdadera seguridad es discreta y operativa, no un manual guardado en un cajón.
El tercero, y quizás el más peligroso, es la falsa sensación de que "eso no me sucederá a mí". Las aplicaciones pequeñas son atacadas todo el tiempo, a menudo mediante una automatización que no elige un objetivo. Ser pequeño no es protección.
La seguridad como ventaja, no como coste
Hay una mejor manera de ver todo esto. La seguridad bien hecha no es sólo defensa, es una diferencia.
En sectores que manejan datos confidenciales, como la atención médica, las finanzas y el sector público, la confianza es moneda de cambio. Un producto que demuestra cuidado con los datos obtiene una ventaja sobre un competidor que trata el tema con indiferencia. Para los gestores públicos esto es aún más crítico: los datos de los ciudadanos no son un activo de la organización, son una responsabilidad.
Invertir en fundamentos de seguridad no detiene la innovación. Al contrario, te proporciona una base sólida sobre la que puedes construir rápidamente sin miedo a que todo se derrumbe.
La seguridad no es lo que haces cuando tienes tiempo. Es lo que define si el producto que estás creando merece existir.
Si su organización está desarrollando aplicaciones web y la seguridad aún es un tema que queda para el final, vale la pena revisar esta prioridad. Tengo otros artículos en el blog sobre LGPD, criptografía y arquitectura segura, y siempre estoy abierto a intercambiar ideas con cualquiera que tome este tema en serio.
Lea también
- Vulnerabilidades en las aplicaciones: por qué persisten y cómo liderar la defensa
- Al crear una aplicación: seguridad que los principiantes no pueden ignorar
- Seguridad en aplicaciones web: la arquitectura explicada para principiantes
- Seguridad en aplicaciones móviles: fundamentos para proteger datos y usuarios
- Recomendación de contenido: seguridad y privacidad cuando el sistema escala
- Seguridad API: los pasos imprescindibles para no dejar la puerta abierta