Seguridad

Las fotos, los vídeos y los demás contenidos subidos a Sweetly no pasan por nuestros servidores de aplicación durante la subida. Tu navegador o tu app pide al backend una URL de subida firmada y de corta duración, y sube el archivo directamente a nuestro almacenamiento de objetos compatible con S3. Esto reduce la superficie de ataque: el servidor de aplicación nunca maneja el archivo en bruto en tránsito, y una URL interceptada deja de funcionar a los pocos minutos.

La lectura funciona igual: cuando se muestra un contenido privado, generamos una URL de lectura firmada válida durante pocos minutos (normalmente 5), en lugar de exponer un enlace permanente al archivo. Los contenidos públicos se sirven a través de una CDN para que carguen más rápido, pero siguen físicamente en el mismo almacenamiento de objetos.

Los documentos subidos para la verificación de edad e identidad (necesarios para registrarse como Performer, conforme al 18 U.S.C. §2257; consulta nuestra declaración específica) se tratan con un nivel de aislamiento superior al del resto de contenidos:

• se guardan en un bucket separado del resto de contenidos de la plataforma, con credenciales propias;
• nunca tienen una dirección pública: no existe ninguna URL que los haga accesibles sin pasar por nuestro sistema de autorización, ni siquiera por un error de configuración;
• el personal solo puede verlos mediante un permiso específico asignado por rol: no basta con ser administrador general de la plataforma;
• cada visualización por parte del personal queda registrada, con quién accedió y cuándo;
• incluso para el personal autorizado, cada visualización genera un nuevo enlace temporal: no guardamos enlaces permanentes al documento, ni siquiera para uso interno.

Las contraseñas nunca se guardan en claro. Usamos Argon2id —el algoritmo de hash de contraseñas recomendado por las guías de OWASP— con parámetros deliberadamente costosos (coste de memoria y número de iteraciones), elegidos para que adivinar contraseñas resulte impracticable incluso partiendo de una copia de la base de datos.

Una sesión activa se compone de dos elementos distintos: un token de acceso firmado y de corta duración, que se usa para las peticiones en curso, y un token de renovación opaco que permite obtener uno nuevo sin volver a introducir la contraseña. El token de renovación nunca se guarda en claro, ni siquiera en el servidor: solo conservamos su huella criptográfica (hash), de modo que ni siquiera un acceso a nuestra base de datos expondría un token utilizable. Puedes cerrar una sesión en cualquier momento: la revocación es inmediata y no espera a que el token caduque.

El inicio de sesión, el registro y la recuperación de contraseña están protegidos por límites de frecuencia calculados por dirección IP y por el valor concreto implicado (por ejemplo, la dirección de correo usada): esto frena tanto un ataque masivo desde una sola dirección como los intentos repetidos contra una misma cuenta desde direcciones distintas. Un límite general de peticiones para toda la plataforma añade una capa más de protección frente a abusos a gran escala.

El número de tu tarjeta, la fecha de caducidad y el código de seguridad nunca llegan a nuestros servidores, en ningún momento. Cuando compras tokens o activas una suscripción, te redirigimos a la página segura del proveedor de pagos, que gestiona íntegramente la recogida y el tratamiento de los datos de la tarjeta según los estándares de seguridad del sector (PCI DSS). Nuestro sistema solo recibe del proveedor de pagos una confirmación firmada del resultado, sin llegar a tener nunca los datos sensibles de la tarjeta.

Los datos bancarios o de pago que una Performer registra para recibir sus ganancias se cifran campo por campo en la base de datos con AES-256-GCM, un cifrado autenticado, con un vector de inicialización distinto generado para cada valor guardado. Incluso en caso de acceso no autorizado solo a la base de datos, esta información seguiría siendo ilegible sin la clave de cifrado, que se custodia por separado.

Nuestro personal no tiene un acceso indiscriminado a todos los datos de la plataforma. Cada cuenta interna tiene permisos granulares asignados por rol, y las operaciones sobre datos sensibles —como revisar un documento de verificación o una solicitud de eliminación de contenido— siguen sujetas al permiso específico necesario, con registro de quién hizo qué.

En producción, todo el tráfico entre tu navegador y Sweetly viaja por una conexión cifrada (HTTPS/TLS): las cookies de sesión están marcadas como seguras y nunca se transmiten por una conexión sin cifrar.

Si has encontrado un fallo de seguridad en Sweetly, te pedimos que nos lo comuniques de forma responsable antes de hacerlo público, para darnos tiempo a corregirlo: escribe a [email protected] con los detalles necesarios para reproducir el problema. No usaremos en tu contra una comunicación hecha de buena fe, siempre que no accedas a datos más allá del mínimo necesario para demostrar el fallo.