A reusable access-control workflow within a SaaS penetration test

Illustrative scenario. All people, systems, observations and results below are fictional. No assessment or workflow evaluation has taken place.

A client commissions a penetration test of its SaaS application after changing its permissions model. One concern is whether an ordinary customer user can retrieve reports belonging to another customer. You have reader and editor accounts in two explicitly authorised test tenants, Amber and Blue, each containing a recognisable synthetic report. The rules of engagement permit individual report retrieval, authenticated report exports and cross-tenant comparisons between those tenants. Production tenants, real customer records and bulk extraction are excluded.

You first use the application normally to understand how reports are opened and downloaded. The agreed permissions matrix says readers can retrieve their own tenant's reports, while selected updates require an editor. It gives you an expected rule to investigate. It does not tell you every way the application might expose the same data.

Your team has a reusable workflow for selected report reads and updates. It is a versioned procedure operated through a browser and request recorder, with an account-to-tenant map, a permitted baseline before each access-control comparison, and a record linking each conclusion to its evidence. You adapt its checks to the current application's requests and select the ones relevant to this engagement. Another competent practitioner reviews that adaptation before you rely on it.

This walkthrough assumes a workflow evaluated for its intended use, with its engagement adaptation reviewed. The downloadable version 0.1.0 is a separate illustrative draft whose evaluation still blocks client use. It must be corrected and re-evaluated before use.

With the Amber reader account, you capture a permitted request for Amber's synthetic report. In a separate session, the Blue account confirms Blue's report and its distinctive content. You now have a known object in each tenant and evidence of the account context. You do not need to search for other tenants or guess real customer identifiers.

The workflow guides the comparison using only the Amber session and the known Blue report identifier. Through the ordinary report route, the application denies access and returns no Blue report content. Permitted Amber reads before and after the comparison confirm that the session remained valid. You retain the relevant requests, responses and identity context, with secrets redacted, in the engagement's agreed evidence store.

The maintained procedure helps you avoid a misleading result here. If the supplied credentials stop working, a login redirect is an execution problem. You stop the affected activity, record which checks could not be completed and resolve the session problem with the lead before repeating them. It cannot support a statement that cross-tenant access was denied. If evidence capture fails, you also stop and preserve what is available. Your recollection alone cannot support the conclusion.

You select checks that fit the agreed request budget and operating window, leaving time to review their evidence. The workflow records what you selected, what actually ran and what was left untested. Its completion status is useful for managing that activity; it cannot tell you whether the client's broader concern has been adequately investigated.

While using Amber's normal download function, you notice that the application retrieves the report through a separate authenticated export-result endpoint. The request uses an export identifier rather than the ordinary report identifier. That makes the earlier denial less informative about the download path. You decide to investigate this path before spending more time on variations of the ordinary report request.

You establish that the export result is intended to be restricted to users of the owning tenant. This is not an intentionally shareable signed link. You also check that the proposed comparison falls within the engagement's written permission for individual exports from the two test tenants. It sits outside the reusable workflow's selected report checks, so you record it as a separate investigative step with its reason and applicable limits. A workflow's narrow operation list and the engagement's wider authority remain distinct. If exports had not been authorised, you would need the client's scope decision before proceeding.

Using the authorised Blue account, you obtain the identifier for Blue's synthetic report export. You then request that result with only the Amber reader's authentication. No Blue cookie, token or bearer link is carried into the comparison. The response contains Blue's recognisable report data. A 200 response alone would not establish disclosure; the returned content and the authenticated account context are what support the observation.

The rules of engagement permit one isolated confirmation on this known synthetic export, provided the session and evidence capture are working. You retain enough detail to establish the result, then stop that line of probing. There is no reason to retrieve further reports or try real customer identifiers to strengthen the demonstration. If unexpected real data, uncertain scope, a timeout or an unintended state change appeared, you would stop immediately and contact the agreed lead and application owner as appropriate.

Mia, the technical lead, reviews the underlying request and response with you. The decision is whether the evidence supports a finding and whether another in-scope step is justified by the remaining objective and time. A target violating its access rule can be a valid investigative result. A failed session or missing evidence is a problem with the test's validity. They require different decisions.

The finding describes cross-tenant disclosure through the authenticated export-result endpoint. It states the Amber reader's starting privileges, the intended tenant restriction, the request made and the Blue synthetic content returned. The supporting evidence lets another practitioner check that conclusion. A generated explanation or a summary saying that access control failed would not be enough.

There is an important precondition: you supplied a known export identifier obtained through the authorised Blue account. You have demonstrated access when that identifier is known. You have not demonstrated how an attacker would discover it independently. The report keeps that distinction visible when describing exploitability and impact.

The coverage statement also records the supported denial through the ordinary report route and the separate export finding. It does not generalise either result to all report types or tenants. You identify the relevant paths left unexamined, including other export formats, sharing functions and independent identifier discovery. The selected privileged write operations have not been investigated in this walkthrough. Mia and you decide which remaining activity warrants engagement time; anything left incomplete is reported as a limitation.

The application owner receives the evidence and reproduction context for remediation. If a targeted retest is agreed, you record the fixed build and repeat both the cross-tenant export comparison and a permitted own-tenant retrieval. You retain the evidence for that retest rather than inferring a fix from a developer's explanation.

The reusable workflow covers selected report reads and updates. The export investigation above is consultant-led work under separate engagement authority. Neither activity investigates every route, role, object type or way of combining weaknesses.

Depending on the scope and observations, further work could examine another access path, abuse of a sharing process, or a combination of weaknesses that changes the starting privileges. These are possible investigative directions, not mandatory checks for every engagement. A reachable resource does not authorise testing it. The remaining time, available accounts and agreed limits affect the conclusions you can draw.

After the engagement, Mia may consider adding the export comparison to the maintained workflow. She first removes engagement-specific data and secrets, specifies its operating boundary and evaluates whether another practitioner can perform it and collect usable evidence. An investigative step being justified during one engagement does not automatically make it an approved reusable capability.

Evaluation establishes whether a workflow performs its intended function under the conditions tested. It does not establish that an engagement is complete or that the assessed environment is secure. During the assessment, you still choose the investigation, adapt to observations and develop defensible findings and coverage statements.

The completed fictional evaluation record (Markdown) shows seven independent cases for the narrow workflow. They include permitted and prohibited actions, a cross-tenant denial, expired authentication, a timeout, insufficient evidence and a deliberately vulnerable fixture. These are invented records, not results from the engagement described above or evidence that the export investigation has been evaluated.

Two unresolved issues block version 0.1.0: it misclassifies an expired session as evidence of a denied attack, and it permits a claim without sufficient captured evidence. Mia's fictional decision is not ready for client use until the corrections and fresh evaluation evidence support a new decision. The deliberately vulnerable case shows the distinction between workflow behaviour and target security: correctly identifying and evidencing the weakness meets that case's workflow criteria even though the target violates its access rule.

The specification and evaluation records retain the detailed result categories, responsibilities, execution limits, stop conditions and recovery arrangements. They provide the reference needed to adapt and review a workflow without turning the engagement into a predetermined sequence.

The walkthrough works without an agent. If one helps prioritise the selected checks or proposes an investigative lead, Mia reviews the specific action, supporting rationale and likely effects against the engagement authority before you execute it. In this example the agent has no application credentials or execution tools. Its suggestion cannot authorise another tenant, endpoint or action, and its explanation cannot substitute for evidence.

Record the model and exposed version, prompt, settings, available tools and agreed processing arrangement. Evaluate that configuration before relying on its output and keep secrets out of its inputs. The approval note explains what a reviewer needs; the model-update note covers changes that invalidate earlier evaluation assumptions.

Download the complete workflow pack (ZIP)

• Completed fictional workflow specification (Markdown)
• Blank workflow specification template (Markdown)
• Completed fictional evaluation record (Markdown)
• Blank evaluation record template (Markdown)
• Pack README: use and adaptation (Markdown)

Start with the README. Use the templates to distinguish the engagement's objective and authority from the workflow's selected operations. Replace the fictional accounts, fixtures and owners, and resolve the scope, intervention, evidence and readiness decisions before use. OffSecDevOps is a practitioner-developed framework; these records support a specific delivery decision, without a certification or readiness score.

Use the existing readiness prompts alongside the records. If adoption exposes operational problems, start with the relevant delivery failure mode.