01 Del prototipo al producto
Programar pidiéndole cosas a una IA permite tener una app funcionando en horas. Lo que no se ve en la demo es lo que decide si puedes cobrar por ella: quién puede leer qué datos, qué pasa cuando cien personas la usan a la vez, qué ocurre si alguien automatiza peticiones contra tu servicio más caro o cómo te enteras de que algo ha fallado.
Los diez puntos siguientes no dependen del lenguaje ni del framework. Para cada uno tienes qué comprobar y por qué importa. La regla de oro al trabajar con Claude Code: primero auditoría, después cambios aprobados uno a uno, y siempre con Git para poder volver atrás.
02 Bloque 1: proteger lo que ya tienes
1. Ningún secreto en el navegador
Las claves de API, de pagos o de base de datos privadas no pueden llegar al código que descarga el usuario. Revisa también los source maps de producción, que permiten reconstruir tu código fuente.
2. Permisos por fila en la base de datos
Si usas Postgres, la seguridad a nivel de fila (RLS) garantiza que cada usuario solo lea y modifique sus propios registros, aunque alguien manipule las peticiones.
3. Control de versiones
Git con un .gitignore correcto, sin archivos .env en el historial y una rama por cambio. Es tu botón de deshacer cuando un cambio de la IA rompe algo.
4. Seguridad de la aplicación
Inicio de sesión robusto, sesiones que caducan, validación de todo lo que envía el usuario y permisos comprobados en el servidor, no solo ocultos en la interfaz.
03 Bloque 2: conectar y publicar bien
5. APIs ordenadas y protegidas
Cada ruta propia debe comprobar quién llama y qué puede hacer, validar la entrada y devolver errores coherentes. Inventaría también las APIs externas que consumes.
6. Despliegue reproducible
Entorno de pruebas separado del de producción, variables de entorno en el proveedor de hosting, HTTPS y un proceso de publicación que no dependa de tu ordenador.
04 Bloque 3: aguantar el uso real
7. Límite de peticiones
Pon un tope de peticiones por usuario o IP en las rutas caras: las que llaman a modelos de IA, envían correos, hacen login o cobran. Sin él, un bot puede vaciar tu saldo en minutos.
8. Caché
Guarda temporalmente lo que cambia poco y se pide mucho. Define cuánto dura cada dato en caché y cómo se invalida cuando cambia.
9. Preparada para crecer
Índices en las consultas frecuentes, paginación, tareas pesadas en segundo plano y conexiones a la base de datos bien gestionadas.
10. Monitorización y alertas
Captura de errores en producción, registros consultables y avisos cuando algo falla o el gasto en servicios por uso se dispara.
05 Auditoría completa con Claude Code
-
1
Asegura el punto de partida
Haz commit de todo antes de empezar para poder volver atrás con seguridad.
-
2
Lanza la auditoría en modo plan
Activa el modo plan (Shift+Tab en la terminal) o pide expresamente que no modifique nada.
-
3
Prioriza
Ordena los hallazgos por gravedad y empieza por secretos, permisos de datos y límites de peticiones.
-
4
Corrige de uno en uno
Un cambio por commit, con una prueba que demuestre que funciona.
Actúa como revisor técnico de una aplicación que voy a empezar a vender. No modifiques ningún archivo: esta sesión es solo de diagnóstico.
Revisa el proyecto contra estos puntos y dame para cada uno un estado (bien, mejorable o urgente), la evidencia concreta (archivo y línea) y el arreglo propuesto en una frase:
1. Secretos o claves accesibles desde el navegador y source maps en producción.
2. Permisos por usuario en la base de datos.
3. Git: .gitignore, secretos en el historial y forma de trabajar.
4. Autenticación, sesiones y validación de entradas.
5. Rutas de API sin protección o con respuestas inconsistentes.
6. Configuración de despliegue y separación de entornos.
7. Límite de peticiones en rutas caras.
8. Uso de caché.
9. Consultas lentas, falta de índices y tareas pesadas síncronas.
10. Captura de errores, registros y alertas.
Termina con los tres arreglos más urgentes y cuánto esfuerzo estimas para cada uno. Si no puedes comprobar algo, dilo en lugar de suponerlo.Vamos a resolver el punto [NÚMERO Y NOMBRE] de la auditoría.
1. Explícame en dos frases el riesgo actual.
2. Propón el cambio mínimo que lo resuelve, con los archivos que tocarás.
3. Espera mi aprobación.
4. Aplica el cambio, añade una prueba que lo demuestre y ejecuta las pruebas existentes.
5. Enséñame el diff y propón un mensaje de commit.
Si el cambio requiere acciones fuera del código (revocar una clave, cambiar una variable en el hosting), dímelo como tarea para mí; no intentes hacerlo tú.06 Antes de cobrar al primer cliente
- ✓He revocado y regenerado cualquier clave que haya estado expuesta.
- ✓He probado con dos cuentas que la una no ve los datos de la otra.
- ✓Existe una copia de seguridad de la base de datos y sé restaurarla.
- ✓Las rutas que cuestan dinero tienen límite de peticiones.
- ✓Recibo un aviso cuando hay errores en producción.
- ✓El despliegue se puede repetir sin depender de mi ordenador.
- ✓Tengo textos legales y de privacidad revisados por quien corresponda.
Preguntas frecuentes
Por los secretos expuestos, los permisos de la base de datos y el límite de peticiones en rutas caras. Son los fallos que más daño hacen y más rápido se explotan.
Sí. Los puntos son conceptos generales; Claude Code adapta la auditoría al framework, la base de datos y el hosting que use tu proyecto.
No es recomendable. Muchos cambios a la vez son difíciles de revisar y de revertir. Un punto por sesión y un cambio por commit es más seguro.
Para la auditoría no tanto, pero sí debes entender los riesgos y revisar lo que se cambia. Si la app va a cobrar o guardar datos personales, conviene que un profesional revise el resultado.
Sobre el autor
Equipo editorial de appyweb
Marketing, SEO y desarrollo con IA
Especialistas de appyweb en SEO, publicidad, desarrollo web y automatización con IA.