Safety Policies

Toren is built on the principle that giveaway platforms should be transparent, verifiable, and trustworthy for both the people running giveaways and the people participating in them.

This page explains in plain terms every security and safety measure in place: what permissions we request from third-party platforms, exactly why we need them, how API calls are actually made, and how your data and account are protected at every layer.

Toren operates two distinct categories of credentials: platform credentials (Toren's own developer app keys) and user OAuth tokens (issued when you connect your account).

Platform credentials are Toren's registered developer keys on X and Google. All giveaway data fetching — replies, likes, reposts, follower checks, YouTube comments — is performed using these platform credentials. They are stored as server-side environment variables, never exposed to the browser, and never transmitted over the network except in signed API requests to the respective platforms.

User OAuth tokens are used exclusively for the account verification step during setup. Once your account is connected and verified, Toren relies on its platform credentials for all ongoing giveaway operations. Your personal token sits at rest, encrypted, and is only refreshed when you explicitly reconnect or when Toren needs to re-confirm account ownership.

This design ensures that even if a user's account token were somehow compromised, it would have no effect on the operation of any live giveaway — because the giveaway data pipeline does not use it.

All data stored by Toren is hosted on Supabase, which runs on top of AWS infrastructure. Data at rest is encrypted using AES-256. Data in transit between Toren's application servers, Cloudflare, and Supabase is encrypted using TLS 1.3.

OAuth access tokens and refresh tokens are stored in encrypted columns. They are never returned in any API response, never logged in server logs, and are only decrypted server-side at the moment they are needed for a specific operation.

Passwords are never stored in plain text. Toren uses Supabase Auth for all authentication, which implements bcrypt hashing with a cost factor that makes brute-force attacks computationally infeasible.

Giveaway participant data (usernames, comment text, like/repost status) is stored only for the duration of the giveaway and winner selection process. It is associated with the giveaway owner's account and is not shared with other users or third parties.

Every database table in Toren is protected by Supabase Row-Level Security policies. RLS is a database-level enforcement mechanism — it is not dependent on application code, which means it cannot be bypassed even if there were a bug in Toren's API layer.

RLS policies ensure that each user can only read and write their own records. A user querying their giveaways, connected accounts, or winner records will never see data belonging to another user, regardless of how the query is constructed.

Administrative operations that legitimately require cross-user access (such as platform-wide analytics or support functions) are performed exclusively via a service-role client that operates outside of RLS, and only from authenticated, server-side API routes — never from the browser.

All sensitive API routes verify the authenticated user's identity via Supabase's admin client before executing any database operation, ensuring tokens cannot be spoofed or replayed to gain access to another user's data.

Toren's winner selection process is designed to be cryptographically verifiable and tamper-evident. Every draw is recorded with a generation ID, a timestamp, the full set of eligibility criteria applied, the total participant count, the eligible participant count, and the selection method.

Winners are selected using a cryptographically seeded Fisher-Yates shuffle applied to the eligible participant pool. The shuffle is performed server-side with no client influence over the randomisation, ensuring results cannot be manipulated by refreshing or re-requesting the generation endpoint.

Every winner generation event is written to an immutable winner history table alongside the active winner records. If a re-roll is performed, the previous draw is archived with a replacement timestamp before the new draw is recorded — providing a full chain of custody for every winner selection event.

Fairness proofs are available on each giveaway's public winner page, allowing anyone — including participants — to inspect the seed, hash, draw logs, and total entry counts used for their specific draw.

Toren uses Supabase Auth with the PKCE (Proof Key for Code Exchange) flow for all OAuth sign-ins including X and Google. PKCE prevents authorisation code interception attacks by binding the code exchange to a cryptographic verifier generated at the start of the flow.

Session tokens are short-lived access tokens (1 hour by default) backed by refresh tokens. Toren's client always fetches a fresh access token immediately before making sensitive API calls, ensuring stale tokens are never used for privileged operations.

Logout invalidates the session server-side via Supabase Auth. Connected account tokens can be revoked at any time from the dashboard's account management section — this immediately removes the stored token from Toren's database and triggers revocation requests to the respective platform.

Toren does not implement 'remember me' functionality that stores long-lived credentials in insecure browser storage. Session state is managed exclusively through Supabase Auth's secure cookie and token infrastructure.

If you discover a security vulnerability in Toren, please report it responsibly by emailing toren@torenhub.com with the subject line 'Security Disclosure'.

Include a description of the vulnerability, the steps required to reproduce it, and the potential impact. We will acknowledge your report within 24 hours and provide a timeline for resolution.

We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and address it. We take all security reports seriously and will work promptly to resolve confirmed vulnerabilities.