Skip to main content
Technical walkthrough

From source signal to reachable behavior

Start with a suspicious code path, then establish whether it is reachable and what its controls do. Keep review signals separate from demonstrated behavior.

Source and application review

Source material passing through review and a reachable behavior check toward evidence
Illustration of the assessment workflow.

Before you startApproved source material, application context and a safe way to validate reachable behavior.

Follow a concrete application path from entry point to authorisation middleware, object lookup and response serializer. The investigation asks where identity and ownership are established, how they travel through the code, and which behavior can be validated in the approved environment.

01 / Bring the relevant source and context

Provide the relevant handler, permission checks, object-query code and serializer alongside the intended role model. Include the surrounding callers or configuration needed to understand which branch runs.

Use uploaded or hosted workspace material for the review. The public JavaScript tool can flag supported JavaScript syntax without running it; TypeScript, JSX and complete data-flow analysis need a different review path.

02 / Follow the path beyond the initial signal

Trace the external identifier from the route or request body into the object query. Does the query include the expected tenant or owner constraint? Does the middleware validate the operation, or only confirm that somebody is signed in?

Continue into the serializer and error paths. Review which fields or related objects are returned and whether alternate branches apply the same policy. Validate the reachable path with a permitted request and a contrasting account condition.

03 / Show the relationship between code and behavior

Connect the relevant source locations to the request that reaches them. Preserve the account conditions, the expected policy, the control response and the observation requiring remediation.

Explain the missing or misplaced check at the boundary where it matters. Keep open questions about callers or deployment configuration attached to the review.

04 / Verify the change at the right boundary

Review the changed permission or query condition, then repeat the request through the actual entry point. Check that the intended owner still succeeds while the contrasting identity receives the expected rejection.

Keep the retest linked to the original finding. Check the deployed behavior as well as the source change.

Questions to resolve before the review

  • What input and preconditions make the path reachable?
  • Which checks surround the suspicious operation?
  • What observation would confirm or disprove the hypothesis?