Auditoría de seguridad web: qué incluye y cómo prepararte

Una auditoría de seguridad web es una revisión ordenada de tu sitio o app para encontrar fallas que permitan ver datos ajenos, entrar sin permiso, cobrarte de más o tumbar el servicio, y que termina en un informe con qué arreglar y en qué orden. Se revisan cuatro capas: quién puede acceder a qué (autenticación y permisos), cómo se guardan los datos, qué llaves y secretos están expuestos, y cómo está configurado el servidor o la plataforma.

Qué se revisa en una auditoría de seguridad de una app

1. Accesos y permisos

• ¿Puede un usuario ver o modificar datos de otro cambiando un ID?
• ¿Las rutas de administración piden sesión y rol de administrador en el servidor?
• ¿Se puede uno registrar como admin o cambiarse el rol?
• ¿Las contraseñas tienen reglas mínimas? ¿Hay límite de intentos?
• ¿Se cierran bien las sesiones?

En apps con Supabase, esto es sobre todo revisar RLS tabla por tabla. Ve RLS en Supabase: qué es.

2. Datos

• ¿Qué datos personales guardas y dónde?
• ¿Hay tablas o buckets de archivos abiertos al público?
• ¿Hay respaldos? ¿Se han probado restaurar?
• ¿Qué datos viajan al navegador que no deberían (por ejemplo, la lista completa de usuarios)?

3. Llaves y secretos

• ¿Hay llaves secretas (Supabase service_role, OpenAI, Stripe, Mercado Pago) en el frontend o en GitHub?
• ¿Las llaves tienen permisos mínimos y límites de gasto?

Si ya encontraste una, ve directo a API key expuesta: qué hacer.

4. Configuración y servidor

• HTTPS forzado, certificado vigente.
• Encabezados de seguridad (por ejemplo Content-Security-Policy, Strict-Transport-Security).
• Dependencias con fallas conocidas.
• Puertos, paneles o bases de datos expuestos a internet.
• Configuración de CORS, correo (SPF, DKIM, DMARC) y DNS.

5. Lógica del negocio

Lo que ninguna herramienta automática encuentra sola: ¿se puede pagar menos manipulando el carrito? ¿Se puede usar un cupón infinitas veces? ¿Se puede reservar algo que ya está ocupado?

Cómo se hace, paso a paso

1. Alcance por escrito. Qué se revisa (dominios, app, API, base de datos), qué no, en qué fechas, y la autorización del dueño. Sin autorización, probar un sistema ajeno puede ser delito.
2. Accesos. Cuentas de prueba con distintos roles y, de preferencia, acceso de lectura al código y al panel (Supabase, Vercel, etc.).
3. Revisión automática. Escáneres de dependencias, de secretos y de configuración.
4. Revisión manual. Probar permisos con varias cuentas, leer políticas y código sensible (login, pagos, carga de archivos).
5. Pruebas activas acordadas (ver pentesting en México para cuando se necesita una prueba de intrusión formal).
6. Informe con hallazgos, gravedad y cómo corregir.
7. Re-revisión después de que corriges, para confirmar.

Qué te deben entregar

Un buen informe incluye, por cada hallazgo:

• Qué es, explicado para que lo entienda alguien no técnico.
• Gravedad (crítica, alta, media, baja) y por qué.
• Cómo se reproduce (en tu entorno).
• Cómo se arregla, concreto.
• Prioridad: qué arreglar hoy y qué puede esperar.

Ve un ejemplo de estructura en informe de auditoría de seguridad informática.

Lo que puedes revisar tú antes

No sustituye una auditoría, pero te ahorra tiempo y te da una idea de dónde estás:

• Corre el Security Advisor de Supabase y el escaneo de tu plataforma (Lovable tiene Quick scan y Deep scan).
• Prueba con dos cuentas que una no vea lo de la otra.
• Busca llaves en el código publicado (F12 → Sources → buscar sk-, service_role, sb_secret_).
• Revisa que tengas respaldos.
• Sigue nuestra checklist de seguridad para apps hechas con IA.

Cuándo necesitas una auditoría

• Antes de lanzar una app con usuarios reales o pagos.
• Si la hiciste con IA (Lovable, Bolt, Replit, Cursor) y nadie con experiencia en seguridad la revisó. La IA suele dejar huecos que no se notan al usarla.
• Si un cliente o inversionista te pide evidencia de seguridad.
• Después de un incidente, para saber por dónde entraron.
• Si manejas datos sensibles: salud, finanzas, documentos oficiales, datos de menores.

Errores comunes al contratar

• Contratar solo un escaneo automático y creer que es una auditoría.
• No dar acceso al código ni cuentas de prueba: el auditor ve menos y encuentra menos.
• No definir alcance: después no se sabe qué se revisó.
• Guardar el informe y no corregir.
• No volver a revisar tras cambios grandes.

En resumen

Una auditoría de seguridad web revisa accesos, datos, llaves, configuración y lógica de negocio, y te entrega un informe priorizado para corregir. En apps hechas con IA, lo más grave suele estar en los permisos y las llaves. Si quieres saber cómo está tu app antes de que alguien más lo descubra, en Black Engine lo revisamos contigo por WhatsApp.