check-silent-bypass

Files (1)

• SKILL.md

SKILL.md (first lines)

# Silent-Bypass Review

Read the in-scope `.ts` / `.tsx` files, apply the rubric below, and report
findings inline. Do NOT modify any files — this is read-only review.

## Scope

- **Include:** `packages/<pkg>/src/**/*.ts(x)`
- **Exclude:** `*.test.ts(x)`, `*.d.ts`, `packages/sdk/src/testing/`,
  `dist/`, `node_modules/`

UI, examples, and scripts are out of scope: silent bypass is a trust
enforcement concern, and trust is enforced in package code. Client-side
validation is a UX hint, not a security control.

File selection, in order:

1. If the user supplies paths or globs as arguments, scan exactly those
   (still respecting the exclude list).
2. If files in scope were edited in the current session, scan those.
3. Otherwise scan in-scope files from `git diff --name-only
   origin/main...HEAD`.
4. Otherwise scan unstaged in-scope files from `git diff --name-only HEAD`.

If nothing is in scope, say so and stop — do NOT scan the whole repository
unless the user explicitly asks.

## How to read each file

1. Read the **full** file — naming and return-type analysis need
   surrounding context, not just the diff hunk.
2. Walk the body looking for the three patterns below.
3. For each candidate, decide: real bypass, or a documented negative case?
4. Lines ending with `// allow-bypass: <reason>` are author-acknowledged —
   drop those candidates.

## Rubric — three patterns

### Pattern A — Trust boundary skipped on a plausible branch

A real validation path is gated behind a condition that *looks* like a
sanity check (well-formed input, expected prefix, common case), and the
other branch silently accepts the input without performing the check.

**Flag:**

```ts
if (token.startsWith("cashuB")) {
  const decoded = verify(token); // only well-formed tokens get verified
  return { valid: decoded.ok };
}
return { valid: true }; // anything else passes
```

```ts
if (env.NODE_ENV === "production") {
  await checkRateLimit(req);
}
return handler(req); // dev/test/staging skip the limit
```

**Do NOT flag:**

- Validation whose other branch returns a clear error
  (`return { ok: false, error: "..." }`).
- Type narrowing whose other branch is a compile-time impossibility
  (exhaustive switch with `assertNever`).
- Dispatch tables where each branch fully handles its own type.

### Pattern B — Error swallowed and converted to success

A try/catch wraps a load-bearing operation; the catch discards the error
and returns a success-shaped value, or the function reports success when
the operation provably failed.

**Flag:**

```ts
try {
  const decoded = getDecodedToken(token);
  return { ok: true, decoded };
} catch {
  return { ok: true }; // swallows the decode failure
}
```

```ts
const result = await db.update(...);
return { updated: true }; // ignores result.rowsAffected
```

**Do NOT flag:**

- A catch that logs and returns a clearly-failed result.
- A catch that re-throws or wraps the error.
- A catch handling one specific narrow error type and re-throwing the rest.
- Best-effort operations whose failure is documented as acceptable.

### Pattern C — Success claimed without doing the work

A function whose name implies a side effect (`settle`, `verify`,
`validate`, `persist`, `send`, `redeem`, `finalize`, `commit`, …) returns a
success-shaped value without performing it.

**Flag:**

```ts
async settle(token: string): Promise<{ settled: boolean }> {
  return { settled: true }; // name claims work, body does none
}
```

**Do NOT flag:**

- Functions named `is*`, `has*`, `can*`, `should*`, `get*`, `from*`,
  `format*`, `build*`, `compute*` — read-only by name.
- Stubs returning a clearly-failed result with an explicit error — loud
  failure is the correct surface.
- Pass-through wrappers that delegate.

From motxx/anchr, MIT.

More from motxx/anchr