Auditoría de seguridad web en 48 horas: Laravel, Node.js y WordPress

Una auditoría útil no es un teatro de herramientas en verde. Consiste en encontrar lo que puede tumbar la aplicación o filtrar datos, documentarlo con evidencia, y priorizar qué arreglar primero.

Esta metodología aplica a aplicaciones PHP/Laravel, Node.js y WordPress (multisite, Elementor, tiendas con pagos). Cuando hay ecommerce o pasarelas locales, incluye checkout y webhooks — la misma superficie que cubre pagos en línea.

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 de 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.
• 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.

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?

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.

Formato del entregable

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