Seguridad

Un reporte de bug puede contener lo que tus usuarios ven y escriben. Por eso la protección empieza en su navegador, antes de que nada se envíe.

#En el navegador: enmascarar antes de enviar

• Nada se sube hasta que la persona envía el reporte. Mientras tanto, el replay, la consola y la red viven solo en la memoria de la pestaña (unos 2 minutos) y se descartan continuamente. La excepción es la captura automática en modo "automático", que el cliente debe activar explícitamente y que tiene límites estrictos por sesión.
• Formularios y contraseñas enmascarados por defecto en el replay y en la captura de pantalla. Las contraseñas, siempre.
• Headers sensibles reemplazados: Authorization, Cookie, Set-Cookie, X-Api-Key, tokens CSRF y otros.
• Claves sensibles en JSON, formularios y URLs (password, token, secret, api_key, session, card, cvv…) reemplazadas por [REDACTED].
• Detección en texto libre de JWT, credenciales Bearer/Basic, keys de Stripe, GitHub, Slack y AWS, y números de tarjeta válidos (Luhn).
• Los clientes pueden ocultar elementos completos, agregar reglas propias y revisar o descartar cada reporte con beforeSend.
• El widget vive en un Shadow DOM aislado y no instala cookies.

Detalles técnicos en Privacidad y enmascarado.

#En tránsito

• Toda la comunicación usa HTTPS (TLS).
• El SDK sube los archivos del reporte directo al almacenamiento con URLs firmadas que vencen en 10 minutos y tienen el tamaño exacto firmado: no se pueden reutilizar ni usar para subir otra cosa.
• La API solo acepta reportes desde los orígenes permitidos de cada proyecto.

#En reposo

• Base de datos y archivos alojados en Neon (Postgres y almacenamiento de objetos) en AWS us-east-2, cifrados en reposo por el proveedor.
• Credenciales de integraciones (tokens OAuth, API keys, secretos de webhooks) cifradas a nivel de aplicación con AES-256-GCM. Nunca se envían al navegador.
• Tokens de API/MCP (wbt_…) y claves secretas de proyecto (sk_…): solo guardamos su hash SHA-256. Se muestran una vez al crearlos y se pueden revocar o regenerar.
• Contraseñas gestionadas por el servicio de autenticación de Neon, que solo guarda un hash.
• Seguridad a nivel de fila (RLS) activada en todas las tablas, sin políticas de acceso público: ningún dato es accesible a través de una API de datos directa. Solo los servidores de Wutbug se conectan a la base de datos.

#Control de acceso

• Cada reporte pertenece a un proyecto y cada proyecto a un equipo. El acceso se verifica en cada solicitud contra la membresía actual: si alguien deja el equipo, pierde el acceso de inmediato, también en sus tokens MCP.
• Roles owner, admin y member: solo owners y admins configuran proyectos, integraciones y personas. Ver Equipo y roles.
• Enlaces para compartir un reporte y la página de la persona que reportó usan tokens aleatorios largos, no aparecen en buscadores y se pueden desactivar. La página de la persona que reportó solo muestra su descripción y la conversación pública, nunca el replay, la consola, la red ni las notas internas.
• Los webhooks entrantes de integraciones se verifican con firma HMAC o JWT.

#Protección contra abuso

Límites de tasa por IP y por proyecto, cuotas por plan, detección de reportes duplicados, límite de subidas pendientes y listas de bloqueo por IP y origen. Las IPs se usan solo en contadores temporales y no se guardan en los reportes. Ver Retención y límites.

#Retención y borrado

• Retención configurable por proyecto (7 a 365 días; 30 por defecto). Un proceso automático borra los reportes vencidos: primero los archivos, luego los registros.
• Subidas incompletas borradas después de 1 hora.
• Eliminar un equipo borra todos sus proyectos, reportes, grabaciones e integraciones.

#Inteligencia artificial

El resumen de cada reporte se genera en el servidor a través de OpenRouter con un modelo de bajo costo, con los datos ya enmascarados y enrutado solo a proveedores que no guardan los prompts ni entrenan con ellos. No usamos reportes para entrenar modelos.

#Incidentes

Si ocurre un incidente que afecte datos personales, avisaremos a los clientes afectados sin dilación indebida y dentro de 48 horas desde que lo confirmemos, según el DPA.

#Reportar una vulnerabilidad

Escríbenos a [Email de seguridad] con los detalles. Respondemos en un plazo de [N] días hábiles y no emprenderemos acciones legales contra investigaciones de buena fe que respeten la privacidad de los usuarios y no afecten el Servicio.