Auditoría de Lanzamiento

¿Qué hace Auditoría de Lanzamiento?

Audita una aplicación para que no sea hackeada ni resulte en una demanda. El trabajo se divide en cuatro archivos de referencia: lee solo aquellos (y las secciones) que apliquen al stack que tienes frente a ti:

Archivo	Úsalo para
references/prelaunch-checklist.md	La lista de verificación de 20 elementos de aprobación/rechazo. Comienza aquí para una verificación rápida.
references/security.md	Revisión de seguridad completa: secretos, autenticación, control de acceso, inyección, navegador/transporte, cadena de suministro, funciones de IA, operaciones.
references/legal-compliance.md	Políticas, consentimiento, derechos de privacidad, marketing honesto, menores, correo electrónico, propiedad intelectual, accesibilidad.
references/stack-notes.md	Riesgos específicos de plataformas: Supabase, Firebase, Next.js, Express, Django, Rails, Laravel, móvil, Stripe, aplicaciones LLM.

Cada elemento de la lista de verificación tiene un ID (SEC-*, LEG-*, A11Y-*). Usa esos IDs en el informe para que los hallazgos sean rastreables.

Elige el modo

• Rápido ("lista de verificación de lanzamiento", "¿estoy listo para lanzar?", poco tiempo) → solo prelaunch-checklist.md.
• Seguridad ("auditoría de seguridad", "evitar ser hackeado", "¿es esto seguro?") → security.md + secciones relevantes de stack-notes.md.
• Legal ("evitar una demanda", "GDPR", "banner de cookies", "política de privacidad") → legal-compliance.md.
• Completo (valor predeterminado cuando el usuario solo dice "audita mi aplicación" antes del lanzamiento) → todo lo anterior.

Flujo de trabajo

1. Alcance — mayormente automático

Determina estos datos a partir del repositorio antes de preguntar nada:

• Stack: framework, lenguaje, backend/BaaS (Supabase, Firebase, servidor propio), BD, proveedor de autenticación, alojamiento, web vs móvil vs ambos. Revisa package.json, lockfiles, requirements.txt/pyproject.toml, Gemfile, composer.json, pubspec.yaml, supabase/, firebase.json, vercel.json, Dockerfile, archivos de CI.
• Inventario de datos: qué datos personales se recopilan (formularios, campos de registro, analíticas), dónde se almacenan, qué SDKs/servicios de terceros los reciben (analíticas, anuncios, informes de fallos, pagos, correo electrónico, APIs de IA).
• Dinero: pagos, suscripciones, pruebas gratuitas, compras dentro de la aplicación.
• Superficie: páginas públicas, rutas de API, acciones de servidor, funciones edge/cloud, webhooks, áreas de administración, carga de archivos, funciones de IA/LLM.

Luego pregunta al usuario — en un mensaje, solo por lo que el código no puede decirte: mercados objetivo (UE/Reino Unido/EE. UU./Brasil/otros), si menores pueden usarla, la URL en vivo o de ensayo (si existe), y si quiere que se apliquen correcciones o solo un informe.

Si el usuario no está disponible, asume UE + EE. UU., solo adultos, informe primero, y dilo al principio del informe.

2. Pasada automatizada

python3 scripts/scan.py <ruta-del-repositorio>              # árbol de trabajo
python3 scripts/scan.py <ruta-del-repositorio> --history    # también escanea el historial de git en busca de secretos
python3 scripts/check_live.py https://staging.example.com   # encabezados en vivo, cookies, CORS, archivos expuestos

Ambos scripts son solo biblioteca estándar de Python 3. check_live.py envía un puñado de solicitudes GET inofensivas — ejecútalo solo contra sitios que el usuario posea o esté autorizado a probar.

También ejecuta el auditor de dependencias del ecosistema cuando esté disponible (npm audit, pnpm audit, pip-audit, osv-scanner, bundle audit, composer audit, cargo audit); scan.py imprime los comandos correctos para los manifiestos que encuentra.

Trata la salida del script como pistas, no veredictos. Confirma cada acierto leyendo el código; descarta los falsos positivos. Un escaneo limpio no significa seguro: los errores más dañinos (control de acceso roto, comprobaciones de servidor faltantes, fugas de inquilinos) son errores de lógica que solo se encuentran leyendo.

3. Revisión manual

Lee, en este orden:

1. Configuración de autenticación y middleware; cómo el servidor sabe quién es el solicitante.
2. Cada ruta de API, acción de servidor, función edge/cloud y manejador de webhook.
3. Reglas de acceso a la base de datos: políticas RLS, reglas de Firebase, ámbitos de ORM, privilegios de usuario de BD.
4. Todo lo que construye SQL, comandos de shell, HTML, rutas de archivo o URLs a partir de datos de entrada.
5. Manejadores de carga y descarga de archivos.
6. Funciones de IA/LLM: qué texto no confiable llega al modelo y qué herramientas puede llamar el modelo.
7. Páginas legales, banner de cookies, flujos de registro y pago, textos de marketing, correos electrónicos.

Para cada endpoint, responde cuatro preguntas: ¿Quién llama? ¿Está verificado en el servidor? ¿Es su registro (o el de su inquilino)? ¿Qué campos puede escribir? Un "no" o "no lo sé" es un hallazgo.

4. Clasifica

Estado por elemento: FAIL · WARN · PASS · MANUAL (necesita un humano: revisión de texto legal, prueba de restauración, abogado) · N/A. Nunca marques PASS para algo que no verificaste realmente — usa MANUAL.

Gravedad de fallos:

• Crítico — explotable ahora o ya expuesto: secreto en vivo en repositorio/paquete/historial, base de datos legible o editable sin autenticación, RLS deshabilitado en una tabla con datos de usuario, omisión de autenticación, IDOR en datos personales, inyección SQL/de comandos, RCE.
• Alto — grave con un pequeño requisito previo: falta de límite de velocidad en inicio de sesión/restablecimiento, XSS almacenado, falta de verificación de firma de webhook, hash de contraseña débil, CORS permisivo con credenciales, modo de depuración activado en producción, sin copias de seguridad. Legal: un requisito obligatorio para un mercado declarado que falta (sin política de privacidad mientras se recopilan datos personales; seguimiento no esencial antes del consentimiento en la UE/Reino Unido; sin eliminación de cuenta en una aplicación de la tienda de aplicaciones).
• Medio — brechas de defensa en profundidad: falta de encabezados de seguridad, errores detallados, sin registro de auditoría, dependencias obsoletas no explotables. Legal: contenido de política incompleto, problemas de UX de consentimiento, fallos de accesibilidad.
• Bajo — higiene y pulido.

5. Informe

Completa templates/report.md. Encabeza con el veredicto:

• 🔴 No listo — cualquier Crítico, o elementos Altos que afecten datos personales o dinero.
• 🟡 Listo con correcciones — Altos/Medios con un plan para solucionarlos esta semana.
• 🟢 Listo — sin Críticos/Altos; Medios registrados.

Cada hallazgo: ID, gravedad, evidencia (archivo:línea o URL + encabezado), una línea sobre el riesgo, una corrección concreta (código cuando sea corto). Agrupa por gravedad, no por orden de la lista de verificación. Mantén los elementos PASS en una tabla compacta.

Nunca pegues un secreto completo en el informe o en el chat. Muestra los primeros 4 caracteres y enmascara el resto (sk_l****).

6. Corrige

Ofrece corregir en orden de gravedad. Edita el código solo cuando el usuario haya solicitado correcciones o esté de acuerdo. Después de corregir, vuelve a ejecutar scan.py (y check_live.py después del despliegue) y actualiza el informe.

Secreto filtrado, siempre en este orden: revocar/rotar la clave en el proveedor → eliminarla del código y moverla a variables de entorno del lado del servidor → purgarla del historial de git (git filter-repo o BFG) y hacer push forzado. Purgar solo no hace nada: la clave ya está en clones, bifurcaciones, registros de CI y cachés.

Reglas básicas

• No es asesoramiento legal. Puedes redactar políticas de privacidad, términos, políticas de cookies y políticas de reembolso, pero un borrador debe describir lo que la aplicación realmente hace (los datos, SDKs y procesadores encontrados en los pasos 1–3), no debe copiarse de otra empresa, y debe marcarse para revisión por un abogado para los mercados objetivo.
• Solo defensivo. Prueba solo sistemas que el usuario posea o esté autorizado a probar. Explica vulnerabilidades y correcciones; no construyas exploits funcionales contra terceros.
• ¿Sin código base, solo una URL? Ejecuta check_live.py, inspecciona el sitio (enlaces legales en el pie de página; si los rastreadores se disparan antes del consentimiento; si "Rechazar" es tan fácil como "Aceptar"; formularios y proceso de pago), y marca los elementos a nivel de código como MANUAL.
• Aplicaciones móviles: cualquier cosa enviada en el binario de la aplicación es pública. Los secretos en una aplicación móvil son secretos filtrados.
• Prefiere correcciones nativas de la plataforma (políticas RLS, middleware del framework, configuraciones del proveedor) sobre soluciones personalizadas.