Seguridad de aplicaciones web: la arquitectura explicada para principiantes

Quienes empiezan a desarrollar para la web tienden a imaginar la seguridad como algo que se añade al final: un antivirus, un firewall, un complemento. Es una imagen cómoda y completamente errónea. La seguridad no es una pieza que encaja en el producto terminado, es una propiedad de la forma en que se construyó el producto.

La diferencia es fundamental. Una aplicación web es como una casa. No se hace que una casa sea segura instalando una costosa cerradura en la puerta de entrada si las paredes son de cartón y las ventanas no cierran. La seguridad viene de la estructura, no de un accesorio pegado encima.

Este artículo explica, sin asumir conocimientos previos, cómo la arquitectura de una aplicación web determina su seguridad. Es para principiantes que desean comprender los fundamentos correctos desde el principio, antes de adquirir hábitos que luego resultan costosos de deshacer.

La anatomía de una aplicación web

Para hablar de seguridad, primero hay que entender a las partes. Una aplicación web tiene, en pocas palabras, tres capas, y cada una tiene su función en la seguridad.

El cliente es lo que se ejecuta en el navegador del usuario: las pantallas, los botones, lo que la persona ve y toca. El servidor es donde ocurre la verdadera lógica, lejos de los ojos del usuario. Y la base de datos es donde se almacena la información.

Entre estas capas, los datos viajan a través de la red. Esta sencilla estructura ya contiene la lección de seguridad más importante para principiantes, y ahí es donde comenzaremos.

La regla de oro: nunca confiar en el cliente

Si recuerda solo un principio de este artículo, recuerde esto: todo lo que se ejecuta en el navegador del usuario está bajo el control del usuario y, por lo tanto, puede ser manipulado. El cliente es territorio enemigo.

Los principiantes cometen el error de imponer controles de seguridad al cliente. Validan el formulario en el navegador, ocultan un botón a quienes no tienen permiso, verifican si el valor es válido en la pantalla. Todo esto es bueno para la experiencia del usuario y absolutamente inútil para la seguridad. Un atacante simplemente ignora la pantalla y habla directamente con el servidor, enviando lo que quiere.

La consecuencia arquitectónica es clara: cada decisión de seguridad debe tomarse en el servidor. Validación de datos, verificación de permisos, reglas comerciales, todo esto reside en el servidor, donde el usuario no puede acceder. El cliente sugiere; el servidor decide. Esta separación es la columna vertebral de la seguridad web.

Los dos pilares: quién eres y qué puedes

Prácticamente toda la seguridad de las aplicaciones se basa en dos conceptos que los principiantes suelen confundir.

Autenticación es demostrar quién eres. Es el inicio de sesión: nombre de usuario y contraseña, quizás un segundo factor. Responde a la pregunta “¿eres realmente quien dices ser?”.

Autorización es definir lo que puedes hacer una vez identificado. Responde a la pregunta "¿puedes hacer esto?"

La confusión entre ambos genera uno de los fallos más comunes que existen. Un sistema confirma el inicio de sesión (autenticación) pero se olvida de comprobar, en cada acción, si ese usuario tiene derecho a esos datos (autorización). El resultado es el clásico ataque de cambiar un número en la URL y acceder a la información de otra persona, una falla que ha estado en lo más alto de las listas de OWASP durante años.

En arquitectura, esto significa dos controles distintos. No basta con confirmar la identidad en la entrada. El permiso debe verificarse cada vez que se accede a un recurso. Olvidar el segundo es como revisar la placa de quien entra al edificio pero dejar todas las habitaciones abiertas.

Protección de datos en tránsito y en reposo

Los datos de una aplicación existen en dos estados y ambos necesitan protección.

En tránsito es cuando los datos viajan entre el cliente y el servidor a través de la red. Aquí la protección es el cifrado de la comunicación, vía HTTPS. Sin esto, cualquier persona en una red compartida, una Wi-Fi pública, por ejemplo, puede interceptar y leer lo que se transmite, incluidas las contraseñas. HTTPS hoy es un estándar básico y no negociable.

En reposo es cuando los datos se almacenan en la base de datos. La protección más importante que deben comprender los principiantes es el manejo de las contraseñas: nunca deben almacenarse mientras el usuario las escribe. Pasan por un proceso llamado hash, que los transforma en algo irreversible. Entonces, incluso si se filtra el banco, las contraseñas no son legibles. Guardar contraseñas en texto plano es quizás el pecado mortal más común entre los principiantes.

Las amenazas clásicas que previene la arquitectura

Algunas categorías de ataques son tan comunes que todo principiante debería conocerlas por su nombre. Aparecen en la lista OWASP, la referencia mundial de riesgos de aplicaciones web.

La inyección ocurre cuando el sistema interpreta los datos enviados por el usuario como comandos. El caso clásico es la inyección SQL, donde se utiliza un campo de formulario para engañar a la base de datos. La defensa arquitectónica es nunca mezclar datos del usuario con comandos directamente, tratando siempre la entrada como datos, nunca como instrucción.

Las secuencias de comandos entre sitios (XSS) ocurren cuando el código malicioso enviado por un usuario termina ejecutándose en el navegador de otro. La defensa consiste en tratar y escapar de todo lo que viene del exterior antes de mostrarlo en pantalla.

El patrón común de estas amenazas es el mismo principio que antes: los datos provenientes del exterior no son confiables y deben validarse y procesarse en el servidor antes de cualquier uso. La arquitectura segura es, en gran medida, una arquitectura que desconfía sistemáticamente de las entradas.

Reflexión para quienes recién comienzan

La trampa mental más peligrosa para el principiante es "mi proyecto es demasiado pequeño para atacarlo". Es exactamente lo contrario. La mayoría de los ataques no eligen objetivos, son robots automatizados que escanean Internet en busca de fallas conocidas. Un proyecto pequeño y mal protegido es precisamente el objetivo más fácil para estos análisis. Nadie necesita querer atacarte; todo lo que se necesita es una puerta abierta encontrada por casualidad.

También existe la dimensión legal que los principiantes ignoran. En Brasil, la LGPD responsabiliza a quienes recopilan datos de las personas de protegerlos, independientemente del tamaño del proyecto. Construir de forma segura desde el principio no es solo una buena práctica técnica, es una responsabilidad legal y ética para con las personas que le confiaron sus datos.

No es necesario dominarlo todo para empezar bien. Los fundamentos arquitectónicos, nunca confiar en el cliente, separar la autenticación de la autorización, cifrar la comunicación, proteger las contraseñas, validar todas las entradas, ya colocan a un principiante por delante de una gran cantidad de aplicaciones en el mercado. La seguridad, al principio, se trata menos de técnicas avanzadas y más de no cometer los errores básicos que sabes cómo evitar.

Aprender a sacar provecho de forma segura desde el primer proyecto es una inversión que se amortiza muchas veces. Rehacer un sistema construido sin estos cimientos es costoso y doloroso; construirlo desde el principio es sólo una cuestión de hábito.

Si está comenzando a desarrollar para la web y desea construir sobre la base adecuada, hay otros artículos de blog sobre autenticación, OWASP, LGPD y arquitectura segura que profundizan en cada uno de estos puntos. Si es un momento de aprendizaje o de toma de decisiones en tu organización, vale la pena hablar de ello.