01 Controles de seguridad implementados

1.1 Autenticación y autorización

• Contraseñas almacenadas con Argon2id (RFC 9106) con parámetros seguros de memoria y iteraciones.
• Rate limiting en endpoints de autenticación: bloqueo automático tras 10 intentos fallidos consecutivos.
• Sesiones con cookies HttpOnly, Secure y SameSite=None donde aplica.
• Tokens OAuth firmados con claves RSA-256 mediante JWKS rotable.
• PKCE obligatorio para todos los flujos OAuth, incluyendo clientes confidenciales.
• Validación byte-a-byte de redirect URIs contra las registradas.
• Tokens de corta duración: access tokens de 1 hora, refresh tokens de 30 días con rotación.

1.2 Protección de aplicaciones web

• Cabeceras de seguridad HTTP: X-Content-Type-Options, X-Frame-Options: DENY, Strict-Transport-Security, Referrer-Policy.
• Protección CSRF mediante tokens firmados criptográficamente en todos los formularios.
• Sanitización y escapado de todas las salidas HTML para prevenir XSS.
• Consultas parametrizadas (PDO prepared statements) para prevenir SQL injection.
• Validación estricta de tipos y rangos en todos los inputs de la API.
• HTTPS obligatorio en toda la plataforma; HTTP redirigido automáticamente.

02 Cifrado y criptografía

03 Control de acceso interno

• Principio de mínimo privilegio: El personal de Zyndhux solo tiene acceso a los datos estrictamente necesarios para sus funciones.
• Separación de entornos: Los entornos de desarrollo, staging y producción están completamente aislados.
• Acceso a producción: Restringido a personal autorizado con registro de auditoría de cada acceso.
• Revisión periódica: Los permisos de acceso se revisan trimestralmente.
• Offboarding: Los accesos se revocan inmediatamente al finalizar la relación laboral o contractual.

04 Infraestructura y operaciones

4.1 Hosting y datos

• Infraestructura operada en servidores de Hostinger con ubicación en la Unión Europea.
• Backups automáticos diarios con retención de 30 días.
• Monitoreo de disponibilidad con alertas automáticas ante caídas.

4.2 Base de datos

• Acceso a base de datos restringido por IP; sin exposición directa a internet.
• Credenciales de base de datos en variables de entorno; nunca en código fuente.
• Backups cifrados con verificación de integridad.

4.3 Monitoreo

• Logs de seguridad centralizados con retención de 2 años.
• Alertas automáticas ante patrones anómalos: múltiples fallos de autenticación, picos de rate, accesos desde IPs inusuales.
• Revisión periódica de logs por el equipo de seguridad.

05 Recomendaciones de seguridad para developers

5.1 Gestión de credenciales

• Almacena el client_secret exclusivamente en variables de entorno del servidor. Nunca en código fuente, repositorios Git ni archivos de configuración sin cifrar.
• Rota el client_secret periódicamente y siempre ante sospecha de compromiso.
• Usa secrets managers (como HashiCorp Vault o servicios cloud equivalentes) en producción.
• Implementa PKCE aunque tu App sea un cliente confidencial.

5.2 Manejo de tokens

• No almacenes access tokens en localStorage o sessionStorage. Usa cookies HttpOnly.
• Implementa la renovación automática de tokens con refresh token antes de la expiración.
• Revoca los tokens del usuario cuando cierre sesión en tu App mediante el endpoint /oauth/revoke.
• Valida el campo iss e aud del id_token antes de usarlo.

5.3 Redirect URIs

• Registra solo URIs exactas — sin wildcards ni subpaths genéricos.
• Usa HTTPS en producción para todas las redirect URIs.
• Elimina URIs de staging/desarrollo antes de pasar a producción.

5.4 Scopes

• Solicita solo los scopes que tu App realmente necesita.
• Explica claramente a tus usuarios por qué necesitas cada scope.
• Nunca solicites scopes adicionales en un flujo de autorización ya existente sin informar al usuario.

06 Respuesta a incidentes de seguridad

6.1 Proceso interno de Zyndhux

6.2 Notificación a developers

Si un incidente afecta datos de tus usuarios obtenidos a través de las APIs de Zyndhux, te notificaremos en un plazo máximo de 72 horas desde la detección, incluyendo: naturaleza del incidente, datos afectados, medidas adoptadas y recomendaciones para tu App.

6.3 Tu obligación de notificación

Si detectas o sospechas de una brecha en tu App que involucre datos obtenidos de las APIs de Zyndhux, debes notificarnos en menos de 24 horas a security@zyndhux.com.

07 Política de divulgación responsable

Si has encontrado una vulnerabilidad de seguridad en la plataforma Zyndhux, te pedimos que la reportes de forma responsable siguiendo este proceso:

7.1 Cómo reportar

1. Envía un email a security@zyndhux.com con el asunto [SECURITY] Nombre descriptivo.
2. Describe la vulnerabilidad: tipo, componente afectado, pasos para reproducir, impacto potencial.
3. Si es posible, incluye un proof-of-concept (PoC) que demuestre el problema sin causar daño.
4. Proporciona tu información de contacto para el seguimiento.

7.2 Compromisos de Zyndhux

• Acusar recibo del reporte en 48 horas hábiles.
• Mantenerte informado del progreso de la investigación.
• No emprender acciones legales contra investigadores de buena fe que sigan esta política.
• Reconocer tu contribución públicamente si lo deseas (Hall of Fame).
• Resolver vulnerabilidades críticas en 7 días, altas en 30 días, medias en 90 días.

7.3 Reglas del investigador

• No accedas a datos de otros usuarios. Usa solo cuentas de prueba propias.
• No realices pruebas que degraden la disponibilidad del servicio (DoS).
• No divulgues la vulnerabilidad públicamente antes de que Zyndhux la haya corregido.
• No uses la vulnerabilidad para fines distintos a la demostración del problema.
• Respeta el período de embargo coordinado con Zyndhux antes de publicar.

08 Programa de Bug Bounty

8.1 Fuera de scope

• Ataques de ingeniería social o phishing contra empleados de Zyndhux.
• Ataques de denegación de servicio (DoS/DDoS).
• Vulnerabilidades en dependencias de terceros sin impacto demostrable en Zyndhux.
• Reportes generados por scanners automáticos sin análisis manual de impacto.
• Problemas en infraestructura no operada por Zyndhux.

09 Contacto de seguridad