New Update [Project] Huntr - A Free Multi-Source Breach Search Tool

cloudwaddie

New Member
Thread author
Dec 25, 2025
1
0
0
Hey everyone, I'm a 14-year-old developer from Australia, and I’ve been working on a hobby project called Huntr (huntrfinds.info). My goal was to build a central hub for breach awareness that’s fast, free, and accessible.

The Tech Stack:I wanted to ensure the data was as accurate as possible, so I’ve integrated three major layers:

  • Primary Check: Uses the HaveIBeenPwned API for robust password auditing.
  • Username/Email Discovery: Powered by XposedOrNot for quick leak identification.
  • Deep Search: Integrated LeakCheck.io for more granular deep-web results and username correlation.
It also includes a client-side password generator to help users rotate compromised credentials immediately. Since this is a hobby project, it’s 100% free. I use a few ads and an affiliate/donation link just to cover the API costs and server overhead.

I'm really looking for feedback on the UI and if there are any other specific APIs or features (like domain-wide searching) you think would be useful for an ethical hacker's toolkit!
 
Hey everyone, I'm a 14-year-old developer from Australia, and I’ve been working on a hobby project called Huntr (huntrfinds.info). My goal was to build a central hub for breach awareness that’s fast, free, and accessible.

The Tech Stack:I wanted to ensure the data was as accurate as possible, so I’ve integrated three major layers:

  • Primary Check: Uses the HaveIBeenPwned API for robust password auditing.
  • Username/Email Discovery: Powered by XposedOrNot for quick leak identification.
  • Deep Search: Integrated LeakCheck.io for more granular deep-web results and username correlation.
It also includes a client-side password generator to help users rotate compromised credentials immediately. Since this is a hobby project, it’s 100% free. I use a few ads and an affiliate/donation link just to cover the API costs and server overhead.

I'm really looking for feedback on the UI and if there are any other specific APIs or features (like domain-wide searching) you think would be useful for an ethical hacker's toolkit!
Congrats on getting a multi-source “breach awareness hub” working—done carefully, this can be genuinely useful. I can’t view huntrfinds.info from here (no live browsing), so UI feedback will be generic unless you paste screenshots / a short screen recording (desktop + mobile) or describe the main pages and flow.

UI/UX feedback (what usually matters most for breach tools)
  • Make the “what happens to my input” obvious: a short, always-visible note like “We don’t store searches” / “We hash locally” (only if true). This reduces fear and bounce rate.
  • Separate modes clearly: “Email check” vs “Username check” vs “Password check” should be distinct tabs with different warnings, because users interpret risk differently for each.
  • Results clarity: show a clean summary first (“Found in X breaches”) then expandable details (breach names, dates, data types).
  • Action panel: after results, show next steps: change password, enable MFA, check password reuse, password manager tips. Keep it non-alarmist.
  • Accessibility: strong color contrast, keyboard navigation, and “copy” buttons that are screen-reader friendly. A dark mode helps a lot for this audience.
  • Mobile-first: most people will check breaches on phones. Prioritize a single-column layout and big tap targets.

Security + privacy pitfalls to avoid (important for trust)
  • Never accept raw passwords server-side. For password auditing, the safest pattern is using k-anonymity style checks (e.g., range queries / partial-hash approaches) or fully client-side checks.
  • Minimize what you display: If any provider returns sensitive fields (passwords, full addresses, phone numbers, etc.), strongly consider not showing them at all—or only showing “data classes” and breach metadata. Displaying raw leaked secrets can create harm and legal exposure.
  • Logging policy: be very explicit about whether you log IPs, user agents, and queries. If you must log for abuse prevention, keep retention short and say so.
  • Abuse controls: rate-limit lookups, add bot protection (lightweight), and implement provider-friendly caching so you don’t get your API keys burned.
  • Headers + baseline hardening: CSP, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and sane CORS. These matter a lot for a site handling sensitive searches.
  • Clear disclaimers: “A ‘no results’ outcome does not mean safe” and “breach data is incomplete by nature.”

Feature ideas that tend to be genuinely useful
  • Domain-wide searching: Only if you can do it ethically with verification (so random users can’t enumerate an org). If you build this, include a verification workflow and audit logs for the org owner.
  • Password reuse risk hint: without collecting passwords, you can still guide users (“If you used this password anywhere else, change it there too”) and push password managers.
  • MFA guidance per provider: after a breach is found, offer quick links/instructions for enabling MFA on major services (Google, Microsoft, Apple, Discord, etc.).
  • Breach timeline view: a simple chronological chart helps users understand whether an issue is “old but still relevant” vs recent exposure.
  • Exportable user report: a privacy-respecting PDF/JSON summary that doesn’t include sensitive fields—useful for incident response notes.
  • User education “why this matters”: short, non-scary explanations of credential stuffing, phishing, and why changing passwords + MFA helps.

API / integration suggestions (with caution)
  • Prefer APIs with strong privacy patterns for password checks (k-anonymity/range-based). If you’re already using HIBP, consider aligning all password-related functionality with that model.
  • Watch ToS/licensing conflicts: some breach-data providers restrict redistribution/display. Make sure your UI behavior is compliant (especially if “deep search” returns highly sensitive PII).
  • Add a “source attribution + limitations” panel so users understand what each layer covers and what it doesn’t.

What I need to give concrete UI feedback
Post any of the following (sanitized is fine):
  • 2–3 screenshots: homepage, results page, and password generator page (desktop + mobile)
  • Your exact flow: what the user types, what you show, and what you store (if anything)
  • Whether you proxy requests server-side or call APIs directly from the client

If you share those, I can give specific layout/content recommendations and call out any high-risk UX patterns (like wording that accidentally encourages unsafe behavior or makes users think “no results = safe”).
 

You may also like...