Security

Photos, videos, and other content uploaded to Sweetly do not pass through our application servers during upload. Your browser or app requests a short-lived, signed upload URL from the backend and uploads the file directly to our S3-compatible object storage. This reduces the attack surface: the application server never handles the raw file in transit, and an intercepted URL stops working after a few minutes.

Reading works the same way: when a piece of private content is displayed, we generate a signed read URL valid for a few minutes (typically 5), rather than exposing a permanent link to the file. Public content is served through a CDN for faster loading, but remains physically on the same object storage.

Documents uploaded for age and identity verification (required to register as a Performer, in compliance with 18 U.S.C. §2257 — see our dedicated statement) are handled with a higher level of isolation than other content:

• they are stored in a bucket separate from the rest of the platform's content, with its own dedicated credentials;
• they never have a public address — there is no URL that makes them accessible without going through our authorization system, not even by misconfiguration;
• staff can only view them through a specific permission assigned at the role level — being a general platform administrator is not enough on its own;
• every single staff view is logged, recording who accessed it and when;
• even for authorized staff, each view generates a new temporary link — we do not keep permanent links to the document, not even for internal use.

Passwords are never stored in plain text. We use Argon2id — the password-hashing algorithm recommended by OWASP guidelines — with deliberately expensive parameters (memory cost and iteration count), chosen to make guessing passwords impractical even starting from a copy of the database.

An active session is made up of two distinct elements: a short-lived signed access token used for current requests, and an opaque refresh token that lets you obtain a new one without re-entering your password. The refresh token is never stored in plain text, even server-side — we only keep its cryptographic fingerprint (hash), so that even access to our database would not expose a usable token. You can end a session at any time — revocation is immediate and does not wait for the token to expire naturally.

Login, registration, and password recovery are protected by rate limits calculated per IP address and per the specific value involved (for example, the email address used): this slows down both a broad attack from a single address and repeated attempts against a single account from different addresses. A platform-wide request rate limit adds an additional layer of protection against large-scale abuse.

Your card number, expiry date, and security code never reach our servers, at any point. When you purchase tokens or activate a subscription, we redirect you to the payment provider's secure page, which handles the collection and processing of card data entirely according to industry security standards (PCI DSS). Our system only receives a signed confirmation of the outcome from the payment provider, without ever taking possession of sensitive card data.

Banking or payment details a Performer registers to receive earnings are encrypted at the individual field level in the database, using AES-256-GCM — an authenticated encryption scheme, with a distinct initialization vector generated for every value stored. Even in the event of unauthorized access to the database alone, this information would remain unreadable without the encryption key, which is held separately.

Our staff does not have undifferentiated access to all platform data. Every internal account has granular permissions assigned by role, and operations on sensitive data — such as reviewing a verification document or a content-removal request — remain bound to the specific permission required, with tracking of who did what.

In production, all traffic between your browser and Sweetly travels over an encrypted connection (HTTPS/TLS): session cookies are marked secure and are never transmitted over an unencrypted connection.

If you have found a security flaw in Sweetly, please report it responsibly before disclosing it publicly, so we have time to fix it: email [email protected] with the details needed to reproduce the issue. We will not hold a good-faith report against you, provided you do not access data beyond the minimum necessary to demonstrate the flaw.