All posts
Go wide before you go deep

Go wide before you go deep

The best vulnerabilities I've found were never on the main domain.

Everyone's hammering login forms and testing XSS on the homepage. I get it. That's where the application lives, that's where the features are, and that's where every scanner points by default.

But that's also where every other hunter is looking.

I prefer being somewhere else. Forgotten subdomains. Staging environments. Internal tools someone exposed two years ago and never took down. The stuff that doesn't show up in the main application's navigation but absolutely shows up in DNS records.

Companies protect what they see. The main domain gets the WAF, the hardening, the quarterly security reviews, the pen test every year. Everything else? That depends on whether someone remembers it exists.

This is exactly why I prefer wildcard and company-level scopes over limited ones. A limited scope funnels every hunter into the same attack surface. You're all testing the same login form, the same API, the same handful of endpoints. The competition is brutal, and the easy findings are gone within hours of a program launching.

Wildcard scopes flip that equation. Instead of competing with hundreds of hunters on the same five pages, you go where nobody else is looking. And the things you find out there are almost always worse than what's on the main app.

Things I've found just by going wide:

  • SQL injection on legacy internal tools still connected to production databases
  • Staging environments mirroring production with broken access controls
  • Internal APIs leaking full user records with zero authentication
  • Verbose error messages exposing stack traces and database credentials
  • Outdated frameworks with known CVEs that nobody bothered to patch

The main application? Solid. Hardened. Tested by hundreds of hunters before you even opened the program page. The security team knows about it. The developers care about it. It gets attention.

That subdomain from 2019 that nobody remembers? Untouched. Running a framework version that stopped getting security patches three years ago. Connected to the same database as production. No WAF. No monitoring. No rate limiting. Nothing.

I've seen this pattern enough times to make it a core part of how I work. When I join a new program, I don't start with the main application. I start with reconnaissance. Wide reconnaissance. I want to know every subdomain, every IP range, every service running on a non-standard port. I want to find the things the security team forgot about, because those are the things that haven't been tested.

The boring recon work is what separates hunters who find duplicates from hunters who find criticals.

This doesn't mean the main application is worthless. Complex business logic bugs, race conditions, and authorization flaws still live there. But if you're looking for quick, high-severity wins, expanding your attack surface is the fastest way to find them.

My advice is simple. If a program offers a wildcard scope, take it. Don't limit yourself to the main domain. Go wide first. Map everything. Find the forgotten assets. Then go deep on the ones that look neglected.

The abandoned staging server with a default admin password will always be easier to crack than the hardened production login that's been tested by every automated scanner on the planet.

Go wider before you go deeper.

Want me to find this in your app, or learn to find it yourself?

Request a pentestBook mentoring
← PreviousStop skipping JavaScript filesNext →Your scope protects from findings, not from attackers