Notes on breaking things properly.

Thinking Beyond the Checklist: Logic-Based Vulnerabilities

Every automated scanner I've run has been good at the same narrow thing: matching known patterns against known payloads. Missing headers, outdated libraries, textbook injection points — the OWASP Top 10 covers this ground well, and tooling covers the Top 10 well. None of that is where the interesting findings live.

The vulnerabilities that actually change an assessment's outcome are almost never a broken parser. They're a sequence of individually reasonable actions that together violate an assumption the application never explicitly stated. A discount code that stacks past its intended limit. A password-reset flow that trusts the wrong parameter to decide whose password gets reset. An approval workflow that never checks whether the approver and the requester are the same person. Nothing here trips a signature. Nothing here looks malformed. The request is syntactically perfect and semantically wrong.

Finding this class of issue means building a mental model of what the application's designers believed would always be true, then spending deliberate time trying to make exactly one of those beliefs false. It's slower than running a tool. It's also the only way I've consistently found high-impact issues in applications that had already passed a conventional scan with a clean report.

My process starts with mapping state, not endpoints — every place the application remembers something about who you are, what you own, and what step of a flow you're on. State is where trust boundaries get drawn, and drawn incorrectly. From there it's a matter of asking, for every boundary: what happens if I'm on the wrong side of this. Most of the time, nothing interesting. Occasionally, everything.

Recon at Scale Without Losing the Manual Edge

Automation earns its keep in exactly one place during reconnaissance: coverage. A script doesn't get tired, doesn't skip the fortieth subdomain because the first thirty-nine were boring, and doesn't forget to check a variant it already ruled out an hour ago. That's a genuine advantage, and it's why I've built and open-sourced tooling around dorking, fuzzing, and secret detection rather than doing every pass by hand.

The failure mode is treating automation's output as a conclusion instead of a shortlist. A wordlist that misses one endpoint naming convention doesn't just miss that endpoint — it silently narrows the entire assessment without telling you it did. I've seen this cost findings on engagements where the tooling was excellent and the operator trusted it a step further than it deserved.

In practice this means every automated run I do — target ingestion, wordlist generation, tech-stack fingerprinting — produces a ranked shortlist, not a verdict. I still walk the application by hand afterward, specifically in the areas the tooling flagged as unusual or incomplete. The tooling's job is to make sure my limited manual hours go to the right ten percent of the surface, not to decide what that ten percent means once I'm there.

Why I Built a Secret Scanner for Burp Suite

Most credential leaks I've found in application traffic weren't hidden. They were sitting in a JavaScript bundle, a source-map file, or a debug response — plainly visible to anyone who happened to look at the right request at the right time. The problem was never detection difficulty. It was that nobody was looking at every request, all the time, closely enough to notice.

Burp Suite already sees every request and response that passes through it during an assessment. That's the natural place to catch a leaked key the moment it appears, rather than hoping it surfaces later in a manual review of exported traffic. So the extension does one job: watch the proxy history in real time and flag high-confidence credential and API-key patterns as they pass through, with enough context to triage immediately instead of re-tracing the request later.

The hard part wasn't pattern matching — it was precision. A scanner that fires on every thirty-two-character hex string is a scanner nobody keeps enabled. Most of the build time went into reducing false positives to the point where the tool stays on for an entire engagement without becoming noise, because a detector that gets muted is a detector that isn't running when it matters.

GitHub as Attack Surface: Notes on Dorking Responsibly

Source control history is one of the most consistently under-scoped parts of an attack surface. Teams rotate a leaked key the moment it's found in a live response, but the same key sitting in a commit from eighteen months ago, in a repository nobody's looked at since, tends to survive far longer than it should. Dorking against GitHub is how that gap gets found before someone with worse intentions finds it first.

I built Simple-GitDorker to automate the discovery of exactly this kind of exposure within authorized scope — high-risk keyword patterns, configuration artifacts, and the kind of misconfigurations that show up more often than teams expect once you actually go looking. The value isn't cleverness in the search terms. It's running the same disciplined set of checks consistently, against every target, instead of relying on memory for which pattern mattered last time.

Responsible use means two things in practice: staying strictly inside the engagement's authorized scope, and treating anything found as something to report through proper disclosure channels, not something to explore further on your own terms. The tooling automates discovery. It does not, and should not, automate judgment about what happens next.