Exercise 3: How Sincere Authorization Can Still Become Unauthorized Access — Possible Solution ==================================================================== THE SCENARIO FROM THE CHAPTER'S WARN-BOX ------------------------------ A client genuinely, sincerely authorizes testing of "our website," believing in good faith that this authorization covers everything needed. But per the chapter's own warn-box, the client may not realize that website actually "sits on shared hosting, behind a third-party CDN, or inside a cloud environment where other systems — belonging to OTHER organizations entirely — share the same infrastructure." HOW THIS TURNS INTO GENUINELY UNAUTHORIZED ACCESS ------------------------------ Per the chapter, if testing "goes even slightly beyond what the client actually owns and controls," the tester can end up accessing systems belonging to a completely different organization — one that never authorized anything at all. The client's own authorization was sincere and given in good faith, but authorization can only actually cover systems the client themselves has the legal authority to authorize testing of. A client cannot grant permission to test infrastructure they don't own or control, even if they mistakenly believe "our website" includes it. The tester ends up committing real unauthorized access against a third party, even though, from the client's side, everyone involved believed the testing was fully authorized. WHAT SPECIFIC SCOPING DETAIL WOULD HAVE PREVENTED IT ------------------------------ Per the chapter's own closing point, scope has to specify "precise IP ranges, exact domains, and explicit exclusions" rather than "general descriptions like 'our website' or 'our network.'" If the written scope document had listed the exact IP ranges and domains the client genuinely owns and controls — rather than the vague phrase "our website" — any shared hosting, third-party CDN infrastructure, or cloud-provider-owned systems would have been mechanically excluded from the start, since they wouldn't appear in that precise list. The precision itself is the safeguard: it forces the authorization question ("does the client actually own and control this specific system?") to be answered explicitly, system by system, before testing begins, rather than left to an assumption that turns out to be wrong. WHY THIS WORKS AS AN ANSWER ------------------------------ It walks through the chapter's own warn-box scenario step by step — sincere belief, the shared-infrastructure reality, the resulting unauthorized access against a third party — and identifies the exact scoping fix (precise IP ranges/domains/exclusions vs. vague descriptions) the chapter itself names as the solution.