Security

How to Report

Email us at [email protected]. There is no form and no ticket portal, and it reaches a person rather than a queue.

Include whatever it takes to reproduce the issue: the URL or endpoint, the steps you took, and what you saw happen. A short proof of concept is worth more than a long write-up. If you are not sure whether something counts as a vulnerability, send it anyway and we will tell you.

Safe Harbor

If you make a good-faith effort to follow this policy, we will treat your research as authorized. We will not pursue legal action against you, we will not refer you to law enforcement, and if someone else brings a claim against you over research that followed this policy, we will make it known that your actions were authorized. This covers claims under the Computer Fraud and Abuse Act and anti-circumvention claims under the DMCA.

This is a commitment we can only make on our own behalf. It does not authorize you to act against another person's data or account, and it cannot waive rights held by anyone else, including the providers whose infrastructure we run on.

If you are unsure whether a particular test would stay inside this policy, ask first at [email protected] and we will give you a straight answer.

Rules for Testing

These exist so that finding a bug never requires harming anyone.

• Test against surveys and accounts you created yourself. Creating one is free and takes seconds, so there is never a reason to use somebody else's.
• If you find a way to reach something that is not yours, stop as soon as you can prove it works. Do not read, download, keep, or share other people's data. A single record, or a screenshot of the response headers, is proof enough.
• Do not run load tests or anything else that degrades the service for other people. We already know roughly where our write throughput gives out, and confirming it is not a finding.
• Keep automated scanning to a level that does not generate meaningful traffic against the live site.
• No social engineering, phishing, or physical attempts against us, our users, or our providers.
• Delete anything you obtained during testing once you have reported it.
• Give us reasonable time to fix an issue before publishing. Our default is ninety days from your report, and we are usually much faster. If you think something warrants disclosing sooner, say so and we will work it out with you.

In Scope

Anything you can reach at rifts.to, including:

• The web application and the public API.
• Sign-in, including the emailed code and the session cookie.
• The OAuth flow and the API tokens used by connected clients such as AI assistants.
• Billing, including anything that grants paid features without an active subscription.
• Any bug that reveals a survey's admin link to somebody who was never given it. This is the highest-impact class of issue in this product and we treat it that way.
• Any bug that lets one account reach another account's saved surveys, profile, tokens, or survey responses.

Out of Scope

We will close the following without much discussion. The first is the report we expect to receive most often, so it is worth reading before you write it up.

• Anyone holding a survey's admin link can administer that survey. This is the design, not a flaw. The admin link is the survey's only credential, and attaching a survey to an account is a bookmark that helps you find the link again, not a lock on who may use it. That was deliberate: admin links for older surveys were once exposed in public page source, and if ownership granted authority, whoever claimed a leaked link first could seize the survey and lock out the person who made it. Because ownership grants nothing, that attack costs the real creator nothing.
• Missing SPF, DKIM, DMARC, DNSSEC, or CAA records, and spoofing of addresses we do not send mail from.
• Missing or imperfect security headers with no demonstrated exploit.
• Clickjacking on pages that carry no state-changing action.
• Self-XSS, and anything requiring a compromised device, a hostile browser extension, or talking a user into pasting code into a console.
• Absence of rate limiting where you cannot show concrete harm.
• Denial of service, resource exhaustion, and anything whose severity depends on how much traffic you can generate.
• Scanner output with no working proof of concept, and reports generated by a language model that the sender has not verified. We read every report ourselves, and one that wastes that time makes us slower for everybody else.
• Issues in Cloudflare, Stripe, PostHog, or another provider we build on. Report those to them. If the problem is in how we configured them, that is ours and we want it.
• Bugs that only affect browsers no longer receiving security updates.
• Content or text injection with no impact beyond the reporter's own screen.

About Survey Responses

People answer surveys here after being told their answers are anonymous, and responses are stored with no respondent identifier at all. We do not read them ourselves except when there is no alternative. If testing ever puts you within reach of responses that are not yours, hold to the same line: confirm the access, report it, and delete what you pulled. A report that attaches other people's answers as evidence causes the exact harm it is describing.

What to Expect from Us

rifts.to is built and run by a very small team, so we will not always be quick, but we will always answer. We aim to acknowledge a report within five business days and to tell you what we make of it within ten. If we are going to fix it, we will tell you when the fix ships. If we decide not to act, we will tell you that and why, rather than going quiet.

There Is No Bug Bounty

We do not pay for reports. rifts.to is a small independent product without the budget for a bounty program, and we would rather say so plainly than leave you guessing. If you would like credit for a valid report we are glad to give it, and you are free to write about your finding once it is fixed.