Security

How to tell us about a security problem in Verified Handles, what you may test, and what to expect back.

Effective 12 October 2026.

Verified Handles exists so that people can tell real accounts from impersonators. A weakness that let someone change an entry, take over an account or see what they should not would undermine that, so if you think you have found one, we want to hear about it.

Not a security problem? To fix a wrong handle, see Corrections. If someone is impersonating you or Verified Handles, or someone’s safety is at risk, see contacting Verified Handles urgently. For anything else, contact us.

What this policy covers

You may test:

  • verifiedhandles.org: the public pages, the console and editor when you are signed in, the read API (/api/v1) and the other routes the developer docs describe, and the MCP server (/mcp) with its sign-in.

Not covered by this policy, so please don’t test them:

  • JEMEDIA Accounts (auth.jemedia.xyz), where you sign in. JEM Media runs it too, but it is a separate service: if you find something there, email us and we will pass it on.
  • JEM Media’s other websites and services, and any other site on the same servers.
  • Google Project Shield, which sits in front of the site, and the other companies we use (listed in the Privacy Policy). Report a problem in their services to them.
  • The accounts and websites an entry links to. They are run by other people.
  • Physical attacks, and social engineering, phishing or pressure on our team, our users or the people listed here.
  • Denial of service: anything meant to slow the site down or take it offline.

What we don’t treat as a security problem

  • Reading or downloading the directory. It is open data, released into the public domain under CC0, and the API is there for it.
  • A wrong or out-of-date handle. That is a correction: see Corrections.
  • An impersonating account on another platform. Report it to that platform.
  • Output from an automated scanner with no example of what an attacker could actually do.
  • Missing headers, version numbers or similar, unless you can show they lead to real harm.

Testing within the rules

  • Test with your own account. You can create one with JEMEDIA Accounts, and API keys from your own console.
  • Keep test suggestions, reports, claims and applications to the few you need, and say in each that it is a security test. Every one goes to a person who reviews it.
  • Don’t access, change or delete anything that isn’t yours beyond the minimum needed to show the problem. If you reach someone else’s personal data, stop there. Tell us what you saw, don’t keep or share it, and delete any copy you have.
  • Don’t change a published entry’s handles or links, even for a moment. People rely on them to find the real account. If you find you could, tell us how and we will check it ourselves.
  • Nothing destructive: don’t delete entries, accounts or images, and don’t make changes in bulk.
  • Don’t upload anything harmful, such as malware or another person’s private images.
  • Stay within the site’s rate limits, and don’t run automated tools at volume. A slow, targeted check is fine. A flood of requests is a denial of service, whatever it is for.
  • Keep what you find between you and us until it is fixed, or until a date we have agreed.

How to report

Email security@verifiedhandles.org. Please include:

  • what the problem is, and where: the page, the API route or the MCP tool;
  • the steps to reproduce it, and what an attacker could do with it;
  • what shows it: a request and its response, a screenshot or a short proof of concept;
  • whether you would like to be credited, and the name or handle to use.

One problem per email helps us track each one. Write in English if you can. Leave out anyone else’s personal data: tell us it is there, and we will look ourselves. You don’t need to encrypt your email.

What happens next

  • We reply within three working days to say we have your report.
  • We tell you whether we could reproduce it and what we plan to do, then update you at least every two weeks until it is fixed, and tell you when it is.
  • We agree with you when the problem can be made public. Normally that is once it is fixed, or 90 days after your report, whichever comes first, unless we agree another date.
  • If you would like credit, we add your name or handle to the thanks list on this page.
  • We don’t pay rewards for reports. Verified Handles is non-profit, and has no budget for one.

Reports are handled by a small team, so a fix can take time. If we can’t reproduce something, we say so and explain why.

Good-faith research

If you make a good-faith effort to follow this policy, we consider your research authorised. We will not take legal action against you over it, or ask anyone else to.

Good faith means staying within the rules above, reporting what you find to us promptly, and not using it for anything else. If you are unsure whether something is allowed, ask us first at security@verifiedhandles.org.

We can only give permission for what we run. This policy doesn’t authorise testing of the services listed as not covered above, and it can’t change what the law says or bind anyone else, such as the police.

Thanks

The people who reported a security problem to us under this policy and asked to be credited.

No one is listed yet.

Changes to this policy

The date this version took effect is at the top. When we change this policy in a way that matters, we say so on the site before the change takes effect.

Contact

Security problems: security@verifiedhandles.org. Data protection: privacy@jemedia.xyz. Help with Verified Handles: contact us. By post: JEM MEDIA LTD, 195-197, Suite Ra01 Wood Street, London, United Kingdom, E17 3NU.