Read the scope first
Most of the time I lose on a target is lost to my own setup and assumptions — not the target. A short note on the boring discipline that actually moves findings.
I spent two hours “bypassing” a bot challenge once before I noticed the program had already allowlisted my account. The wall wasn’t the target. It was my own setup. I’d skipped the scope notes because I was impatient to start hacking.
That’s the most expensive habit in this work, and it took me a while to admit it: the thing slowing you down is usually not the target’s defenses. It’s your assumptions about them.
The cheap wins are in the reading
Before I touch a single request now, I read everything the program gives me:
- Scope and out-of-scope. Not just the in-scope hosts — the exclusions tell you where they’ve already been burned, which is a map of where the interesting bugs were.
- Rules of engagement. Rate limits, allowlists, test accounts. Half the “anti-bot” walls people fight are switches the program already flipped for researchers.
- Past disclosures, if public. The same bug class often recurs in a different endpoint.
None of this is glamorous. All of it saves hours.
The bug is usually in the assumption
When I’m stuck, the question that unsticks me most often isn’t “what else can I try” — it’s “what am I assuming that I haven’t checked.” The config I assumed was right. The header I assumed was ignored. The endpoint I assumed was the same as the one in the docs.
The bug was never in the code I was staring at. It was in the thing I took for granted.
A small discipline
So the loop I actually run looks boring:
- Read the scope and the rules. All of it.
- Confirm my setup matches what the program expects — test account, allowlist, proxy.
- Then form a hypothesis and test it.
- When stuck, list my assumptions and check the cheapest one first.
It’s not exciting. It just works more often than the alternative, which is two hours fighting a wall that was never load-bearing.
Read the scope first. Future-you will thank you.