El recurso anterior te dio las 3 cerraduras imprescindibles antes de publicar. Este es el siguiente nivel: el blindaje que usan los productos serios. Empecemos por una verdad incómoda y liberadora: nada es "impenetrable". Google, Stripe, los bancos — todos pueden ser atacados. La meta real no es ser invulnerable; es ser tan caro y molesto de atacar que el atacante se rinda y vaya por una presa más fácil, y contener el daño cuando algo pasa para que un fallo no se vuelva una catástrofe. Es como tu casa: no existe la imposible de robar, existe la que tiene rejas, alarma, perro y cámaras — donde el ladrón mira, calcula el esfuerzo, y se va a la del vecino. Esa es la meta: ser la casa difícil. Aquí están las 8 capas que lo logran, en lenguaje simple, cada una con su analogía y un prompt para pedírsela a tu IA.
Nada es "impenetrable", y quien te diga lo contrario te miente. Google, Stripe, los bancos: todos pueden ser atacados. Entonces, ¿de qué sirve la seguridad? La meta real no es ser invulnerable — es ser tan caro y molesto de atacar que el atacante se rinda y vaya por una presa más fácil. Y es contener el daño cuando algo pasa, para que un fallo no se vuelva una catástrofe.
Dos cosas que la gente confunde: autenticación es "¿eres quien dices ser?" (el login), y autorización es "¿tienes permiso para ESTO en concreto?" (¿este usuario puede ver este dato?). La regla de oro: negar por defecto. Todo está cerrado a menos que explícitamente se abra — nunca al revés. La mayoría de las fugas pasan porque alguien dejó algo "abierto por defecto" y se le olvidó cerrarlo.
Quiero asegurar la autenticación y autorización de mi backend con la regla "negar por defecto". Cada endpoint debe nacer cerrado y abrirse solo con justificación explícita. Configura un guard global que exija autenticación en todo, y permite marcar como público solo lo que yo indique. Para la autorización, verifica permisos por acción, no solo por login. Explícame en pasos simples qué hiciste.
Esta capa es justo lo que vimos en la guía anterior (la Cerradura 1). Aquí la elevamos a regla de arquitectura: en un producto multi-usuario, RLS no es opcional, es el cimiento.
Mi app es multi-usuario (muchos clientes en la misma base de datos). Asegura el aislamiento total con Row Level Security: activa RLS en TODAS las tablas con datos de usuarios, con políticas que garanticen que cada quien solo accede a lo suyo. Quiero que la base lo imponga aunque el código tenga un bug. Usa (SELECT auth.uid()) por rendimiento y restringe al rol authenticated. Dame el SQL y explícame cómo probar que un usuario NO puede ver datos de otro.
Agrega rate limiting a mi backend: un límite de peticiones por minuto por usuario y por IP, más estricto en los endpoints sensibles (login, registro, y los que llaman a la IA). Cuando se pase el límite, responde con un error claro (429) sin tumbar el servidor. Dime los límites que recomiendas para empezar y cómo ajustarlos.
Antes de que una petición maliciosa toque tu servidor, pasa por un escudo exterior — Cloudflare es el estándar. Ese escudo absorbe los ataques masivos (los DDoS: miles de máquinas atacándote a la vez), filtra bots conocidos y bloquea patrones de ataque. Tu servidor queda escondido detrás, sin exponer sus puertas directamente. Es la primera línea, la que usan los grandes.
Quiero poner un escudo exterior (WAF/CDN como Cloudflare) delante de mi app. Guíame en pasos simples para: pasar mi dominio por Cloudflare, activar la protección DDoS y el firewall de aplicación, y esconder mi servidor de origen para que nadie le pegue directo. Dime qué configuraciones activar de entrada y cuáles son gratis.
Asegura mis secretos (API keys, contraseñas, tokens). 1) Sácalos del código y de git: ponlos en variables de entorno y crea un .gitignore que ignore .env. 2) Si guardo llaves de mis usuarios, cífralas en la base con una clave por usuario. 3) Configura gitleaks como hook antes de cada commit para que me frene si intento subir un secreto por accidente. Explícame cada paso en simple.
Nunca confíes en lo que el usuario envía. Cada dato que llega a tu backend se valida contra un esquema estricto antes de tocar nada. Esto bloquea los ataques clásicos: el SQL injection (que el atacante meta comandos en un formulario para robar tu base de datos), la inyección de prompts (que un usuario manipule a tu IA para que se salte sus reglas), y los datos malformados que rompen el sistema. La regla: validar en cada borde. Todo lo externo es sospechoso hasta que se prueba lo contrario.
Valida TODA la entrada de mi backend con un esquema estricto (usa Zod o equivalente) en cada endpoint, antes de procesar nada. Rechaza lo que no cumpla el esquema. Protégeme específicamente contra SQL injection, inyección de prompts a la IA, y datos malformados. Dame el patrón para aplicarlo en cada borde y un ejemplo en uno de mis endpoints.
Mi app usa IA (que cuesta dinero por uso). Protégeme de que un usuario me sangre los créditos: 1) ponle a cada usuario un presupuesto/límite diario de uso de IA, y córtalo cuando lo alcance con un mensaje claro. 2) Registra el consumo por usuario para detectar comportamientos anormales. 3) Avísame si alguien dispara su gasto. Explícame cómo definir los límites para no afectar al usuario normal.
No puedes proteger lo que no ves. Cada acción importante queda registrada (quién, qué, cuándo) en un log inmutable que nadie puede borrar. Si pasa algo raro, tienes la grabación. Y un sistema de alertas te avisa mientras pasa, no después. Esto es lo que te deja dormir tranquilo: si alguien intenta algo, lo ves en vivo.
Agrega auditoría y observabilidad a mi app: 1) un log inmutable que registre quién hizo qué y cuándo en las acciones importantes (login, cambios de datos, pagos), que no se pueda borrar ni editar. 2) Alertas que me avisen en tiempo real si pasa algo sospechoso (muchos intentos de login fallidos, gasto anormal, errores en picos). Dime qué eventos registrar primero y cómo recibir las alertas.
Si quieres pedirlas todas juntas al arrancar un proyecto serio, este prompt resume las 8 capas para que tu IA las tenga en cuenta desde el cimiento:
Vamos a construir este backend con seguridad de nivel enterprise desde el día 1, usando "defensa en profundidad" (muchas capas). Ten en cuenta estas 8 capas en todo lo que construyas, y recuérdame cuál falta: 1. AUTH: autenticación + autorización con "negar por defecto" (todo cerrado salvo lo que abra explícito). 2. AISLAMIENTO: Row Level Security en todas las tablas (cada usuario solo ve lo suyo, impuesto por la base). 3. RATE LIMITING: límite de peticiones por usuario/IP, más estricto en endpoints sensibles. 4. ESCUDO EXTERIOR: WAF/CDN (Cloudflare) delante, con protección DDoS y el origen escondido. 5. SECRETOS: nada de claves en código/git; vault + variables de entorno; llaves de usuario cifradas; gitleaks antes de cada commit. 6. VALIDACIÓN: validar toda entrada con esquema estricto (Zod) en cada borde; protección contra SQL injection e inyección de prompts. 7. COST GUARDRAILS: presupuesto de IA por usuario con corte automático; detectar consumo anormal. 8. AUDITORÍA: log inmutable (quién/qué/cuándo) + alertas en tiempo real. Empieza diciéndome cuáles aplican a mi proyecto y en qué orden las implementamos, sin sobre-ingeniería para lo que no necesito todavía.
Únete a 4.200+ creadores. Sin tarjeta. Construye tu primera app con IA en minutos.