Guía gratuita · Iván Studio

Su app hecha con IA funciona.

¿Y es segura?

27 controles en 3 fases

La IA le escribe código que corre, pero no piensa en seguridad por defecto: le deja las claves a la vista y le cree todo lo que manda el usuario. Esta es la lista para revisar antes de publicar. Vaya marcando lo que ya tiene; la página se lo recuerda.

Su avance
0 / 27

FASE 01

Acceso y entrada los básicos

Quién entra y qué le deja escribir. Son los que más se olvidan porque "la app ya funciona".

  1. 01Autenticación robusta

    Correo y contraseña solos ya no alcanzan. Active la verificación en dos pasos desde el primer día y, si puede, deje entrar con Google o Apple.

  2. 02Las claves de API fuera del navegador

    Nunca ponga OPENAI_API_KEY ni ninguna clave en el frontend. Si se ve en las herramientas del navegador, ya es de cualquiera. Van en variables de entorno del servidor.

  3. 03Contraseñas con Argon2id

    Nada de MD5 ni SHA-256 para contraseñas. Argon2id es el estándar actual y es lento a propósito, para que adivinarlas por fuerza bruta no valga la pena.

  4. 04Validación en el servidor, siempre

    La validación del formulario es solo para que se vea bonito. Cualquiera se la salta mandando la petición directo. Todo se vuelve a validar en el backend.

  5. 05Protección contra XSS

    Si muestra texto que escribió un usuario, límpielo antes (por ejemplo con DOMPurify). Si no, alguien le mete un <script> que le roba las sesiones a sus usuarios.

  6. 06Registro de actividad sospechosa

    Guarde los intentos fallidos de entrar, los accesos al panel de administración y los cambios de contraseña. Si algo raro pasa a las 3 de la mañana, usted se tiene que enterar.

  7. 07Consultas parametrizadas

    Nunca arme la consulta pegando texto: "... WHERE id = " + id. Use parámetros. Así se cierra la puerta a la inyección SQL.

  8. 08Protección CSRF

    Un token único en cada formulario. Sin eso, otra página puede hacer que su usuario con sesión abierta borre su cuenta sin darse cuenta.

FASE 02

Datos y configuración los del medio

Cómo viaja la información y qué deja abierto el servidor.

  1. 09HTTPS obligatorio

    Sin certificado todo viaja en texto plano. Let's Encrypt es gratis y se renueva solo.

  2. 10Cookies de sesión seguras

    Márquelas con HttpOnly, Secure y SameSite. Así un script malicioso no las puede leer.

  3. 11Límite de intentos

    Ponga un tope de intentos de inicio de sesión por IP (por ejemplo, 5 por minuto). Sin eso, prueban contraseñas hasta que una entra.

  4. 12CORS cerrado

    Nada de Access-Control-Allow-Origin: *. Permita solo el dominio de su frontend.

  5. 13Encabezados de seguridad

    Content-Security-Policy, Strict-Transport-Security y X-Frame-Options. Son pocas líneas y cierran varios ataques comunes de una.

  6. 14Enlaces de recuperación que vencen

    El enlace de "olvidé mi contraseña" debe durar poco (15 minutos está bien) y servir una sola vez.

  7. 15Límites al subir archivos

    Tamaño máximo, solo los tipos que necesita y nunca ejecutables. Si no, le suben un .php y se toman el servidor.

  8. 16Pagos verificados en el servidor

    Nunca cobre el precio que manda el navegador. El backend recalcula el total antes de cobrar.

  9. 17Modo debug apagado en producción

    Con DEBUG=true los errores muestran rutas, versiones y a veces claves. Es regalarle el mapa a quien lo quiera atacar.

  10. 18Dependencias al día

    Corra npm audit (o una herramienta como Snyk) cada semana. Hay bots buscando librerías viejas con fallas conocidas.

  11. 19Archivos de configuración escondidos

    Compruebe que .env, .git y los respaldos no se puedan abrir desde el navegador. Pruebe sudominio.com/.env: tiene que dar error.

FASE 03

Mantenimiento los finales

La seguridad no se instala una vez: se revisa.

  1. 20Secretos borrados del historial de Git

    Si alguna vez subió una clave a GitHub y luego la borró, sigue en el historial. Límpielo con git filter-repo o BFG, y revise con gitleaks.

  2. 21Revocar la clave que se filtró

    Si cree que una clave se filtró, no espere: revóquela en OpenAI, AWS o Cloudflare y genere una nueva. Borrarla del código no basta.

  3. 22Auditoría completa

    Pase la app por OWASP ZAP o use el prompt de auditoría que está al final de esta guía.

  4. 23Informe de vulnerabilidades

    Un documento con lo que encontró, qué tan grave es, cómo se arregla y la fecha de la prueba. Es lo que piden los clientes grandes.

  5. 24Respaldo cifrado… y probado

    Tener respaldo no sirve si nunca probó restaurarlo. Hágalo una vez y salga de la duda.

  6. 25Panel de administración cerrado

    La ruta /admin no puede estar abierta para todos. Exige rol de administrador, revisado en el servidor.

  7. 26Ojo con cada librería nueva

    Cada npm install mete código de un desconocido. Antes de instalar, mire quién la mantiene y si de verdad la necesita.

  8. 27Probar que el arreglo sí funcionó

    ¿Arregló un XSS? Vuelva a intentar el ataque. Si no lo comprobó, no está arreglado.

Si tiene poco tiempo

Empiece por estos cuatro

  1. Las claves de API fuera del frontend (02).
  2. Validación en el servidor (04).
  3. HTTPS y contraseñas con Argon2id (09 y 03).
  4. Límite de intentos en el inicio de sesión (11).

Con eso tapa los huecos por los que más se meten. Después siga con el resto, de a pedacitos.

Prompt para auditar con IA

Que la IA revise lo que hizo la IA

Péguelo en Claude o ChatGPT junto con el código de su proyecto.

Actúa como auditor senior de ciberseguridad, experto en el OWASP Top 10. Revisa el código de mi app [nombre de su app] y entrégame: 1. Las 10 vulnerabilidades más críticas, de la más grave a la menos grave. 2. El código corregido para cada una. 3. Una prueba para verificar que quedó arreglada. 4. Un informe en formato profesional para entregarle a un cliente.

La IA le hace una app que funciona. Que no se la roben ya es cosa suya.

Así nomasito. Un abrazo.

Sígame en Instagram para más