Source review: entry point to protected operation

Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

Used in these playbooks#

Write the invariant first#

Choose a business rule precise enough to falsify: “a member can export documents only from a project where membership is currently active.” Record actor, object, operation, tenant, and when authorization must hold. A suspicious function becomes useful when you identify who can reach it and what protected state it changes. Reuse the authorization matrix for principal/object combinations and injection tracing for interpreter-specific input handling.

Start forward at a real interface: HTTP route, websocket event, CLI argument, uploaded project, plugin callback, or queue producer. Then work backward from the sensitive read, write, process invocation, parser, or credential use. Join the two traces; unresolved dynamic dispatch is an explicit gap. Check route registration and feature gating rather than assuming a named handler is exposed.

A worked asynchronous trace#

The following is a hypothetical review worksheet, not a finding against a named project.

A useful candidate is “worker rehydrates an object globally after a tenant-scoped request.” Confirm whether the earlier guard binds the same immutable identifier, whether membership revocation should affect queued jobs, and whether the output is actually accessible. Business requirements may deliberately snapshot permissions; document that distinction rather than treating every delayed check as defective.

Local search and modeling cheat sheet#

Examples inspect a reviewed local repository. Patterns are leads, not a complete inventory. Place evidence outside the scan root; prepare local rules before offline/private-code analysis.

rg -n --hidden -g '!.git' \
  'route\(|router\.|websocket|add_task|enqueue|\.delay\(' ./repo
rg -n --hidden -g '!.git' \
  'pickle\.loads|yaml\.load|subprocess\.|child_process|exec\(' ./repo
semgrep scan --oss-only --config ./rules --metrics=off \
  --disable-version-check --json \
  --output ./evidence/source-leads.json ./repo

The Semgrep command uses reviewed local rules and the OSS engine. Inspect stderr, skipped files, and scan completion; an empty result with parser failures is not a clean audit. Rule licenses and engine capabilities are separate concerns. Semgrep CLI reference.

Model sources, propagation, context-specific sanitizers, and sinks. A path validator does not sanitize a shell argument; a role check does not validate serialized data. Custom wrappers can hide a source or sink from default rules. Create one vulnerable fixture and one safe sibling to validate your model. Static taint analysis does not automatically establish tenant policy or full runtime reachability. Semgrep taint model.

Prove the boundary through supported use#

Instrument the local application to log identifiers, decisions, and function names without credentials. Reproduce from the ordinary interface with synthetic accounts. Keep four observations together: allowed own-object request; denied or expected-to-deny foreign-object request; actual protected effect; resulting output access. Repeat without instrumentation changing security behavior. If only an internal helper is callable, qualify the finding as a library/caller-contract issue until a consumer path is established.

Inspect alternate callers after proving one flaw: bulk API, export service, websocket subscription, scheduled task, and administrative UI may reuse the same operation with different guards. Group equivalent paths by root cause and record tested variants. Do not inflate one shared defect into five independent findings.

Completion and report threshold#

• Invariant identifies actor, object, operation, and trust boundary.
• Attacker-controlled field is tracked through transformations and aliases.
• Every guard is evaluated with concrete fixture values.
• Feature, edition, role, and configuration prerequisites are explicit.
• Real interface reproduces the protected effect beside an authorized control.
• Safe sibling and patch retest preserve legitimate behavior.

Submit the smallest connected argument: entry point → attacker control → ineffective boundary → sensitive operation → demonstrated impact. A sink search, scanner trace, or direct helper call alone belongs in the hypothesis queue.

Vulnerability reverse references#

• Hard-coded product credentials — A reusable credential is embedded in source, history, a release, or a default configuration. Distinguish a shared built-in credential from an accidentally committed deployment credential when assigning the weakness.
• Unsafe object deserialization — Untrusted bytes reach a format that can instantiate behavior-bearing objects or invoke code, such as Python pickle, without a sufficient trust boundary.
• JavaScript prototype pollution — An attacker-controlled property path changes inherited object state, which can affect unrelated objects and security-sensitive consumers.
• Out-of-bounds memory write — A native component writes beyond an allocated object because length, index, or allocation assumptions do not agree.
• Use after free in a public API or parser lifecycle — Code uses an object after its lifetime has ended, often across callbacks, error handling, reference counting, or asynchronous operations.
• Integer overflow affecting allocation or bounds — Input-derived arithmetic wraps or overflows so the checked size, allocation size, and later operation refer to different effective values.
• Regular-expression denial of service — An attacker-controlled string makes the chosen regular-expression engine perform excessive backtracking or other disproportionate matching work.
• Predictable temporary files and unsafe creation — A component creates or reuses temporary files in a way that permits another local principal to precreate, replace, read, or redirect sensitive operations.
• Untrusted executable, library, or module search path — A program resolves an executable/library/module from an attacker-writable search location instead of the intended trusted component.
• Firmware contains a reusable shared authentication credential — An attacker-accessible firmware artifact embeds a credential that grants protected access, potentially across multiple devices.
• Exposed repository or history secret — Source, history, or a published artifact exposes a credential outside its intended audience.
• Sensitive data in errors, debug routes, or generated files — An error or debug output crosses a confidentiality boundary by revealing protected state.
• Predictable security token or capability identifier — A security token relies on randomness that does not meet its unpredictability requirement.
• Password storage without an adequate adaptive hash — A password verifier has insufficient computational cost for its supported threat model.
• Encrypted data accepted without integrity authentication — A protected data format permits security-relevant changes that are not detected before use.
• SAML assertion signature, audience, or response binding failure — The service provider trusts an assertion whose signature or authentication context is not valid for the receiving flow.
• Untrusted model artifact reaches executable deserialization or custom code — An attacker-controlled artifact reaches a loader whose execution trust exceeds the uploader's intended data-only authority.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity