avahit

Security & vulnerability disclosure

If you have found a way to break Avahit, tell us and we will fix it. This page sets out how to report it, what we promise in return, and where the line is between research and damage.

Reporting

Write to [email protected] with enough detail to reproduce the problem: a URL, the steps, and what you saw. Proof-of-concept code helps. Please do not post it publicly first.

What you can expect from us:

  • an acknowledgement within three working days;
  • an assessment, and our intended fix, within ten working days;
  • notification when the fix ships, and credit on this page if you want it;
  • no legal action against you for research that follows the rules below.

We do not run a paid bug bounty. This is a small operation and any reward would be symbolic; we would rather promise a fast fix and honest credit than a payout we cannot sustain.

In scope

  • avahit.com and everything served under it, including the API routes.
  • The outbound click redirect at /go/.
  • The embeddable storefront widget.
  • The browser extension published under our name.

Out of scope

  • Denial of service, traffic floods, and anything that degrades the service for other people. Load-testing our servers is not research.
  • Automated scanner output with no demonstrated impact, and reports whose entire content is a missing header.
  • Social engineering of our people, of creators, or of merchant support desks.
  • Attacks against merchant sites, affiliate networks or any third party reached through our links. Their security is theirs, and we cannot authorise you to test it.
  • Physical attacks on hosting infrastructure, and anything involving the machines of our neighbours on the same server.

Rules for testing

  • Use your own accounts. Create as many as you need, but do not touch another person’s account or data.
  • Stop as soon as you have shown the problem exists. Do not read, copy, modify or delete data that is not yours, and tell us immediately if you see personal data by accident.
  • Do not leave persistent artefacts — no stored payloads on public pages, no spam posts, no defacement. Clean up test content when you are done.
  • Give us reasonable time to fix before publishing. Ninety days is fine.

What we do on our side

  • All traffic over HTTPS with HSTS; a content security policy; frame, sniffing and referrer protections on every response.
  • Passwords hashed with bcrypt. Sessions are httpOnly, secure cookies with a revocation epoch so a password change ends every other session.
  • Server-side URL fetching is guarded against SSRF, including redirect chains and IPv4-mapped addresses; uploads are checked by file signature rather than by the declared content type; media paths are guarded against traversal.
  • Rate limiting on sign-in, sign-up, posting, comments, follows and the copyright form.
  • Daily database and media backups with a restore that is actually tested weekly, not merely scheduled.

If something goes wrong anyway

If a breach affects personal data, we notify the competent supervisory authority within 72 hours of becoming aware, and we tell affected users directly when the risk to them is high. What we would tell you, and what you can ask us afterwards, is set out in the Privacy Policy.

Last updated 2026-08-05.

Last updated 2026-08-05