1. Modelo de seguridad actual
Magnetia separa la superficie pública de la aplicación privada. La biblioteca y el editor se encuentran detrás de validación de sesión, mientras que el API protege sus endpoints y la propiedad de las pizarras.
2. Contraseñas y sesiones
- Las contraseñas de cuenta se procesan mediante funciones de hash del servidor; no se guardan como texto plano.
- Las sesiones autenticadas se gestionan desde el servidor, utilizan cookies HttpOnly y pueden revocarse individualmente desde Seguridad de la cuenta.
- Los enlaces de verificación y recuperación usan tokens aleatorios, hasheados en MySQL, con expiración y uso único.
- El código beta es una puerta temporal para crear cuentas y no reemplaza la autenticación personal.
Los intentos fallidos de login y solicitudes sensibles incorporan límites básicos para reducir abuso automatizado. Un restablecimiento de contraseña revoca todas las sesiones activas.
3. Protección de pizarras
Las pizarras cloud tienen identidad persistente, propietario y revisión. El control de revisión evita que una respuesta antigua sobrescriba silenciosamente una versión nueva. Antes de restaurar historial, Magnetia conserva un punto seguro del estado actual.
4. Local-first y continuidad
Los cambios se guardan primero en IndexedDB y después se sincronizan. Si la conexión falla, la cola local conserva cambios pendientes para reintentarlos posteriormente.
5. Transporte y hosting
En producción, Magnetia debe utilizarse mediante HTTPS. V1.7.7.3 añade cabeceras públicas defensivas cuando el hosting Apache soporta mod_headers.
No afirmamos cifrado de extremo a extremo, cifrado específico de contenido en reposo, certificaciones de seguridad ni arquitectura zero-knowledge.
6. Superficie pública mínima
La landing no incorpora trackers publicitarios en esta versión. Los eventos de conversión preparados en el frontend permanecen locales salvo que en el futuro se conecte explícitamente una plataforma analítica.
7. Reporte responsable de seguridad
Si encuentras una vulnerabilidad, evita acceder a información ajena, modificar datos de terceros o degradar el servicio. Puedes reportarla mediante Contacto indicando que se trata de un reporte de seguridad.
También se publica /.well-known/security.txt para facilitar el reporte responsable.
8. Qué sigue pendiente
Antes de una expansión pública amplia recomendamos revisar adicionalmente: políticas de rotación de sesiones, rate limiting avanzado, auditoría de dependencias, backups del servidor, recuperación ante desastre y una revisión externa de seguridad.