# 🔒 Reporte de Seguridad del Proyecto Karibeo

## ⚠️ ADVERTENCIAS CRÍTICAS DE SEGURIDAD

### 1. CRÍTICO: Verificación de Roles del Cliente (NO SEGURO PARA PRODUCCIÓN)

**PROBLEMA**: El sistema actual verifica roles de administrador usando el objeto `user` almacenado en localStorage del cliente.

**Archivos afectados**:
- `src/hooks/useAdminData.ts` (línea 18)
- `src/hooks/useEmergencyData.ts` (línea 16)
- `src/App.tsx` (línea 131)
- `src/pages/SignIn.tsx` (línea 33)

**Por qué es inseguro**:
```typescript
// ❌ INSEGURO - Un atacante puede modificar localStorage
const isAdmin = user?.role === 'admin';
```

Un atacante puede:
1. Abrir DevTools en el navegador
2. Modificar `localStorage.setItem('karibeo-user', JSON.stringify({...user, role: 'admin'}))`
3. Obtener acceso completo al panel de administración

**SOLUCIÓN REQUERIDA PARA PRODUCCIÓN**:

#### Opción A: Backend con verificación de roles (RECOMENDADO)
1. Crear tabla `user_roles` en la base de datos (separada de `users`/`profiles`)
2. Implementar verificación de roles en el backend
3. Cada endpoint de API debe verificar permisos en el servidor
4. Usar Row Level Security (RLS) en Supabase

```sql
-- Ejemplo de estructura segura
CREATE TABLE user_roles (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID REFERENCES auth.users(id) ON DELETE CASCADE,
    role TEXT NOT NULL CHECK (role IN ('admin', 'super_admin', 'user', 'hotel', 'restaurant')),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    UNIQUE(user_id, role)
);

-- Función de seguridad definer (evita recursión RLS)
CREATE OR REPLACE FUNCTION has_role(_user_id UUID, _role TEXT)
RETURNS BOOLEAN
LANGUAGE SQL
STABLE
SECURITY DEFINER
SET search_path = public
AS $$
  SELECT EXISTS (
    SELECT 1 FROM user_roles
    WHERE user_id = _user_id AND role = _role
  )
$$;

-- Política RLS usando la función
CREATE POLICY "Only admins can view all data"
ON some_table
FOR SELECT
TO authenticated
USING (has_role(auth.uid(), 'admin'));
```

#### Opción B: Sin Backend
Si NO puedes implementar backend:
1. **Aceptar el riesgo** - La verificación del cliente es solo para UX
2. **No almacenar datos sensibles** - Nada crítico debe depender de roles
3. **Implementar ofuscación** - Dificultar (no prevenir) manipulación
4. **Rate limiting** - Limitar llamadas a API

### 2. Validación de Inputs Insuficiente

**PROBLEMA**: La mayoría de formularios no tienen validación robusta.

**Archivos sin validación**:
- ✅ `src/pages/SignIn.tsx` - **CORREGIDO**
- ✅ `src/pages/SignUp.tsx` - **CORREGIDO**
- ❌ `src/pages/dashboard/AddListing.tsx`
- ❌ `src/pages/dashboard/Settings.tsx`
- ❌ `src/pages/dashboard/Profile.tsx`

**Riesgos**:
- Inyección SQL (si el backend no valida)
- XSS (Cross-Site Scripting)
- Datos corruptos en la base de datos
- Buffer overflow en campos de texto

**SOLUCIÓN IMPLEMENTADA**:
- Creado `src/lib/validation.ts` con schemas de validación usando zod
- Actualizado SignIn.tsx con validación completa
- Actualizado SignUp.tsx con validación robusta

### 3. Credenciales Mock Hardcoded

**PROBLEMA**: Usuarios de prueba con contraseñas conocidas en `src/contexts/AuthContext.tsx`

```typescript
// ⚠️ DESARROLLO SOLAMENTE
const mockUsers = {
  'superadmin@karibeo.com': { password: '123456', role: 'super_admin' },
  'admin@karibeo.com': { password: '123456', role: 'admin' },
  'user@karibeo.com': { password: '123456', role: 'tourist' }
};
```

**SOLUCIÓN**:
- ✅ Agregada documentación clara de que es solo para desarrollo
- ⚠️ **CRÍTICO**: Eliminar estos usuarios antes de producción
- ⚠️ **CRÍTICO**: Usar variables de entorno para credenciales de prueba

### 4. Tokens en localStorage

**PROBLEMA**: Tokens JWT almacenados en localStorage son vulnerables a XSS.

**Estado actual**:
```typescript
localStorage.setItem('karibeo-token', token);
```

**Riesgo**: Si hay una vulnerabilidad XSS, un atacante puede robar tokens.

**SOLUCIÓN (para implementar)**:
- Usar HttpOnly cookies (requiere backend)
- Implementar refresh tokens con rotación
- Tokens de corta duración (15 minutos)
- Refresh tokens en HttpOnly cookies

### 5. Sin Rate Limiting

**PROBLEMA**: No hay protección contra ataques de fuerza bruta en login.

**SOLUCIÓN REQUERIDA**:
- Implementar rate limiting en el backend
- Bloquear IPs después de N intentos fallidos
- Captcha después de 3 intentos
- Retrasos progresivos entre intentos

## ✅ Mejoras Implementadas

1. **Validación de Inputs con Zod**
   - Schemas de validación centralizados en `src/lib/validation.ts`
   - Validación de email, password, nombres, teléfonos
   - Mensajes de error descriptivos
   - Protección contra caracteres maliciosos

2. **Documentación de Seguridad**
   - Este documento SECURITY.md
   - Comentarios de advertencia en código crítico
   - Guías de implementación segura

3. **Mejora de Formularios de Autenticación**
   - SignIn con validación completa
   - SignUp con validación de password seguro
   - Manejo de errores mejorado

## 📋 Checklist de Seguridad para Producción

### ANTES DE DEPLOY:
- [ ] Eliminar usuarios mock de AuthContext.tsx
- [ ] Implementar verificación de roles en el backend
- [ ] Crear tabla user_roles separada
- [ ] Implementar RLS policies en Supabase
- [ ] Migrar tokens a HttpOnly cookies
- [ ] Implementar rate limiting
- [ ] Auditar todos los endpoints de API
- [ ] Habilitar CORS solo para dominios conocidos
- [ ] Configurar CSP (Content Security Policy)
- [ ] Implementar logging de intentos de acceso no autorizado
- [ ] Agregar validación en TODOS los formularios
- [ ] Sanitizar HTML en campos de texto rico
- [ ] Configurar HTTPS obligatorio
- [ ] Implementar 2FA para administradores
- [ ] Revisar dependencias con `npm audit`
- [ ] Configurar variables de entorno adecuadamente
- [ ] Implementar monitoreo de seguridad

### TESTING DE SEGURIDAD:
- [ ] Pruebas de penetración
- [ ] Análisis de vulnerabilidades XSS
- [ ] Análisis de inyección SQL
- [ ] Pruebas de escalación de privilegios
- [ ] Pruebas de autenticación bypass
- [ ] Pruebas de CSRF

## 🔗 Recursos Adicionales

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Supabase Security Best Practices](https://supabase.com/docs/guides/auth/row-level-security)
- [JWT Security Best Practices](https://tools.ietf.org/html/rfc8725)
- [Input Validation with Zod](https://zod.dev/)

## 📞 Contacto de Seguridad

Si descubres una vulnerabilidad de seguridad, por favor NO la publiques públicamente. Contacta al equipo de desarrollo directamente.

---

**Última actualización**: ${new Date().toISOString().split('T')[0]}
**Versión del documento**: 1.0
**Estado**: Desarrollo - NO apto para producción sin correcciones