gosearch: a Go username scanner for 305 sites, plus breach lookups

The problem gosearch solves, and who it is aimed at

Checking whether a username exists on dozens of platforms is tedious if you do it by hand. gosearch automates that enumeration. The README describes the original motivation plainly: the author wrote it to learn Go and to build a Sherlock clone that addresses what the README calls Sherlock's faults and limitations. The audience follows from the repository topics: OSINT, digital-footprint lookup, information gathering, pentesting and red team work. It is a reconnaissance utility for people who already have a target username and want a quick map of where it appears.

The scope is broader than profile checking. According to the README, gosearch also queries HudsonRock's Cybercrime Intelligence API, ProxyNova's Combination Of Many Breaches API, and BreachDirectory.org. The README gives three figures for those sources: 900k leaked credentials from HudsonRock, over 3.2 billion from ProxyNova, and 18 billion from BreachDirectory. Those numbers come from the project's own description of third-party services, not from an independent audit, and gosearch is only as current as those APIs.

One detail in the README is worth reading as a design statement: gosearch searches common TLDs for domains associated with a username whether or not BreachDirectory is queried. So a single run mixes profile enumeration, domain guessing and breach lookup. That is convenient for a one-shot recon pass and awkward if you only wanted one of the three.

How gosearch works: concurrency, colour coding and a site list you can edit

The mechanism is a concurrent HTTP checker driven by a data file. The repository root contains data.json, which holds the site definitions, and the README's badge states 305 websites. The README frames the core value as concurrency: rather than opening profiles one by one, the binary fans the requests out and reports back. The Go module declaration in go.mod targets go 1.25.0 and pulls in a small dependency set: github.com/ibnaleem/gobreach for breach lookups, github.com/joho/godotenv for environment loading, github.com/olekukonko/tablewriter for the result table, and github.com/inancgumus/screen for terminal handling.

The interesting part is how it handles uncertainty. The README says gosearch colour-codes uncertain results as yellow to indicate potential false positives, and it recommends the --no-false-positives flag as best practice. That flag narrows output to profiles the tool is confident exist. This is a direct answer to the two failure modes the README attributes to Sherlock: false negatives, where a username exists but is not detected, and false positives, where a username is flagged incorrectly. gosearch does not claim to eliminate either. It gives you a confidence signal and a filter.

Breach handling adds a second stage. If you pass a BreachDirectory API key with -b and password hashes come back, the README states that gosearch attempts to crack them using Weakpass, and it claims a near-100 percent success rate because Weakpass's wordlist aligns with the breaches BreachDirectory reports. Treat that claim as the project's own, not a measured result. Cracking is also the point where a read-only recon tool starts producing credentials, which changes what you are handling.

Install and first run: go install, then filter the noise

Installation is a single Go command. The README puts it at the top of the page, which tells you the expected audience already has a Go toolchain. There is no package manager formula, no container image and no release binary documented in the README, only a warning to download gosearch from nowhere other than the repository itself.

go install github.com/ibnaleem/gosearch@latest

After that, the binary is named gosearch. On Unix the README shows the -u flag with a username placeholder, and on Windows the same command through gosearch.exe.

gosearch -u [username]

The README's recommended first real run adds the confidence filter, so you see only the profiles the tool believes are genuine rather than the whole yellow-tinted list.

gosearch -u [USERNAME] --no-false-positives

If you also want the BreachDirectory lookup, you supply the key on the command line with -b. The README points to the BreachDirectory RapidAPI page for obtaining one.

gosearch -u [USERNAME] -b [API-KEY] --no-false-positives

Two installation constraints are documented. On 32-bit architecture the README says gosearch will fail to build and points to a separate 32-bit branch. On Windows, the README notes that Windows Defender may flag the binary as malware and states that this is a false detection, with issue #90 as the reference. Whether you accept that explanation is your call, but the README does not offer a signed binary today; it says SHA256 hashes and GPG-signed releases are planned for the future.

Where gosearch gets it wrong

False positives are an acknowledged, unfixed problem. The existence of a --no-false-positives flag and a yellow colour code is evidence that the raw output needs interpretation. If you script gosearch and parse the default output, you are parsing results the project itself labels uncertain. The README's own framing is that the flag is best practice, which means the unflagged run is the noisier one.

Coverage is bounded by data.json. The badge says 305 websites, and the README asks for contributors, describing the project as heavily reliant on them. A site list maintained by hand drifts: platforms change their not-found responses, add bot protection, or disappear. Nothing in the README describes an automatic verification step for the list, so a stale entry is a plausible source of both error types.

Password cracking is the sharpest limitation. It only happens with a BreachDirectory API key, it depends on Weakpass, and the README's near-100 percent figure is a project claim rather than a measurement. More importantly, the output is plaintext credentials for real accounts. A tool that is harmless when it lists profile URLs becomes something else entirely when it prints passwords, and the README does not document handling guidance for that output.

Finally, gosearch is a CLI. There is no documented library API, no server mode and no web interface in the README. If you wanted to embed username checking in a pipeline as a Go package rather than shelling out to a binary, the repository layout (main.go at the root, internal/ for the rest) suggests you would be reading source rather than following a published interface.

gosearch versus Sherlock, and when a different tool fits better

The README names Sherlock as the direct comparison and lists seven differences. Three are about data sources: Sherlock does not search HudsonRock, ProxyNova or BreachDirectory, while gosearch does. Two are about accuracy: the README states that Sherlock sometimes reports false positives and frequently misses real usernames. Two are about implementation: Sherlock is Python-based and therefore slower in the README's assessment, and the README calls Sherlock outdated and lacking updates. That last point is the project's characterisation of another tool, not a fact this article can verify.

The practical difference is the confidence model. Sherlock's output is a list; gosearch's output is a list plus a colour signal plus a filter flag. If your workflow is "give me every candidate URL and let me triage," the default run is fine. If your workflow is "give me only what is real," you want --no-false-positives and you accept that it may hide genuine hits the tool could not confirm.

A different class of alternative is not a scanner at all. If you do not know the username, gosearch cannot help, and the README says so directly. It points to urbanadventurer/username-anarchy for generating candidate usernames from a first and last name, noting that username-anarchy runs only in Unix terminals. The two compose: generate candidates, then feed them to gosearch. If your actual need is breach data alone, the three APIs gosearch wraps are themselves accessible, and gosearch's value there is the wrapper, not the data.

Maintenance, licensing and what a GPL-3.0 dependency means for you

The repository is not archived, and the last push was on 2026-09-21. The most recent release listed is v2.0.1, "Gravatar Fixes", from 2026-06-06, following v2.0.0, "GitHub OSINT & codebase refactor", from 2026-05-24. The README's own note that the project heavily relies on contributors is the honest summary of its maintenance model: the site list and the checks around it improve when people send changes.

Upgrade cost is low for users. Installation is go install against @latest, so pulling a new version is the same command as the first install, and there is no migration or config file to rewrite. The risk sits on the other side: @latest means you take whatever is current, and the README's warning about downloading only from the repository is a reminder that the supply chain here is the Go module path and the GitHub repository.

The licence is GPL-3.0, stated in the repository metadata and present as a LICENSE file at the root. That matters if you plan to reuse the code rather than run the binary. GPL-3.0 is a copyleft licence, so incorporating gosearch's code into a distributed product carries obligations that permissive licences do not. Running the binary for your own investigations is a different question from shipping derived code, and the boundary between the two is a legal question this article cannot answer. If you intend to embed any of it, read the LICENSE file and get proper advice. Note also that the breach features depend on third-party APIs with their own terms, and BreachDirectory requires a RapidAPI key.

Editorial conclusion

Adopt gosearch if you already work in a terminal and want username enumeration plus breach lookups in one binary, especially if you keep a BreachDirectory API key on hand for the -b flag. Skip it if you need a graphical interface, if you expect a documented library API for your own code, or if you cannot tolerate the false positives that the --no-false-positives flag and yellow colour-coding exist to manage. Before relying on it, run gosearch -u on a username you control and compare the confident results against the sites you know you registered on, then check whether the data.json site list still matches the platforms you care about.

Frequently asked questions

Official sources

1. ibnaleem/gosearch on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases