Existe una expresión que resume bien el día en que una aplicación es vulnerada: que te pillen con los pantalones bajados. Es ese momento en el que el problema ya ocurrió y ya no puedes fingir que todo estaba bajo control. Con ese espíritu —directo y sin alarmismo innecesario— Danrley Pereira y Pedro Druck subieron al escenario de la sala DW Corp en Campus Party Brasil 2025 (CPBR17), en Brasilia, para hablar sobre seguridad web en la práctica.
Este resumen intenta mantener el mismo tono de la charla: nada de jerga intimidante, solo lo esencial que todo desarrollador debería saber antes de poner algo en producción.
La seguridad no es un lujo de seniors
Una idea atravesó toda la sesión: la seguridad no es una etapa que se activa al final del proyecto ni una tarea exclusiva de personas senior. Comienza en la primera línea de código. Cuanto antes pienses en cómo se puede abusar de tu aplicación, más barato y sencillo será protegerla.
La buena noticia es que la mayoría de los ataques del mundo real no son sofisticados. Son los mismos errores repetidos, y ya existe un mapa para identificarlos.
OWASP Top 10 en un lenguaje claro
Ese mapa es OWASP Top 10: una lista mantenida por la comunidad con las categorías de vulnerabilidades más comunes en aplicaciones web. Piensa en ella como una checklist de lo que suele salir mal: fallos de control de acceso, exposición de datos sensibles, inyecciones, configuraciones de seguridad incorrectas, componentes desactualizados, entre otros.
El valor de la lista no está en memorizarla, sino en utilizarla como una lente. Antes de lanzar una feature, conviene preguntarse: ¿en qué puntos toca este cambio cada uno de esos riesgos? Así fue como Danrley y Pedro guiaron a la audiencia: tomaron elementos del Top 10 y mostraron cómo aparecen en el código del día a día.
Inyecciones: el clásico que todavía derriba sistemas
Una inyección ocurre cuando los datos enviados por el usuario se interpretan como un comando. El ejemplo clásico es SQL injection: un campo de búsqueda aparentemente inocente que, si se maneja mal, permite reescribir la consulta a la base de datos. Pero el principio se aplica a cualquier lugar donde una entrada se convierte en ejecución: comandos, HTML o consultas.
La defensa mostrada en la práctica fue sencilla y consistente: nunca confíes en la entrada del usuario. En el back-end con Flask, esto significa utilizar consultas parametrizadas en lugar de concatenar strings de SQL, además de validar todo lo que llega. En el front con React, significa no inyectar HTML sin procesar proveniente del usuario y dejar que el propio framework escape el contenido. La regla de oro: trata todo dato externo como sospechoso hasta demostrar lo contrario.
Control de acceso: quién puede hacer qué
Otro campeón de los incidentes es el control de acceso roto: ocurre cuando el sistema olvida comprobar si ese usuario realmente puede realizar una acción. Es el caso clásico de cambiar un id en la URL y terminar viendo el pedido de otra persona.
El punto planteado en el escenario fue que autenticación y autorización son cosas diferentes. Autenticar es saber quién es el usuario; autorizar es decidir qué puede hacer. Ocultar un botón en el front no es seguridad: la comprobación de permisos debe realizarse siempre en el servidor, en cada solicitud.
OAuth2 y JWT sin misticismo
La parte que generó más preguntas fue la relacionada con el login. OAuth2 y JWT suelen sonar místicos, pero la dupla los explicó con analogías sencillas.
OAuth2 es un protocolo de autorización: en lugar de dar tu contraseña a cada aplicación, autorizas que reciba una “tarjeta de acceso” con permisos limitados. Es lo que ocurre cuando eliges “Iniciar sesión con Google”.
JWT (JSON Web Token) es el formato de esa tarjeta: un token firmado que contiene información sobre quién eres y qué puedes hacer. Como está firmado, el servidor puede verificar si fue alterado. En el ejemplo con React y Flask, el front guarda el token y lo envía en cada solicitud; el back en Flask valida la firma y la expiración antes de permitir cualquier acción. Las precauciones destacadas fueron: no incluir datos sensibles dentro del token, definir una expiración corta y validar siempre en el servidor; nunca confiar únicamente en lo que dice el cliente.
Qué llevarse a casa
El mensaje final de Danrley y Pedro fue tranquilizador: no necesitas ser especialista en seguridad para elevar mucho el nivel de tu aplicación. Necesitas adoptar algunos hábitos: desconfiar de la entrada del usuario, comprobar los permisos en el servidor, entender qué contienen tus tokens y mantener las dependencias actualizadas.
La seguridad tiene menos que ver con la paranoia y más con el cuidado constante. Y ocuparse de ella desde el principio es la mejor manera de que nunca te pillen con los pantalones bajados.
