Found a crack? Tell us first.

How to report a security issue in twiga, what's in scope, and the promise we make to anyone who reports one in good faith: we work the problem with you, and we don't come after you for finding it.

Last updated: 2026-07-25

Reporting a vulnerability

  • Email [email protected]. Tell us what you found, how to reproduce it, and which URL, endpoint, or component it affects. Logs, requests, or a short proof-of-concept help us move faster.
  • Report privately. Please don't open a public issue or post the details anywhere until we've had a fair chance to fix it. Give us that window and we'll give you a straight answer.
  • Want to encrypt it? Say so in your first message and we'll send you a key.

What happens next

  • A reply, fast. Expect an acknowledgement within three business days, and an initial read — severity, and what we're going to do about it — within ten.
  • Updates as we go. You'll hear from us while we work the fix, and again when it ships.
  • Credit, if you want it. Once the issue is resolved, the credit is yours — or stay anonymous, your call.

In scope

  • twiga.tv and its subdomains.
  • The twiga API.
  • The web player and the account dashboard.

Out of scope

  • Upstream providers. twiga relays streams you bring from third parties. Their systems, their logins, and their content are not ours to test — please don't attack them, and don't use twiga to do it.
  • Denial of service at volume. Report the weakness that would let someone flood or exhaust the service; don't demonstrate it against the live system.
  • Social engineering of our team, our users, or anyone else, and any physical attack.
  • Scanner output with no real impact. A tool that flags a header is a starting point, not a finding — show us the exploit.

Your provider login

Your provider login is sealed in your browser with your key. The server stores ciphertext and opens it in memory while you’re signed in, then wipes it 30 minutes after your session goes quiet.

Check the seal yourself

Safe harbour

We will not pursue or support legal action against anyone who reports a vulnerability in good faith and plays it straight. In good faith means:

  • You make a real effort to follow this policy.
  • You don't destroy data, violate anyone's privacy, or degrade the service for other people.
  • You access only the minimum needed to prove the issue, and you don't view, keep, or share anyone else's data.
  • You give us a reasonable time to fix it before you tell the world.

Not sure whether something is allowed? Ask us first at [email protected]. Work done in good faith under this policy is authorised, and we won't treat it as a breach of our terms.

Rewards

We don't run a paid bug-bounty programme. What we offer is honest: a fast, respectful response, public credit if you want it, and our genuine thanks.

For the machines

  • The same contact is published in machine-readable form at /.well-known/security.txt (RFC 9116), for scanners and tooling that look there first.