Skip to content
Code Recycle

Component · for humans & their agents

Unprotected Route Scan

verified · first-partyactively maintained$0 during beta (was $29)

Your assistant wrote an endpoint to delete a project. It works — because you were signed in when you tested it. Nobody is signed in when a stranger calls it with curl.

by saltyhash · Code Recycle admin

Get it free — beta

Every claim on this page is refundable if it is untrue — refund policy.

Verified: 19 tests · 10/10 mutations caught

An audit of one AI-assisted codebase found NINETEEN route handlers with no authorisation check of any kind, in an app that had been in daily use for months — because every one of them worked perfectly for the logged-in developer who asked for it.

Not a rare slip

An audit of one AI-assisted codebase found NINETEEN route handlers with no authorisation check of any kind, in an app that had been in daily use for months — because every one of them worked perfectly for the logged-in developer who asked for it.

| verdict | meaning | |---|---| | `unprotected_mutation` | a state-changing handler with no authorisation — the one to fix | | `webhook_unverified` | a webhook with neither a session check nor a signature verification | | `unprotected_read` | a read with no authorisation — often deliberate; decide rather than assume | | `protected` | an authorisation call exists (see below for exactly what that claims) | | `declared_public` | you have said this path is public on purpose |

An unauthenticated GET on a public listing is a design choice. An unauthenticated DELETE is a hole. Treating them alike gives a list too long to act on and buries the four lines that matter, so only the first two fail a deploy.

Webhooks are the trap inside the trap

A payment webhook has NO SESSION BY DEFINITION — the caller is Stripe, not a person. Demanding a session check there is noise, and worse, it teaches somebody to add a blanket exception; the blanket is what eventually covers a real route. But a webhook is not therefore unprotected: it authenticates by SIGNATURE. So an unsigned webhook is its own finding with its own fix, and a signed one is correct rather than merely excused.

What it claims, exactly

That an authorisation call EXISTS. Not that it is correct, not that it covers every branch, not that it checks the right thing — none of which a static reader can know. The output says so in as many words, because a tool implying otherwise would be sold on a promise it cannot keep.

Identifiers are matched WHOLE. An earlier version matched substrings and reported a route as protected because it called `scan(...)` — "can" was in the auth list. A false clean bill of health is the worst direction this tool can be wrong in, so short tokens are gone and "authorize" no longer matches "notauthorized".

Two escape hatches, because without them it is noise

Every codebase has one guard helper of its own and a handful of deliberately public paths. `authFunctions` and `publicPaths` exist so a team can say so — a tool that cannot be told gets ignored rather than fixed.

Verified

19 tests, 10 deliberate defects, all 10 caught — including mutations downgraded to reads, any path containing "webhook" auto-passing, the pages router silently skipped, and substring matching restored.

Delivery

Source delivered as a private repository invite within 24 hours of purchase. Single-product commercial license: use and modify in any number of products; no redistribution or resale of the source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function isRouteFile(path: string): boolean;
  export function looksLikeWebhook(path: string): boolean;
  export function handlersIn(file: SourceFile): Method[];
  export function scanRoutes(files: SourceFile[], options: ScanOptions = {}): RouteFinding[];
  export function hasUnprotectedMutation(findings: RouteFinding[]): boolean;
  export function formatRouteFindings(findings: RouteFinding[]): string;
  export type Method = "GET" | "HEAD" | "OPTIONS" | "POST" | "PUT" | "PATCH" | "DELETE" | "unknown";

01Capabilities

Does

  • + Role-based access control
  • + Security triage
  • + Pre-deploy checks

Doesn’t

  • No exclusions declared

02Requirements & stack

Depends on

No declared dependencies

Credentials needed

None declared

Stack

typescript

03Community

No endorsements yet

No verified confirmations yet — be the first.

Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.

Open an issue

Sign in to confirm — weight comes from verified usage, not vote count.

0 open · 0 answered · 0 fixed · 1 said it worked

04Trust Passport

Full passport →
–/100

0/0 automated components pass. An automated score is never a security guarantee.

✓ Verified · first-partyreviewed Sep 20, 2026 · re-verification due Dec 19, 2026
  • publisher identity Publisher status verified; 1 verification(s) on file
  • malicious pattern scan No known malicious-behavior patterns across 8 source file(s) plus listing text
  • capability contract All 0 observed capability reference(s) match the declared manifest
  • agent safety scan No injection patterns in agent-readable content
  • provenance No release signature or provenance attestation
  • behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.

Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.

VersionChannelReleasedNotes
1.0.0stableAug 11, 2026First public release.