---
type: AUD
asset_id: AUD-EL-PlatformSecurity-MPX-v01
version: v01
status: Activo
confidencial: true
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
fecha_creacion: 2026-07-03
fecha_ultima_actualizacion: 2026-07-03
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Plataforma
proyecto: Platform Intelligence (TP-EL-PlatformIntelligence-MPX-RClub-v01)
proposito: >
  Evaluación DEFENSIVA de postura de seguridad de MasterPlaybooks (masterplaybooks.com/dev),
  autorizada por el owner (Victor), ejecutada por observación pasiva el 2026-07-03. NO es un
  pentest ofensivo: no se explotaron vulnerabilidades, no se accedió a datos de otros usuarios,
  no se probó bypass de autenticación. Los hallazgos que requieren confirmación activa o revisión
  de código están marcados como tales.
metodo: Observación pasiva con sesión admin del owner (headers de respuesta, almacenamiento del cliente, tráfico de red que la app genera naturalmente). Sin pruebas activas.
alcance: 5 frentes — aislamiento de datos, auth/sesión, exposición del cliente, headers/transporte, PII
tags: [AUD, seguridad, MPX, plataforma, confidencial, platform-intelligence, defensivo]
---

# AUD · Postura de Seguridad — MasterPlaybooks v01
## Evaluación defensiva pasiva · 2026-07-03 · CONFIDENCIAL

> **Tripleta WORX** — Owner: Victor Heredia · Sherpa: Jay · Ratificador: Victor Heredia
> **⚠️ CONFIDENCIAL** — contiene detalles de infraestructura y superficie de datos. No compartir fuera del equipo core (Victor, Alex, Jesús, Gus, Jay).
> **Método:** observación pasiva, sesión admin del owner. Cero riesgo operativo: no se alteró data ni se ejecutaron pruebas activas.

---

## §0 · Resumen ejecutivo

La plataforma tiene **buenas bases en manejo de credenciales del cliente** (no hay secretos hardcodeados en el frontend, el token de sesión no vive en `localStorage`), pero presenta **dos hallazgos altos** que deben atenderse pronto:

1. 🔴 **ALTO — PII en URLs públicas predecibles:** las fotos de perfil se sirven desde un host separado (`genniux.net/php/imagenes/`) con nombres de archivo que son **el email o el nombre real del usuario**, sin control de acceso. Cualquiera que adivine/enumere un email obtiene la foto, y la URL misma revela el email.
2. 🟠 **ALTO — Ausencia total de headers de seguridad:** la plataforma no envía CSP, HSTS, X-Frame-Options, X-Content-Type-Options ni Referrer-Policy. Esto abre clickjacking, degrada la defensa contra XSS y no fuerza HTTPS.

Además, se confirmó la arquitectura de backend (`genniux.net`, dos capas de API) y el endpoint multi-canal (`get/companies`) que se relaciona con la fuga cross-canal detectada en el diagnóstico funcional.

| Severidad | Hallazgos |
|---|---|
| 🔴 Alto | 2 (PII en URLs, autorización cross-canal por confirmar) |
| 🟠 Medio | 3 (headers ausentes, config del canal en localStorage, host de imágenes sin auth) |
| 🟢 Bajo / Positivo | 3 (sin secretos en cliente, token fuera de localStorage, HTTPS en todo) |

---

## §1 · Hallazgos por frente

### F1 · Aislamiento de datos / multi-tenancy

| ID | Hallazgo | Severidad | Evidencia (pasiva) | Estado |
|---|---|---|---|---|
| SEC-ISO-01 | Endpoint multi-canal `POST /api/playbook/get/companies` alimenta el admin con todos los canales/empresas | 🔴 Alto (por confirmar) | El admin de MPX lista un usuario `demo@rebelocityclub.com` con playbook ajeno ("Derecho procesal penal"). Correlaciona con el bug RClub↔TribusRRHH | Requiere revisión de código o prueba activa para confirmar si el backend filtra por canal/rol |
| SEC-ISO-02 | El filtrado por canal parece hacerse del lado cliente | 🔴 Alto (por confirmar) | La app descarga la lista completa y filtra en el front; si el backend no valida el `channel_id` contra el rol del solicitante, es una fuga de autorización | Requiere M4 (Code Review) |

> **Nota metodológica:** confirmar SEC-ISO-01/02 exigiría llamar a los endpoints como un usuario de otro canal — eso es prueba activa y queda fuera de esta evaluación pasiva. Se recomienda hacerlo en el Módulo 4 (Code Review) con acceso al repo.

### F2 · Autenticación y sesión

| ID | Hallazgo | Severidad | Evidencia | Estado |
|---|---|---|---|---|
| SEC-AUTH-01 | Token de sesión NO está en `localStorage` | 🟢 Positivo | Ninguna clave de storage contiene token/jwt/auth. Buen patrón: reduce robo de sesión vía XSS | OK |
| SEC-AUTH-02 | Rutas admin (`/dashboard/admin`, `/stats`, `/admin-canales`) protegidas solo en el front | 🟠 Medio (por confirmar) | Las rutas se ocultan por rol en la UI; falta confirmar que cada endpoint valida el rol en el backend, no solo la UI | Requiere M4 (Code Review) |
| SEC-AUTH-03 | Backend con dos capas: `/api/` (PHP, POST) y `/api-nodejs/api/` (Node, REST) en `genniux.net` | ℹ️ Info | Superficie de ataque dividida en dos stacks; conviene auditar ambos con el mismo estándar de authz | Documentar |

### F3 · Exposición del cliente

| ID | Hallazgo | Severidad | Evidencia | Estado |
|---|---|---|---|---|
| SEC-CLI-01 | Sin secretos hardcodeados en el frontend | 🟢 Positivo | Escaneo de patrones Stripe (pk/sk), OpenAI, Anthropic, Google API, AWS, JWT en todo el `localStorage`: 0 coincidencias | OK |
| SEC-CLI-02 | `dm_config` en localStorage expone config del canal | 🟠 Medio | Incluye `server`, `rutaapp`, `admin_1`, `admin_2`, `correo_soporte`, `correo_registros` — metadata de infra/administradores legible por cualquier script en la página | Mover a memoria o minimizar; no exponer identidad de admins |
| SEC-CLI-03 | `fallbackEvents` en localStorage incluye `userId` en claro | 🟢 Bajo | Identificador interno de usuario; bajo impacto pero innecesario en storage persistente | Limpiar |

### F4 · Headers y transporte

| ID | Hallazgo | Severidad | Evidencia | Estado |
|---|---|---|---|---|
| SEC-HDR-01 | **Sin `Content-Security-Policy`** | 🟠 Medio | Header ausente en la respuesta. Sin CSP, un XSS tiene rango completo de ejecución | Agregar CSP restrictiva |
| SEC-HDR-02 | **Sin `Strict-Transport-Security` (HSTS)** | 🟠 Medio | Header ausente. El sitio es HTTPS pero no obliga al navegador a no bajar a HTTP | Agregar HSTS con max-age largo |
| SEC-HDR-03 | **Sin `X-Frame-Options` / frame-ancestors** | 🟠 Medio | Header ausente → la app es embebible en un iframe = riesgo de clickjacking | Agregar `X-Frame-Options: DENY` o CSP frame-ancestors |
| SEC-HDR-04 | Sin `X-Content-Type-Options` ni `Referrer-Policy` ni `Permissions-Policy` | 🟢 Bajo | Headers de endurecimiento ausentes | Agregar los tres (nosniff, no-referrer-when-downgrade o stricter, permissions mínimas) |
| SEC-HDR-05 | Servidor revela `Server: LiteSpeed` | 🟢 Bajo | Fingerprinting del stack; minimizar banner del servidor | Opcional |

### F5 · PII y superficie de datos

| ID | Hallazgo | Severidad | Evidencia | Estado |
|---|---|---|---|---|
| SEC-PII-01 | **Fotos de perfil en URL pública predecible con email/nombre como nombre de archivo** | 🔴 Alto | Patrón `https://genniux.net/php/imagenes/{usuario}.png`. Se observaron archivos cuyo nombre ES un email real (p.ej. formato `nombre@dominio.com.png`) o el nombre completo de la persona. Cargan por GET simple, sin token | La URL misma filtra PII (email); el objeto es accesible sin autenticación aparente |
| SEC-PII-02 | Host de imágenes sin control de acceso | 🔴 Alto | Las imágenes de todos los usuarios se sirven desde el mismo directorio público. Un tercero que enumere/adivine nombres de archivo puede recolectar fotos y correlacionar email→persona | Mover a almacenamiento con acceso firmado (URLs con token temporal) o IDs opacos |
| SEC-PII-03 | Emails reales de usuarios visibles en el admin | 🟢 Bajo (esperado) | 48 usuarios con email visible en el panel admin — normal para un admin, pero refuerza que el vector real es SEC-PII-01/02 donde el email sale del perímetro autenticado | Sin acción directa; mitigar vía SEC-PII-01 |

> **Nota de privacidad:** este reporte NO incluye la lista de emails/usuarios observados. Solo se documenta el patrón. Los datos personales vistos durante la auditoría no se persisten.

---

## §2 · Top 5 acciones priorizadas

| # | Acción | ID | Severidad | Responsable |
|---|---|---|---|---|
| 1 | Reemplazar URLs públicas de fotos de perfil: usar IDs opacos + URLs firmadas con expiración; nunca usar email/nombre como nombre de archivo | SEC-PII-01/02 | 🔴 Alto | Alex + Jesús |
| 2 | Confirmar (vía code review) que TODO endpoint admin y multi-canal valida rol y `channel_id` en el backend, no solo en la UI | SEC-ISO-01/02, SEC-AUTH-02 | 🔴 Alto | Alex (backend) |
| 3 | Agregar headers de seguridad a nivel servidor/LiteSpeed: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy | SEC-HDR-01..04 | 🟠 Medio | Alex (infra) |
| 4 | Sacar de `localStorage` la config sensible del canal (identidad de admins, server, rutas) | SEC-CLI-02 | 🟠 Medio | Jesús |
| 5 | Endurecer el host `genniux.net/php/imagenes/`: bloquear listado de directorio y acceso directo no autenticado | SEC-PII-02 | 🔴 Alto | Alex (infra) |

---

## §3 · Lo que esta evaluación NO cubrió (límites)

Por ser una revisión **pasiva y no ofensiva**, quedan fuera y requieren el Módulo 4 (Code Review) o pruebas activas autorizadas:

- **Vulnerabilidades de backend:** inyección SQL, IDOR profundo (acceder a datos de otro usuario por manipulación de IDs), lógica de negocio, deserialización.
- **Confirmación de authz:** si los endpoints admin/multi-canal realmente rechazan a un usuario sin privilegios (SEC-ISO, SEC-AUTH-02) — requiere prueba controlada.
- **Seguridad de pagos/Stripe:** el flujo de membresías/pagos (P0 del M4 del TP) solo se observó a nivel presencia, no se auditó.
- **Pipeline de IA (Sherpa/KatIA):** inyección de prompt, fuga de contexto entre usuarios/canales — relacionado con el bug P0 del diagnóstico funcional (RAG desanclado).
- **Dependencias:** versiones desactualizadas / CVEs en librerías del front y back.

---

## §4 · Handoff y NEXTs

- **Para el Módulo 4 (Code Review, Room 6):** este AUD es el insumo de priorización. Los IDs `SEC-ISO-*` y `SEC-AUTH-02` son las hipótesis de seguridad #1 a confirmar con acceso al repo.
- **NEXT Alex:** SEC-PII-01/02 (URLs de fotos + host de imágenes) y SEC-HDR-* (headers) — son cambios de infra de impacto alto y esfuerzo bajo-medio.
- **NEXT Jesús:** SEC-CLI-02 (config sensible fuera de localStorage).
- **NEXT Victor:** decidir si se autoriza una fase de prueba activa (pentest controlado) para confirmar los hallazgos "por confirmar", o si se resuelven directo vía code review.
- **Relación con diagnóstico funcional:** SEC-ISO-01/02 es la cara de seguridad del hallazgo `MPX-ADM-04` de `OUT-EL-PlatformDiag-MPX-v02` (usuario RClub en admin MPX).

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-03 | Evaluación defensiva pasiva inicial. 5 frentes, 2 hallazgos altos (PII en URLs públicas, authz cross-canal por confirmar), 3 medios (headers, config en cliente, host de imágenes), 3 positivos (sin secretos en cliente, token fuera de localStorage, HTTPS). |

---

*Evaluación pasiva autorizada por el owner · Jay (SherpaX) · 2026-07-03 · Proyecto Platform Intelligence · CONFIDENCIAL*