Tomamos la seguridad muy en serio en Oxy. Esta semana identificamos y solucionamos 8 problemas en OxyHQ Services, nuestro módulo backend principal que potencia la autenticación, facturación y gestión de sesiones. Esto es lo que arreglamos y por qué es importante.

Reparaciones Críticas

Validación del secreto del webhook de Stripe al inicio (#183): La función getWebhookSecret() podría devolver una cadena vacía en tiempo de ejecución si no se establecía la variable de entorno. Aunque constructEvent de Stripe fallaría por solicitud, el endpoint webhook seguía registrado y aceptando solicitudes. Ahora validamos el secreto al iniciar el servidor y fallamos rápido si falta.

Límites en la cantidad de crédito de facturación (#182): Nuestro proceso de compra de créditos almacenaba créditos de paquete en los metadatos de Stripe, pero el manejador de webhook que procesaba compras completadas no volvía a validar la cantidad de crédito contra nuestros paquetes conocidos. Un webhook falsificado o repetido con metadatos modificados podrían, teóricamente, otorgar créditos ilimitados. Añadimos revalidación por el lado del servidor y limitamos las cantidades de crédito en el manejador del webhook.

Lista blanca de origen CORS de FedCM (#181): Los endpoints de FedCM reflejaban cualquier origen de solicitud en los encabezados CORS combinados con Access-Control-Allow-Credentials: true. Sin una lista blanca de origen, cualquier dominio podría obtener potencialmente tokens de identificación o información de cuenta de usuario. Implementamos una lista de permitidos de origen estricta para todos los endpoints relacionados con FedCM.

Reparaciones de Alta Severidad

Evitar CSRF por medio del encabezado X-Native-App (#184): Cualquier solicitud con el encabezado X-Native-App: true estaba evitando la coincidencia de la cookie CSRF completamente. El middleware solo verificaba que el token del encabezado existiera y cumpliera una longitud mínima. Apretamos esto al requerir una validación adecuada del token sin importar el encabezado de la aplicación nativa.

Fuga de memoria en la gestión de sesiones (#189): La función trackRemovedSession utilizaba callbacks de setTimeout que nunca eran limpiados al desmontar un componente. Con eliminaciones frecuentes de sesiones, los callbacks de temporizador se acumulaban y mantenían referencias a refs obsoletas. Añadimos limpieza adecuada al desmontar.

Cierre obsoleto en la restauración de sesión de OxyProvider (#187): El callback restoreSessionsFromStorage capturaba dependencias que cambiaban cuando cambiaba el array de sesiones, causando que los efectos se ejecutaran de nuevo con cierres obsoletos. Esto creaba condiciones de carrera durante la restauración de sesiones. Reestructuramos la cadena de dependencias para prevenir capturas obsoletas.

Reparaciones de Media Severidad

Limpiar el iframe de verificación de sesión IdP (#192): Llamadas rápidas a checkIdPSession podían sobrescribir la referencia de limpieza sin llamar a la función de limpieza anterior, dejando iframes huérfanos en el DOM. Ahora siempre llamamos a la limpieza anterior antes de establecer una nueva.

Invalidación de caché de sesión (#196): getUserBySession() almacenaba en caché las respuestas con un TTL de 2 minutos, pero si una sesión era revocada por el servidor, el cliente seguía sirviendo datos obsoletos. Ahora invalidamos la caché inmediatamente cuando falla una validación de sesión.

¿Qué sigue?

Continuamos auditando nuestra infraestructura de autenticación y facturación. Todas las reparaciones están disponibles ahora en la última versión de @oxyhq/services. Si estás construyendo sobre los Servicios de Oxy, actualiza tus dependencias para obtener estos parches.

Puedes seguir todos los problemas abiertos y contribuir con soluciones en nuestro repositorio de GitHub.