Reporting a vulnerability
Email [email protected]. It reaches me directly. I read everything, I will acknowledge a genuine report, and I will tell you when it is fixed. There is no bug bounty; this is a free site run by one person. Credit in a fix note is yours if you want it.
The same details are published in the machine-readable security.txt (RFC 9116).
What to include
- The URL or tool affected, and the request that triggers it (a
curlcommand is ideal). - Steps to reproduce, and what you observed against what you expected.
- Your view of the impact: what an attacker could do with it.
- Any evidence that helps, such as a response body or a screenshot. Please do not include anyone else's personal data.
Please test against your own systems or ones you are entitled to test. Do not run denial-of-service tests against this site or use its tools to attack a third party; that is covered by the terms of use and it also does not tell either of us anything useful.
How the site handles data
The full description is on the privacy page. The security-relevant summary:
- Browser-only tools (JSON, JWT, encoding, timestamps, diff, hash) process input on your device and send nothing to the server.
- Server-side lookups use the target you give them for that request only. Targets and results are not stored, and there is no lookup history.
- There are no access logs. Error logs name the route pattern, never a request's path values, query, address or headers.
- Rate limiting is in memory, keyed by visitor address, and expires within minutes.
- The only persistent data is a set of anonymous daily counters (page and tool usage by interface and outcome) with no per-visitor fields.
- The request bin holds captured requests in memory for a short time and is viewable by anyone with the bin URL; it is a debugging tool, not a secure store.
Protections that are actually in place
This list describes what the code does today. It is not a promise that nothing can go wrong, and it does not list things I have not built.
- Server-side request forgery guard. Every outbound connection resolves its target first and refuses anything that is not a public unicast address: loopback, RFC 1918 private ranges, link-local, carrier-grade NAT, multicast, unspecified and reserved ranges are all rejected. Hostnames that only resolve to such addresses are rejected too. The DNS tool will only query a resolver at a public address.
- Timeouts and output limits. Lookups have a hard ceiling (6 seconds per lookup, 15 seconds for an HTTP redirect chain, 14 seconds for a full Domain Health run), HTTP response bodies are read up to 2 MB and then cut, redirect chains stop after 10 hops, and the request bin stores at most 64 KB of body per request.
- Rate limiting. Server-side tools are limited per visitor address with a token bucket (30 a minute, burst of 10), the traceroute and bin creation more tightly, and the private statistics dashboard slows down failed logins.
- Strict content security policy. Scripts and styles load only from this origin (plus Google Fonts for stylesheets and font files); there are no inline scripts or styles, no framing is allowed, and forms may only submit to this site. The site also sends
X-Content-Type-Options,X-Frame-Options,Referrer-PolicyandPermissions-Policyheaders. - Minimal runtime. The whole site is one statically linked Go binary running as a non-root user in a distroless container with a read-only filesystem and all Linux capabilities dropped. There is no database, no shell and no package manager in the image.
- No secrets in the browser. There are no API keys, tokens or session cookies to steal, because the public site has none.
- Private administrative route. The usage dashboard requires authentication, is served with
Cache-Control: no-storeandX-Robots-Tag: noindex, nofollow, noarchive, and does not exist at all unless credentials are configured on the server.
Things worth knowing before you report them
- The tools connect to the host you name from this server. That is the feature, not an SSRF, provided the host is a public address. A way to reach a private or loopback address through them would be a real finding.
- The request bin echoes back whatever is sent to it, including headers, to the bin's viewer. That is its purpose. A way to read a bin without knowing its ID, or to make a capture persist, would be a real finding.
- The header checker and IP tool reflect your own request back to you and are not vulnerabilities.
- The status code tester returns the status you ask for, by design, with no caching.
Scope
Everything served from kirkdiamond.com is in scope. Third-party services the tools talk to (public DNS resolvers, Team Cymru, RDAP servers, Google Fonts, the systems you point the tools at) are not mine and are out of scope; please report issues with those to their owners.