---
type: AUD
asset_id: AUD-EL-PlatformSecurity-MPX-v02
version: v02
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 v02
## 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 **cuatro hallazgos altos** que deben atenderse pronto — dos de ellos ya **confirmados por observación pasiva**, dos **por confirmar** en code review:

1. 🔴 **ALTO (confirmado) — 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 (confirmado) — Fuga de datos cross-canal al cliente:** el navegador **recibe** datos de canales ajenos (se observó `demo@rebelocityclub.com` con playbook de otro canal en el admin MPX). Independientemente de lo que valide el backend, la data ya salió del perímetro de su canal hacia el cliente.
3. 🔴 **ALTO (por confirmar) — Autorización cross-canal en backend:** falta confirmar (code review) que los endpoints multi-canal/admin rechazan a un solicitante sin privilegios, en vez de confiar en el filtrado del front.
4. 🟠 **MEDIO — Ausencia de headers de seguridad:** la plataforma no envía CSP, HSTS, X-Frame-Options, X-Content-Type-Options ni Referrer-Policy. Abre clickjacking, degrada la defensa contra XSS y no fuerza HTTPS. *(Severidad Media — corregido de v01, que lo rotulaba Alto en el título.)*

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.

### Rúbrica de severidad (nueva en v02)

Para que el conteo sea reproducible y el M4 herede números consistentes, cada hallazgo se clasifica por **Impacto × Exposición**:

| | **Exposición: pública/no-auth** | **Exposición: requiere sesión** | **Exposición: solo admin/interno** |
|---|---|---|---|
| **Impacto alto** (PII, authz, RCE) | 🔴 Alto | 🔴 Alto | 🟠 Medio |
| **Impacto medio** (hardening, metadata) | 🟠 Medio | 🟠 Medio | 🟢 Bajo |
| **Impacto bajo** (fingerprint, higiene) | 🟢 Bajo | 🟢 Bajo | 🟢 Bajo |

- **Confirmado** = observable pasivamente en esta auditoría. **Por confirmar** = requiere prueba activa o code review (M4). El estado no cambia la severidad, solo la certeza.

### Conteo (recontado en v02 contra el detalle de §1)

| Severidad | # | Hallazgos |
|---|---|---|
| 🔴 Alto | 4 | SEC-PII-01, SEC-PII-02, SEC-ISO-01, SEC-ISO-02 |
| 🟠 Medio | 5 | SEC-AUTH-02, SEC-CLI-02, SEC-HDR-01, SEC-HDR-02, SEC-HDR-03 |
| 🟢 Bajo | 4 | SEC-CLI-03, SEC-HDR-04, SEC-HDR-05, SEC-PII-03 |
| 🟢 Positivo | 3 | SEC-AUTH-01, SEC-CLI-01, SEC-AUTH-04 |
| ℹ️ Info | 1 | SEC-AUTH-03 |

> **Nota v02:** el conteo de v01 (2 altos / 3 medios / 3 bajos) subcontaba y duplicaba "host de imágenes" entre Medio y Alto. Este conteo cuadra 1:1 con las tablas de §1.

---

## §1 · Hallazgos por frente

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

| ID | Hallazgo | Severidad | Evidencia (pasiva) | Estado |
|---|---|---|---|---|
| SEC-ISO-01 | **Fuga de datos cross-canal al cliente:** el admin MPX recibe y renderiza un usuario `demo@rebelocityclub.com` con playbook ajeno ("Derecho procesal penal"). La data de otro canal **ya llegó al navegador** | 🔴 Alto | El objeto cross-canal es visible en el DOM/respuesta del admin. Correlaciona con el bug RClub↔TribusRRHH | **Confirmado (fuga al cliente).** La validación de authz en backend se separa en SEC-ISO-02 |
| SEC-ISO-02 | **Authz cross-canal en backend por confirmar:** `POST /api/playbook/get/companies` parece devolver todos los canales y el filtrado se hace en el front; si el backend no valida `channel_id` contra el rol, es fuga de autorización | 🔴 Alto (por confirmar) | La app descarga la lista completa y filtra en el cliente | Requiere M4 (Code Review) para confirmar el gate de backend |

> **Nota metodológica:** confirmar el *gate de backend* (SEC-ISO-02) exigiría llamar a los endpoints como un usuario de otro canal — prueba activa, fuera de esta evaluación. Lo que SÍ es confirmable y ya está confirmado es que la data cross-canal llega al cliente (SEC-ISO-01).

### 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-04 | **Atributos de la cookie de sesión (nuevo en v02):** al no estar en localStorage, el token probablemente vive en cookie — verificar `HttpOnly`, `Secure`, `SameSite` | 🟢 Positivo/por confirmar | Pendiente inspeccionar el `Set-Cookie` en la respuesta de login. Es observable pasivamente y completa la media victoria de SEC-AUTH-01 | Confirmar los tres flags; si falta `HttpOnly` sube a 🟠 Medio |
| 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 | 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, referrer estricto, 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 (formato `nombre@dominio.com.png`) o el nombre completo de la persona. Cargan por GET simple, sin token | **Confirmado.** 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 |

> **Quick win (nuevo en v02):** verificar si `genniux.net/php/imagenes/` tiene **directory listing habilitado**. Si lo tiene, no hay que adivinar nombres de archivo — se enumeran todos de una vez, lo que convierte SEC-PII-02 de "adivinable" a "cosechable en masa". Prueba pasiva de segundos (GET al directorio); mitigación inmediata: `Options -Indexes` en el server.

> **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. **Exposición de PII no autenticada (SEC-PII-01/02) puede tener implicaciones de protección de datos — escalar con Victor.**

---

## §2 · Top 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 | **Quick win:** deshabilitar directory listing en `genniux.net/php/imagenes/` (`Options -Indexes`) — contiene la cosecha masiva mientras se hace el #1 | SEC-PII-02 | 🔴 Alto | Alex (infra) |
| 3 | Cerrar la fuga cross-canal: el backend debe filtrar por `channel_id`/rol antes de responder, para que la data ajena **no llegue al cliente**; confirmar en code review el gate de todo endpoint admin/multi-canal | SEC-ISO-01/02, SEC-AUTH-02 | 🔴 Alto | Alex (backend) |
| 4 | 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) |
| 5 | Sacar de `localStorage` la config sensible del canal (identidad de admins, server, rutas) | SEC-CLI-02 | 🟠 Medio | Jesús |
| 6 | Verificar flags de la cookie de sesión (`HttpOnly`, `Secure`, `SameSite`) | SEC-AUTH-04 | 🟢→🟠 | Alex |

---

## §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 del gate de authz en backend:** si los endpoints admin/multi-canal realmente rechazan a un usuario sin privilegios (SEC-ISO-02, 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. `SEC-ISO-02` y `SEC-AUTH-02` son las hipótesis de seguridad #1 a confirmar con acceso al repo. `SEC-ISO-01` ya está confirmado como fuga al cliente.
- **NEXT Alex:** SEC-PII-01/02 (URLs de fotos + directory listing) y SEC-HDR-* (headers) — cambios de infra de impacto alto y esfuerzo bajo-medio. Verificar cookie flags (SEC-AUTH-04).
- **NEXT Jesús:** SEC-CLI-02 (config sensible fuera de localStorage).
- **NEXT Victor:** (a) escalar la exposición de PII no autenticada como posible tema de protección de datos; (b) decidir si se autoriza una fase de prueba activa (pentest controlado) para confirmar SEC-ISO-02/SEC-AUTH-02, 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 |
|---|---|---|
| v02 | 2026-07-03 | QA de coherencia + profundización. Recontada la tabla de severidad (4 altos / 5 medios / 4 bajos / 3 positivos / 1 info) para cuadrar 1:1 con §1; eliminado el doble conteo de "host de imágenes". Corregido el rótulo "ALTO" de headers a Medio. Agregada rúbrica de severidad (Impacto × Exposición). SEC-ISO-01 separado en fuga-al-cliente (confirmado) vs. gate-backend (SEC-ISO-02, por confirmar). Nuevo SEC-AUTH-04 (cookie flags). Nuevo quick win: directory listing en el host de imágenes. Escalamiento de PII como tema de protección de datos. |
| 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*