Last updated 2026-07-08. Written in plain language by the people who built this, describing exactly what the software does — not boilerplate copied from somewhere else. If a claim below stops being true, this page is wrong and should be fixed, not the other way around.
Account: your email and password. Passwords are handled entirely by Supabase Auth — we never see or store a plaintext password, only what Supabase Auth manages on our behalf.
Signed-in scans: the URL or code you scan, and the full findings (secret matches, header issues, cross-account results, design tells). Full evidence — masked secrets, exact file locations, proof lines — is automatically deleted 1 hour after the scan completes, regardless of whether you looked at it. What survives permanently is a summary only: the URL, the date, total finding count, worst severity, and the design/slop bucket — never the evidence itself. See retention below for the exact mechanics.
Every scan, including without an account: we log an aggregate-only record — the domain scanned, which checks ran, finding counts per category, worst severity, and the design score/bucket. Never the actual evidence, masked secrets, file paths, or fix-prompt text, and never tied to any identity for anonymous scans. This exists solely so we can validate the design-tell detector against real traffic over time; it is never shown to any user (including you) and never published.
IP address, briefly, for abuse prevention only:each scan request is rate-limited. For signed-in users the limit is keyed to your account; for anonymous requests it's keyed to your IP address, stored as part of a small counter row (address + a request count + a timestamp — nothing else). That counter row is deleted automatically once it's a day old, whether or not you ever came back. We don't use IP addresses for anything besides this counter — no location profiling, no cross-session tracking.
Cross-account (BOLA) test, if you use it:you supply credentials for two of your own test accounts against your own Supabase project, plus that project's URL and public API key. All of it is used only in memory for that one request and is never stored or logged anywhere, in our database or in server logs.
Dependency audit, if you use it:if you upload a package-lock.json, only the package name/version pairs it lists are sent to npm's public advisory API to check for known vulnerabilities. The uploaded file itself isn't stored beyond that request. If you instead paste pre-computed npm audit --jsonoutput, the same applies — we parse it in memory and don't retain the raw file.
Ordinary infrastructure logs:like effectively every website, our hosting provider (Vercel) keeps short-lived operational logs (timestamps, request paths, status codes, IP) for debugging and abuse detection at the platform level. We don't build any feature on top of these beyond what's described above, and we don't export or aggregate them ourselves.
We don't sell your data, to anyone, ever. We don't run ads or any third-party analytics/tracking scripts on this site — there are none in the code, not just a policy promise; you can verify this yourself by reading the page source. We don't publish your scan results anywhere — there is no public registry or shareable link for any scan, and there never has been. We don't email you anything except transactional account messages (confirm your email, reset your password) — no newsletters, no marketing, no re-engagement drip.
Vercel hosts the app and runs the scan itself (including the headless browser used for the design check). Supabase handles authentication and stores your account and scan data in Postgres. Resend delivers transactional email (confirmation, password reset) on our behalf. When you run a dependency audit, npm's public registryreceives the package name/version pairs from your lockfile — nothing else. No other third party receives your data, and we don't use any data brokers, ad networks, or analytics platforms.
Your account and scan data is stored in Supabase's US-East (Ohio) region. The application itself runs on Vercel's infrastructure, which defaults to US regions for server-side execution; static assets are served from Vercel's global edge network regardless of where you are. We haven't configured any additional geographic data residency options — if you have a specific regional-storage requirement, contact us before relying on this being sufficient.
Full scan evidence (masked secrets, proof lines, exact file paths, cross-account proof, fix-prompt text): deleted automatically 1 hour after the scan completes, via a scheduled database job that runs every 15 minutes. Not soft-deleted — the columns are set to null and the underlying storage is reclaimed by Postgres normally.
Scan summary (URL, date, finding counts, worst severity, design bucket): kept indefinitely, tied to your account, until you delete your account or the specific scan.
Aggregate calibration log(domain + score/bucket, no evidence, not tied to identity for anonymous scans): kept indefinitely for product-improvement purposes. It contains nothing personally identifying for anonymous use, and for signed-in use it's the same non-evidence data already covered above.
Rate-limit counters (IP or account + a count + a timestamp): deleted automatically once a day old.
Account data (email, auth records): kept until you delete your account, at which point it is removed immediately and permanently — see deleting your data.
This is a security-auditing tool, so we hold ourselves to the same bar we check for in your app: HTTPS everywhere, a Content-Security-Policy and standard security headers on this site itself (you can check — it's one of the things Risetris tests for), row-level security policies in Postgres scoping every account to only its own data, password handling delegated entirely to Supabase Auth rather than hand-rolled, rate limiting and SSRF protection on the scanning endpoint, and no service-role/admin database key anywhere in the application code — sensitive database operations run through narrowly-scoped functions instead. No system is perfect; if you find a real vulnerability in Risetris itself, we want to know about it before anyone else does.
You can access everything we hold about your account by looking at your dashboard — there's no hidden data beyond what's shown there plus the account email itself. You can correct your account email or password directly. You can export your own scan summaries by copying them from the dashboard (there is no separate bulk-export tool today; ask if you need one). You can delete everything, immediately and permanently, yourself, at any time — see below. If you're in a jurisdiction that grants you additional formal rights (GDPR, CCPA, or otherwise) beyond what self-service already covers, contact us and we'll handle the request directly rather than pointing you back at this page.
Your dashboard has a Delete my account button that immediately and permanently deletes your account and every scan tied to it. There is no recovery period, no soft-delete, and no support request needed — confirming the action removes the underlying database rows right away.
Risetris is built to audit apps you own or have explicit permission to test. The cross-account (BOLA) probe in particular writes real rows to whatever Supabase project you point it at — only run it against your own project with your own test accounts. Running any check against a site or backend you don't control, without permission, is your responsibility, not something Risetris authorizes or monitors for.
Risetris isn't directed at children and we don't knowingly collect data from anyone under 13. If you believe a child has created an account, contact us and we'll delete it.
If what the software actually does changes in a way that affects this page, we'll update it and change the "last updated" date at the top. We won't backdate changes or make retroactive claims about what an older version of the app did.
[contact address to be added — this section is a placeholder until a monitored inbox is set up]
This is a plain-language description of what the software actually does, written by the people who built it — not a substitute for legal advice. If you have specific compliance requirements (GDPR, CCPA, or otherwise), please reach out before relying on this page alone.