When a prospect approached us for a web‑application penetration test, the engagement looked routine: their statement of work listed just one API endpoint, the same scope three other security firms had quoted (and supposedly tested) over the past three years.
Peeling Back the Layers: The Scoping Call
Instead of sending a boiler‑plate quote, we kicked off a technical scoping call with the customer’s engineering team. Early in the conversation a red flag appeared:
- “We don’t maintain an OpenAPI/Swagger file,” the engineers said.
- Yet the system relied on a micro‑service gateway that felt far larger than a single route.
Rather than guess, we asked the engineers to review their source code and tally the real number of endpoints. Two days later they came back somewhat shocked themselves with a count of approximately 700 unique paths and verbs.
The Challenge
- Risk misrepresentation – A one‑endpoint quote implied a tiny attack surface, grossly understating business risk.
- Timeline explosion – Testing 700 endpoints thoroughly is not a two‑week sprint.
- Budget reality check – Our initial ballpark (aligned to the one‑endpoint scope) was no longer realistic.
Our Approach
- Transparent recalibration
- Shared the new endpoint inventory provided by engineering.
- Walked through how the expanded surface affects authentication testing, rate‑limit abuse, business‑logic testing, and retest cycles.
- Detailed, line‑item quote
- Clear breakdown of phases, deliverables, and a retest window.
- Explained how proper scoping ultimately lowers long‑term cost by preventing missed issues and “surprise‑findings” later.
Outcome
- Revised higher quote approved. The client valued accuracy over a “too‑good‑to‑be‑true” price.
- Competitive edge: Our diligence exposed a blind spot missed by three previous vendors, proving real expertise.
- Long‑term partnership: We’re now their preferred security provider for annual assessments and DevSecOps consulting.
Lessons for Security Leaders
- Never skip a technical scoping call. Even detailed RFPs hide architectural surprises.
- If no API spec exists, engage engineering early to verify endpoint counts from the codebase.
- Insist that vendors list the exact number of endpoints, user roles, and auth flows their quote covers.
- Beware of “checkbox” pen tests. If a proposal doesn’t change when scope does, it’s not risk‑driven, it’s commoditised.
Quick Checklist for Accurate API Pen‑Test Scoping
- ✅ Provide an up‑to‑date OpenAPI/Swagger file or let engineers confirm counts from source code.
- ✅ List user roles and auth mechanisms (OAuth2, API keys, JWT, etc.).
- ✅ Disclose rate limits, throttling, and environment constraints.
- ✅ Clarify micro‑service gateways vs. actual downstream endpoints.
- ✅ Allocate time for dynamic discovery, undocumented routes happen.
Closing Thoughts
Good security isn’t cheap, and cheap security isn’t good. Scoping diligence protects budgets and reputations alike for both client and vendor. Planning a penetration test? Start with a conversation, not a canned quote.
Ready for an assessment that uncovers what others miss? Let’s talk.
