Arquitectura de seguridad verificada
Seguridad · ProjectHub
Defensa en profundidad con múltiples capas independientes. Si una falla, las siguientes la contienen. Diseñada para datos institucionales del Tec de Monterrey.
5/7Capas activas
5/8Amenazas mitigadas
7/11Controles activos
Defensa en profundidad — 7 capas
01 — Red · Cloudflare WAF
Todo el tráfico entra por Cloudflare antes de llegar a Vercel. El Web Application Firewall bloquea ataques de capa 7: SQL Injection, XSS, bots maliciosos y DDoS volumétrico. Los certificados TLS/HTTPS son gestionados automáticamente.
Activo
02 — Borde · Vercel Edge Network
El frontend corre en la red edge de Vercel con 100+ PoPs globales. Las API Routes de Next.js se ejecutan como Serverless Functions aisladas — cada request vive en su propio contexto de ejecución sin estado compartido entre usuarios.
Activo
03 — API · Control de acceso por route
Ninguna query de Supabase sale desde el cliente. Todas las operaciones de base de datos pasan por las API Routes de Next.js en el servidor, usando la SERVICE_ROLE_KEY que nunca se expone al browser. RLS desactivado intencionalmente — la capa de autorización vive aquí.
Activo
04 — Datos · Supabase PostgreSQL
Base de datos en Supabase Cloud con PostgreSQL 15. Row Level Security desactivado por diseño de arquitectura — el control de acceso ocurre a nivel de API. Conexiones cifradas en tránsito. Backups automáticos diarios gestionados por Supabase.
Activo
05 — Secretos · Variables de entorno
Todas las credenciales se almacenan como variables de entorno en Vercel y Render — nunca en el repositorio. La ANON_KEY de Supabase es la única variable pública (prefijo NEXT_PUBLIC_); no concede permisos de escritura sin RLS.
Activo
06 — Autenticación · SSO Institucional
Login con cuentas @tec.mx vía OAuth2/OIDC de Supabase Auth. La infraestructura está construida (callbacks, cookies httpOnly, logout) pero desactivada en producción hasta finalizar el rol mapping con TI del Tec.
Planeado
07 — Monitoreo · Logs y observabilidad
Logs de errores capturados por Vercel Functions y Render. Variables de entorno auditadas por cambios. Plan: integración con Sentry para alertas en tiempo real ante errores 5xx y excepciones no manejadas.
Parcial
Matriz de amenazas OWASP Top 10
SQL Injection
Todas las queries usan el SDK de Supabase con parámetros tipados. Cero SQL concatenado con input de usuario.
Mitigado
XSS (Cross-Site Scripting)
React escapa HTML por defecto. No se usa dangerouslySetInnerHTML. Cloudflare WAF como segunda capa.
Mitigado
CSRF
API Routes validan Content-Type: application/json. SSO con cookies SameSite=Strict cuando se active.
Parcial
Exposición de credenciales
SERVICE_ROLE_KEY solo en server. ANON_KEY pública pero sin permisos de escritura directa. .env en .gitignore.
Mitigado
DDoS / Flood
Cloudflare absorbe ataques volumétricos antes de llegar a Vercel. Rate limiting automático por IP.
Mitigado
Acceso no autorizado a datos
Sin acceso directo a Supabase desde el cliente. Toda lectura/escritura pasa por API Routes en el servidor.
Mitigado
Inyección en prompts de IA
PHubAgent tiene system prompt con instrucciones de seguridad. Claude tiene mecanismos de defensa ante prompt injection.
Parcial
Session hijacking
Cookies httpOnly + Secure cuando SSO esté activo. Tokens de sesión no expuestos en localStorage.
Planeado
Checklist de controles
HTTPS forzado en todos los endpoints (Cloudflare + Vercel)
SERVICE_ROLE_KEY nunca expuesta al cliente (solo server-side)
Cero SQL concatenado — todas las queries parametrizadas via Supabase SDK
React escapa HTML automáticamente — sin dangerouslySetInnerHTML
Variables de entorno en Vercel y Render — sin secretos en el repo
Cloudflare WAF activo con protección de bots y DDoS
API Routes aisladas — Serverless Functions sin estado compartido
SSO @tec.mx con OAuth2 + cookies httpOnly (Fase 04)
Rate limiting por usuario en endpoints sensibles (Fase 04)
Sentry para monitoreo de errores en tiempo real (Fase 03)
Auditoría de acceso a datos sensibles (logs por usuario)