Una aplicación debe funcionar bien y proteger tanto a quienes la usan como a quien la desarrolla o administra.
🛡️ Seguridad de aplicaciones (AppSec)
Es el conjunto de prácticas para prevenir, detectar y corregir vulnerabilidades en el software. Su objetivo es proteger los datos, las funciones y los recursos de una aplicación frente a accesos, cambios y usos no autorizados.
Esto protege tanto a quienes usan la aplicación como a quienes la desarrollan y administran.
No existe una aplicación completamente segura. El objetivo es prevenir problemas, limitar el daño y poder recuperarse.
1. ¿Qué necesitas proteger?
En seguridad, un activo es algo que tiene valor para ti o para tus usuarios —información, una cuenta o un servicio—, según la definición de NIST.
En tu aplicación, identifica por ejemplo:
- Datos de clientes: alguien podría robar sus domicilios o borrar sus pedidos.
- Tu cuenta de administrador: alguien podría tomar el control y cambiar la aplicación.
- Tus llaves privadas de API: alguien podría usar servicios que tú pagas.
- Tu código: alguien podría modificarlo para que la app haga algo que no autorizaste.
Haz una lista de los recursos que usa tu app y anota qué daño causaría que alguien los usara sin permiso.
La protección depende del recurso: cualquiera puede leer la descripción pública de un producto, pero solo una persona autorizada debería poder cambiarla.
2. Las tres bases de la seguridad
Según NIST, proteger la información implica cuidar tres cosas:
- Confidencialidad: Un recurso solo se debe ver por los usuarios que tienen permiso asignado a él. Un cliente no debe consultar los datos de otro.
- Integridad: que no se cambie ni borre nada de forma indebida. Un cliente no debe modificar el precio antes de pagar.
- Disponibilidad: que los usuarios autorizados puedan usar el servicio cuando lo necesitan.
Una sola falla puede afectar las tres. Por ejemplo, una cuenta administrativa robada podría permitir leer datos, cambiarlos y apagar el servicio.
3. Amenaza, vulnerabilidad, riesgo y control
- Vulnerabilidad: una debilidad del sistema.
- Amenaza: algo que puede causar daño.
- Riesgo: qué tan probable es un problema y qué tan grave sería.
- Control: una medida para evitarlo o reducir sus consecuencias.
Imagina que tu cuenta de administrador usa la contraseña 123456:
- Vulnerabilidad (la debilidad): la contraseña es fácil de adivinar.
- Amenaza (lo que puede ocurrir): alguien intenta adivinarla para entrar sin permiso.
- Riesgo (la probabilidad y el daño): qué tan probable es que consiga entrar y qué podría hacer después, como borrar datos o usar servicios que tú pagas.
- Control (la protección): activar un segundo factor de autenticación, para que conocer la contraseña no sea suficiente para entrar.
4. Autenticación y autorización
La autenticación comprueba quién eres, por ejemplo, al iniciar sesión.
La autorización determina qué puedes hacer. Ser cliente de una tienda no te da permiso para modificar productos o consultar pedidos ajenos.
Los permisos deben comprobarse en cada operación. Ocultar un botón no basta: alguien podría enviar la solicitud directamente al servidor, como advierte OWASP.
Aquí aplica el mínimo privilegio: dar solo los permisos necesarios. Si un servicio únicamente necesita leer datos, no debería poder borrarlos.
5. Validación de entradas e inyección
La validación de entradas comprueba que los datos recibidos cumplen con lo esperado: cantidades positivas, fechas válidas o formatos de archivos correctos.
Una inyección ocurre cuando la aplicación toma lo que alguien escribe como una orden que debe ejecutar. Por ejemplo, un atacante podría escribir código en un buscador para intentar obtener datos privados de la base de datos.
Para evitar ese tipo de ataque se usan consultas parametrizadas: hacen que la base de datos trate lo escrito como un valor que debe buscar, aunque contenga código, y no como una nueva orden.
Revisar que los campos del formulario tengan un formato válido también ayuda, pero no sustituye esta protección.
6. Cifrado, contraseñas y secretos
El cifrado protege la información para que no pueda leerse sin la llave adecuada:
- En tránsito: mientras viaja, por ejemplo, mediante HTTPS.
- En reposo: mientras está guardada en archivos o bases de datos.
Las contraseñas de usuarios no deben guardarse como texto legible. Se usan funciones de hash para contraseñas, que permiten comprobarlas sin conservar su texto original.
Los secretos, como contraseñas de bases de datos y llaves privadas de API, deben guardarse en herramientas o configuraciones seguras del servidor. No deben aparecer en el código ni llegar al navegador.
7. Dependencias y configuración
Las dependencias son paquetes de código creados por otras personas que utiliza tu app. Sus fallas también pueden afectarte. Mantén un inventario, revisa actualizaciones y pruébalas antes de publicarlas.
La configuración también importa: una carpeta pública por error puede exponer datos aunque el código funcione bien.
Si la aplicación no puede comprobar un permiso, debe rechazar la operación. Esto se llama fallar de forma segura.
8. Detectar problemas y recuperarse
Los registros o logs guardan eventos como errores y cambios importantes. Las alertas avisan cuando algo necesita atención.
No deben incluir contraseñas ni llaves privadas.
Los respaldos permiten recuperar datos, pero hay que probar que funcionan. Tener una copia no sirve de mucho si no sabes restaurarla.
9. Hice una app con IA. ¿Qué reviso primero?
Abre la carpeta principal (la raíz) de tu proyecto en una herramienta de IA con acceso al código. Copia y pega el siguiente prompt 👇
Revisa todo el código del proyecto, sus dependencias y la configuración disponible, sin modificar nada.
Busca vulnerabilidades que puedan afectar a mis usuarios o a mí: acceso a datos ajenos, robo de cuentas, secretos expuestos, cambios sin permiso o uso de servicios que genere gastos.
Para cada problema, explica en lenguaje sencillo:
- Vulnerabilidad: qué falla y en qué archivo está. Muestra evidencia sin revelar contraseñas ni llaves privadas.
- Amenaza: cómo podría alguien aprovechar esa falla.
- Riesgo: qué daño podría causar y qué tan fácil sería aprovecharla.
- Control: qué protección existe, si es suficiente y cómo corregir el problema.
Presenta primero los problemas de riesgo alto y explica por qué tienen esa prioridad. Distingue los problemas comprobados de las sospechas e indica cómo verificar estas últimas de forma segura.
Termina con una lista de correcciones en orden de prioridad y señala qué partes no pudiste revisar. No hagas pruebas contra servicios en producción.
Este es un primer paso para revisar el código, una de las prácticas que contempla el SSDF de NIST. La IA puede pasar por alto problemas y no necesariamente ve la configuración real de tus servicios. Que no encuentre fallas no demuestra que la app sea segura.
Para terminar
Ya tienes el vocabulario para razonar sobre riesgos (activos, amenaza, vulnerabilidad, riesgo, control), sabes dónde se esconden los descuidos más comunes (permisos, entradas, secretos, dependencias, configuración) y tienes un prompt para pedirle a tu IA que revise todo eso por ti.
Marca cada revisión como comprobada, falló o necesito ayuda. Que la IA diga "todo está bien" no sustituye una prueba.
Si manejarás pagos o información sensible, busca una revisión técnica antes de abrir la app al público.
Construir con IA puede acelerar el trabajo. Comprobar lo que construiste sigue siendo parte de él.