Scope the attack surface you actually run

A pentest that ignores how the product is actually reached will still produce a PDF. It will not produce a list the team can act on. Scope is the difference.

GlitchIdea’s application security work is built around the surface that is live: the web application, the APIs behind it, and the identity paths that bind them together. Findings are written so engineering can change code and configuration, including through coordinated disclosure when that is the right channel.

The surface is not the marketing site

Teams often point a tester at the public homepage and call it “the app.” The interesting surface is usually next door: authenticated areas, partner APIs, webhooks, file upload, admin tools that are “not really public,” and staging systems that share identity with production.

Before testing starts, we want a map that a developer would recognise:

• entry points (web, mobile API, partner, jobs)
• identity (login, SSO, API keys, session)
• trust boundaries (tenant, role, environment)
• data that would hurt if it moved (accounts, tokens, PII, admin actions)

If that map does not exist, the first day of the engagement is to build it from running systems and source, not from a sales deck.

Checklists are a floor, not the scope

OWASP-oriented review is useful because it stops obvious classes of failure from being skipped: injection, broken access control, authn/authz mistakes, SSRF, insecure file handling. It is a floor. It is not the product.

The product has a business logic. Can one tenant read another’s objects if they guess an ID? Can a read-only token call a write route? Can a webhook be replayed? Can password reset be pointed at an account you do not own? Those questions do not appear as a single CWE line. They appear when someone uses the app the way an attacker would: as a user with a slightly wrong privilege.

APIs need their own pass

A browser pentest that never leaves the UI will miss the API the UI already calls — and the routes the UI does not expose. API work includes:

• authentication vs authorisation (a valid token is not a permit for every resource)
• object-level access on IDs and collections
• mass assignment and extra fields
• rate limits and token lifetime
• error messages that leak existence or internals

If the product is “an app plus an API,” both are in scope or you should say so explicitly. Hidden out-of-scope APIs become the incident later.

Identity is usually the shortest path

Most serious findings in application work are not exotic memory bugs. They are broken access control, session issues, and “this endpoint trusts the client.” Password reset, invite links, SSO callback, and API key management deserve more time than a scanner’s low-hanging XSS on a marketing form.

We spend time there on purpose. It is also where coordinated disclosure most often matters, because identity bugs are easy to copy once they are described carelessly. Reports from GlitchIdea are written for the owner of the system first, with enough detail to reproduce and not more public colour than the engagement requires.

What you should expect to receive

A pentest engagement should leave you with:

• a scoped description of what was tested and what was not
• findings ordered by how they change risk on this system
• reproduction that an engineer can follow without a call
• a clear line between verified issues and unverified hunches

It should not leave you with a score designed for a slide. If a number is required for a process you already have, we can map findings into that process. We will not invent a metric to decorate the report.

How to brief a test

You do not need a perfect document. You need:

• environments (prod, staging, and whether they share identity)
• accounts or how to get them
• a list of properties you care about (money, tenancy, admin, secrets)
• known out-of-scope (third-party widgets, denial of service, and so on)

From there we propose a scope you can put in a statement of work. If the surface is larger than the time, we cut by risk, not by what is easiest to screenshot.

To start, write with the system and the outcome.

A concrete example

A B2B app with “organisations” and “projects.” The UI hides another org’s project. The API does not: GET /api/projects/8471 returns the object if you have any valid session. That is broken object-level authorisation. A scanner may not rank it. A tenant who can iterate IDs will.

Scoping for that product means: authenticated API, org and project models, invite and billing routes, and the admin that support uses. It does not mean three days on the marketing CMS. If time is short, we test the tenancy paths first and write down what we did not touch.

That is what “the surface you actually run” looks like in a report: named routes, named roles, reproduced with two test accounts — not a generic OWASP appendix.