Thank you for taking the time to report a problem responsibly. This page tells you where to
send it, what happens next, and — importantly — what not to include.
Report to
security@reracked.app. Please use this
address rather than a public issue, an app-store review, or social media. A public report
exposes other people’s data before anything can be fixed.
Reracked is a closed beta built and operated by one person, Brendan Hamilton.
The response times below are honest for a single maintainer rather than copied from a template.
What to include
- What the issue is, and what an attacker gains from it.
- Steps to reproduce against your own account — the request, the
response, and the order you did things in.
- Which host you tested against, and roughly when.
- Anything you think we would get wrong if we tried to reproduce it ourselves.
What NOT to send — please read this part
Email is not an encrypted channel, and your report will sit in a mailbox. Sending any of the
following turns a helpful vulnerability report into a data incident of its own:
- Credentials or tokens. No access tokens, refresh tokens, password-reset
codes, session cookies, API keys or passwords — not yours, and definitely not anyone
else’s. Describe how you obtained one; do not paste it. If you already have,
say so and we will treat it as compromised and rotate it.
- Another person’s data. If a bug exposed someone else’s
information, tell us that it did, roughly how many records you could reach, and one
redacted example showing the shape. Do not send the records, and please
delete any copy you made.
- Bulk extracts. A screenshot of a single row proves the read. Ten thousand
rows does not prove it any harder.
If your proof genuinely requires sensitive material, say so in your first email and we will
arrange a channel for it before you send anything.
What we ask of you
- Test only against accounts you created. Do not access, modify or delete
other people’s data.
- No automated scanners, load tests or denial-of-service attempts against production. There
are rate limits and concurrency caps in front of everything, and tripping them at volume is
indistinguishable from an attack — it will be treated as one.
- Give us a reasonable chance to fix the issue before disclosing it publicly.
What you can expect from us
| Stage | Target |
|---|
| Acknowledgement that a human has read it | 3 business days |
| Initial assessment — reproducible, and how severe | 7 business days |
| Fix, or a written plan with dates, for High/Critical issues | 30 days from confirmation |
| Coordinated public disclosure, if you want one | By agreement, normally after a fix ships |
If you have not heard anything within the acknowledgement window, assume the mail went astray
and send it again — that is a failure on our side, not an invitation to disclose.
We will tell you what we found, whether we are fixing it, and when it ships. If we decide
not to fix something, we will say so and explain why rather than going quiet.
There is no bug-bounty programme and no monetary reward. We will credit you
by name or handle if you would like that, and we are glad to say so publicly.
Supported versions
| What | Supported |
|---|
| Backend | Only the version currently deployed to production. No maintained release branches, no backports. |
| Android app | Only the most recent build on the active Play track. |
Reracked is a hosted service in closed beta, not distributed software — everyone is on
the deployed version, so “supported” means what is running now. Older builds of the
app can also be refused by the server and asked to update; that is an upgrade mechanism, not a
security boundary.
Scope
In scope
- The Reracked backend API and its infrastructure.
- The Reracked Android app on the active Play track.
- Anything that exposes one user’s data to another, bypasses authentication or
authorization, or breaks account deletion or data export.
Out of scope
- Automated-scanner output with no demonstrated impact — a header grade, a TLS
configuration preference, a “missing” header on an API that serves no HTML.
- Rate-limit thresholds you consider too generous, without a demonstrated attack.
- Denial of service by volume; anything requiring a rooted or compromised device, a malicious
app already installed alongside ours, or physical access to an unlocked phone.
- Social engineering of the maintainer or of any user.
- Third-party services we use, where our configuration is not at fault — report those
to the provider.
Things that are deliberate
So you do not spend time confirming behaviour we chose on purpose:
- A record belonging to someone else returns “not found”, never
“forbidden” — so the API cannot be used to discover whether a given record
exists. This is intended.
- Registration returns one message whether a username or an email is already
taken, and sign-in takes the same time for a known and an unknown account. Resistance to
account enumeration is a design goal — a measurable difference is a valid
report.
- Unexpected access to operational endpoints is a valid report.
Health checks are public; metrics require a separate scrape credential by design.
Report any route that bypasses that requirement.
- Deleting your account is a hard delete of the live database, and is
replayed against restored backups so a restore cannot bring the account back.
- Signing out ends your session but does not instantly kill an access token
already issued. Sign-out revokes the refresh token chain immediately, so no new
access token can be minted; one already in hand keeps working until it expires, which is
capped at 15 minutes. Deleting your account, and resetting your password,
both take effect at once. This is a deliberate trade-off, not an oversight — but if
you can make that window longer than 15 minutes, or use it after a password reset or an
account deletion, that is a valid report.
Finding a way around any of these is exactly the kind of report we want.
Machine-readable contact
This policy is also advertised at
/.well-known/security.txt
(RFC 9116).