csprecon reads a site's Content Security Policy to find sibling domains

A policy header is a curated list of related infrastructure

csprecon discovers new target domains using Content Security Policy, and the idea is that a policy header is a list the site owner wrote about the third parties and subdomains they trust. A Content Security Policy names the origins a page is allowed to load from, so a single fetch of a page gives you a set of domains that the site genuinely depends on.

That is a different source of truth from the one a subdomain wordlist provides. A wordlist is a guess about naming conventions, while a policy entry is a fact about the deployment. The tool is described as a reconnaissance tool, and the repository topics place it in bug bounty and red team tooling, alongside information retrieval and web security.

The implementation is in Go, and the dependency list shows how the output is produced. An HTML parser, goquery, reads the fetched page, the mapcidr library from projectdiscovery handles CIDR input, and the author's own golazy package is also a dependency. The CLI is built with goflags and logs through gologger, both from projectdiscovery, which is the same stack many reconnaissance tools use.

Three install paths, and the one that needs no root

The tool installs in three ways, and one of them is unusual for a security tool because it does not need root privileges.

Homebrew is the first:

brew install csprecon

Snap is the second, and it does need sudo:

sudo snap install csprecon

The third is a Go install, which is the option for a machine that already has a Go toolchain:

go install github.com/edoardottt/csprecon/cmd/csprecon@latest

The Go install also tells you the repository layout. The module is github.com/edoardottt/csprecon, the binary is under cmd/csprecon, and the rest of the code lives under pkg, so the command and the reusable parts are separated in the usual Go fashion. The module requires Go 1.26.0.

The build and release machinery is conventional for a Go CLI. There is a Makefile with a remod target that rebuilds the module files from scratch, a .golangci.yml for the linter, a .goreleaser.yaml for the release builds, and a snapcraft.yaml for the snap package, so all three installation routes are produced from the same source.

The flags, and the ones that matter for a careful run

The help output is the whole configuration surface, and it is worth reading before pointing the tool at a target.

Input is three ways: the -u or -url flag for a single domain, the -l or -list flag for a file of domains, and the -cidr flag, which interprets the input as a CIDR range. The list examples note that protocols are needed for list input, which suggests the tool distinguishes an input it should fetch from one it should not.

Configuration is where the caution lives. The -c or -concurrency flag sets the concurrency level with a default of 50, and the -t or -timeout flag sets the connection timeout in seconds with a default of 10. The -rl or -rate-limit flag sets a rate limit per second, and the -px or -proxy flag sets a proxy server by URL.

Output is four options. The -o or -output flag writes results to a file, -v or -verbose gives verbose output, -s or -silent prints only results, and -j or -json switches to JSON output.

The domain filter is the flag that turns this from a scanner into a reconnaissance tool. The -d or -domain flag filters results belonging to the given domains, comma separated, which is how you keep the output to the target you are actually working on.

A default of 50 concurrent connections with a 10 second timeout is a lot of load for a single target if you point it at a large list. The rate limit flag exists for that reason, and the examples show it set to 10 requests per second.

Working through the examples

The README's examples are short and cover the realistic uses.

A single domain, which is the case where the tool is most useful, is just the url flag with a scheme:

csprecon -u https://www.github.com

The same thing through standard input is possible, which lets you pipe from another tool:

echo https://www.github.com | csprecon

For a list of targets, the list flag takes a file, and the example notes that protocols are needed:

csprecon -l targets.txt

and the same file through a pipe:

cat targets.txt | csprecon

Restricting results to a specific target is the -d flag, which is how you avoid drowning in third party domains pulled from someone else's policy:

cat targets.txt | csprecon -d google.com

A CIDR range is handled by combining the url flag with the cidr flag:

csprecon -u 192.168.1.0/24 -cidr

The remaining three examples are the operational ones. A rate limit of 10 requests per second:

cat targets.txt | csprecon -rl 10

JSON output for piping into another tool:

cat targets.txt | csprecon -j

and traffic through a local proxy:

cat targets.txt | csprecon -px http://127.0.0.1:8080

What the output can and cannot tell you

The limits of the technique follow from what a policy header contains, and they are worth stating before the tool is used on a real engagement.

A policy names origins the page is allowed to load from, and it names them in a specific syntax that includes schemes, hosts and paths. What csprecon extracts is the domain information from that, which means the output is a set of hosts the site already tells you about. That is a genuinely useful signal, because the third parties in a policy are frequently less well known than the site itself, and a policy is a curated list rather than a guess.

What the technique cannot do is find anything the site does not mention. If a company has an internal service, a staging host or an acquisition that is not in any policy, this will not surface it. The same applies in the other direction: a site with a permissive policy that lists a large CDN or an advertising network gives you a domain that is not a target at all, which is why the -d filter matters and why the output needs reading rather than bulk ingestion.

The tool also inherits the limits of a single HTTP fetch. A site that serves different policies to different clients, or that only sets a policy on some pages, will give inconsistent results, and a site with no policy gives nothing.

One more limit is the delivery of the output. The results are hostnames, and nothing in the tool turns them into reachable services, so the next step of an assessment, and the point where the real work starts, is elsewhere.

Where this does not belong

The clear case is a site with no Content Security Policy, or one that sets a policy with no third party origins. The tool has nothing to extract, and no amount of flags changes that.

The second is wide asset discovery. A subdomain enumeration tool that uses a large dictionary finds hosts that no policy mentions, which is the majority of what a tester usually wants. csprecon is for the narrower question of what a site has already admitted to.

The third is anything that is not reconnaissance. The tool fetches a public header from a URL and prints domains. It does not attempt to exploit, authenticate or fuzz anything, and it is not built for that. The repository topics list bug bounty and reconnaissance, and that is the scope.

The fourth is operational caution. A default concurrency of 50 against someone else's infrastructure is a noticeable amount of traffic for a tool that is nominally passive, since each input is a full HTTP request. A rate limit, a small list, and a run outside peak hours are the difference between reconnaissance and noise. The proxy flag and the JSON output are there for people who want the requests to blend in or to route through their own infrastructure.

Maintenance, contributing and the licence

The release history shows a project that is being worked on. The recent versions are v0.4.7 from 2026-09-02, v0.4.6 from 2026-05-22 and v0.4.5 from 2026-05-08, and the last push to the repository was on 2026-10-14, with the repository not archived. Detailed changes for each release are in the release notes on the releases page.

The contributing path is deliberately minimal. Open an issue or a pull request, and before opening a pull request download golangci-lint and run it:

golangci-lint run

and if there are no errors, go ahead. That is the whole contract, and the linter configuration in the repository decides what the checks are.

The licence is MIT, and the README links the licence file in the repository. The author is edoardottt, and the homepage given is edoardottt.com, which is also the contact address.

The project has appeared in a few security newsletters and podcasts, which is a reasonable signal that it is known in the bug bounty community, and the repository topics cover the usual vocabulary of that world: reconnaissance, offensive security, bug bounty tooling and information retrieval.

Editorial conclusion

csprecon fits a security tester who has one target and wants the related domains the site itself points at, because a policy header is a curated list of third parties and subdomains that a wordlist will never reproduce. It is the wrong tool for wide asset discovery, since it only sees what a policy header exposes, and the wrong tool against a site with no policy or a restrictive one. Before you run it, check three things: that you have authorisation for the targets, that the site actually serves a policy, and that your request rate stays low, since the concurrency default of 50 is aggressive for a scan that touches someone else's infrastructure. The tool is MIT licensed, the current release is v0.4.7 from 2026-09-02, and the last push was on 2026-10-14.

Frequently asked questions

Official sources

1. edoardottt/csprecon on GitHub
2. License: MIT
3. Project website
4. README
5. Releases