Auditoría de seguridad web en 48 horas (Laravel, Node.js, WordPress)

Una auditoría útil no es un PDF de 80 páginas ni un semáforo de herramientas en verde. Es encontrar qué puede tumbar la aplicación o filtrar datos, demostrarlo con evidencia, y decidir qué se arregla primero.

Esta metodología de 48 horas aplica a aplicaciones PHP/Laravel, Node.js y WordPress (multisite, Elementor, tiendas con pagos). Si hay ecommerce o pasarelas locales, incluye checkout y webhooks — la misma superficie que suele generar incidentes reales.

Por qué importa (más allá del “compliance”)

Piensa en la seguridad como el candado de un local: no sustituye al negocio, pero sin él cualquier persona puede entrar. Un hallazgo temprano cuesta un sprint; un incidente cuesta clientes, reputación y días de fuego.

• Dinero: pagos manipulables o webhooks sin firma.
• Datos: pedidos o usuarios visibles por IDOR.
• Operación: admin sin MFA, plugins abandonados, .env público.
• Prioridad: sin P0/P1/P2, todo parece urgente y nada se cierra.

Conceptos clave en lenguaje claro

• Superficie de ataque: todo lo que un desconocido puede tocar (formularios, APIs, uploads, admin).
• Autenticación vs autorización: “quién eres” vs “qué puedes hacer”. Fallan cosas distintas.
• IDOR: cambiar /orders/100 a /orders/101 y ver el pedido de otro.
• Inyección: meter datos que el sistema interpreta como instrucciones (SQL, XSS, path traversal).
• Dependencias: código de terceros con bugs conocidos; actualizar también es seguridad.

Distribución de las 48 horas

Horas 0–4: mapa de superficie

• Inventario de rutas públicas (web + API).
• Formularios, uploads, webhooks de pago, cron endpoints.
• Headers actuales, cookies, redirecciones.
• En WordPress: versión, tema hijo, plugins activos, usuarios administrator.
• En multisite: sitios, super-admins y plugins de red.

Horas 4–16: autenticación y sesión

• Reset de password, enumeración de usuarios, rate limiting.
• Cookies Secure / HttpOnly / SameSite.
• CSRF en formularios que cambian estado.
• JWT: exp, rotación, almacenamiento inseguro en localStorage.
• Admin de WordPress o Filament/Horizon expuesto sin MFA.

Horas 16–32: inyección y lógica de negocio

• SQL / ORM mal usado, XSS almacenado, path traversal.
• Mass assignment en Laravel ($fillable / $guarded).
• IDOR: ¿se puede ver el pedido #id+1?
• En pagos: confirmar que el monto no se confía al cliente.
• Upload: tipo real del archivo, no solo la extensión.

Horas 32–48: dependencias y entregable

• composer / npm audit con criterio (ruido vs riesgo real).
• Plugins WordPress abandonados o con advisories conocidos.
• Secretos en repo, .env expuesto, backups públicos.
• Informe P0/P1/P2 + plan de remediación por sprint.

Laravel: puntos de revisión

• Validación con Form Requests en todas las entradas de API.
• Autorización: Policies/Gates en show/update/destroy.
• Mass assignment: modelos con $guarded = [] o fillables peligrosos.
• Files: Storage con disco privado; URLs firmadas.
• Colas con backoff y dead-letter; payloads sin PII innecesaria.
• APP_DEBUG=false en prod; Telescope/Horizon no públicos.

WordPress: puntos de revisión

• Eliminar usuario admin genérico; revisar roles; 2FA en cuentas privilegiadas.
• XML-RPC: deshabilitar si no hay app legítima que lo necesite.
• REST: endpoints de usuarios que filtran info.
• Uploads: bloqueo de ejecución en uploads.
• WooCommerce: plugins de pasarela actualizados; webhooks con permisos mínimos.

Errores comunes al “auditar”

• Confiar solo en un scanner automático sin validar hallazgos a mano.
• Ignorar lógica de negocio (montos, IDs de pedido, permisos por rol).
• Entregar lista de CVEs sin priorizar impacto en este producto.
• No revisar deploy: el mismo secreto o plugin viejo vuelve en el siguiente release.
• Marcar todo como crítico: el equipo se satura y no arregla lo explotable hoy.

Checklist práctico

1. ¿Hay .env, .git o backups accesibles por URL?
2. ¿Login, reset y APIs sensibles tienen rate limit?
3. ¿Cookies de sesión llevan flags correctos en HTTPS?
4. ¿CSRF está activo en formularios que cambian estado?
5. ¿Policies/capabilities existen y se llaman en cada ruta?
6. ¿Uploads validan MIME real?
7. ¿Webhooks de pago validan firma/origen y son idempotentes?
8. ¿Headers de seguridad (CSP, HSTS) existen sin romper el front?
9. ¿Dependencias críticas tienen dueño de actualización?
10. ¿El deploy puede volver a introducir el mismo secreto o plugin viejo?

Formato del entregable

Cada hallazgo incluye: dónde, cómo reproducirlo, riesgo, arreglo sugerido y esfuerzo relativo. Conecta con DevOps y Coolify y ciberseguridad .