Security

How to report

Email contact@kindnesscommunityfoundation.com with the subject line ’Security report — Toolvore’. A real person reads that address.

Include enough for us to reproduce it without guessing: the URL or the tool affected, the exact steps you took, what you observed and what you expected instead. Say which browser and operating system you were on if it might matter. A proof of concept helps, but a clear written description is enough to start — do not sit on a report because you have not finished weaponising it.

Put the detail in the body of the email where you can. A link to a video on a host that expires, or a file we have to download to understand the report, slows the first reply down rather than speeding it up. We do not publish a PGP key, so treat the report as ordinary email; if the detail is sensitive enough that you would rather not, say so in a first message and we will agree another channel before you send anything.

How this site is built, and what that removes

There are 163 tools here. 131 of them run entirely inside your browser, and 130 of those make no network request at all — the single exception is the image OCR tool, which downloads its recognition engine from a public code CDN and never sends your image anywhere. 15 tools pass your input through our server to a third party, and 17 send text to Anthropic’s API. Those numbers are computed from the tool registry at build time rather than typed by hand, so they cannot quietly go stale.

The consequence for a researcher is worth stating directly. There is no account system: no login, no session cookie, no password reset, no role or permission check, no token to forge. The whole category of authentication and authorisation bugs has nothing here to attach to. There is no store of user files, because files are never uploaded — a document you convert is read by the page, worked on in your tab’s memory and handed back, so there is no object storage to enumerate and no file of somebody else’s to reach.

We hold exactly one thing that could be called user data. If you use the box that offers to tell you when new tools are added, we store your email address and the name of the tool you were using when you typed it, and nothing else. That is the entire persistent dataset.

So most of a standard checklist comes back empty here, and not because we defended those things well. They are absent. Naming that is more useful than a scope list that implies otherwise.

Where the attack surface actually is

Five places, in roughly the order we would look ourselves.

The server-backed tools. Several of them take a hostname or a URL that you supply and fetch it from our infrastructure — the DNS lookup, WHOIS, the HTTP headers checker, the meta tag checker, the REST API tester and the URL shortener. That is a request-forgery surface by construction. There is a guard that resolves the hostname first and refuses loopback, private, link-local, unique-local, carrier-grade NAT and multicast ranges, including IPv4-mapped IPv6 forms, and it checks every address a name resolves to rather than only the first. Redirects, rebinding between the check and the connection, and unusual address encodings are the interesting corners.

The AI route. It forwards your text to Anthropic on our API key, which means anything that gets more work out of it than intended costs us money directly. Requests are limited to 6 a minute per address and 120 a minute overall, and the counters live in memory inside a serverless instance — so it is a speed bump against loops and casual abuse, not an exact limit and definitely not a spend cap. A single message is capped at 40,000 characters and a forwarded conversation at 60,000. The tool name in the request is checked against a fixed list with Object.hasOwn, after a prototype-chain hole let names like constructor through the old truthiness check and briefly turned the route into an unconstrained model proxy with no system prompt. Anything that defeats the tool whitelist, the character caps or the rate limiting is a genuine finding.

Client-side rendering of untrusted input. The markdown previewer, the markdown-to-HTML converter and the output of every AI tool render text into the page, and all of it goes through DOMPurify first. A payload that survives that and executes is exactly the sort of thing we want to hear about.

Dependencies. Most of the real work happens in libraries running in your tab — pdf-lib, pdf.js, tesseract.js, marked, sharp and others. A vulnerability in one of those is our problem too, and we would rather learn it from you than read about it later.

Hosting and build configuration. Redirects, caching behaviour, anything reachable that should not be, and anything the deploy pipeline exposes.

In scope and out of scope

In scope: toolvore.com and everything served under it, including the API routes behind the server-backed and AI tools.

Out of scope, because they are not ours to authorise you to test: the third-party services those tools query, all of which are named on the privacy page, and Anthropic’s API. Report issues in those to the people who run them.

Also out of scope: automated scanner output with no demonstrated impact, opinions about our SPF or DMARC records, volumetric or denial-of-service testing, social engineering of anyone connected to the project, physical attacks, and anything that requires an already-compromised device or a malicious browser extension. Best practice without a working attack path is not a vulnerability.

One specific case, since it is the most common report on sites like this: we do not set a Content-Security-Policy. Telling us that is not a finding, because we already know. A working injection that a policy would have stopped is a finding, and it is a better argument for adding one than any header-grading tool.

What we ask of you

Give us a reasonable chance to fix the issue before you disclose it publicly. Ninety days is our default assumption and we would much rather agree a date with you than have one arrive by surprise. If we are dragging, say so.

Do not access, modify or delete data that is not yours, and do not degrade the service for other people. Stop as soon as you have enough to prove the issue rather than continuing to see how far it goes. Do not use social engineering, physical attacks or denial-of-service testing. Test against your own input and your own traffic — there are no other accounts here to stumble into, which makes this easier than it usually is.

If you are unsure whether something falls inside these rules, ask before you do it. We would far rather answer that email than the one after it.

What you can expect from us

We aim to acknowledge a report within a few business days. We will tell you whether we could reproduce it, keep you updated while we investigate and fix, and tell you when it is resolved.

If we decide not to fix something, you will get a reason rather than silence. If we disagree with your severity assessment we will say why, and you are welcome to argue back.

We will credit you by name or handle if you would like that, and leave you out of it if you would not. We will not require you to sign a non-disclosure agreement as a condition of getting an answer.

We do not publish a target fix time. With a team this small, any number we picked would be decoration.

Safe harbour, in plain terms

If you research in good faith and stay inside the rules above, we will not pursue legal action against you over that research, will not report you to law enforcement for it, and will not ask your hosting provider or employer to act against you. If someone else raises a complaint about testing we authorised here, we will say plainly that it was authorised.

What we cannot do is speak for anyone else. This covers this site and the routes it operates. It does not cover the third-party services listed on the privacy page, it does not cover Anthropic, and it cannot override whatever computer-misuse law applies where you happen to be sitting. Good faith on both sides is what this rests on, not a contract.

There is no paid bounty

We do not pay for vulnerability reports. There is no reward tier, no swag, no hall of fame with a prize attached. Rather than leave that vague and let you find out after a weekend of work, it is here in its own section.

The site is free, sells nothing, runs no advertising and is operated by KCF LLC as a project of the Kindness Community Foundation. There is no revenue stream a bounty budget could come out of, and inventing one we cannot fund would be worse than saying no.

What you get instead is a fast and honest reply from someone who reads the report properly, credit if you want it, and a fix. If that is not worth your time, we understand entirely.

What happens once an issue is confirmed

We triage by what could actually happen to a person using the site, not by a score. Anything that would expose the stored email list, or let someone spend against our API key, goes to the front of the queue.

Deploys are continuous, so a fix ships when it is written rather than waiting for a release window. Then two more things happen. We look for the same mistake elsewhere in the codebase, because the fix and the sweep are separate jobs — the prototype-chain hole in the AI route taught us that the hard way. And where the mistake is the sort a machine can catch, we add a check that fails the build: the repository already refuses to build if a browser-classified tool reaches a network host that is not on an approved list, which exists because a claim on the privacy page had quietly stopped being true.

If an issue ever affected anyone’s data, we will say so on this site rather than hoping nobody asks, and we will contact the people affected directly where we hold an address for them. Given that the email list is the only thing we store, that notice would be narrow — which is the point of holding so little.