Where
apps/web/app/api/cron/process-vlm-queue/route.ts lines 12–17
Problem
Every other cron handler authorizes via the shared isAuthorizedCron(request.headers.get("authorization")) helper in apps/web/lib/cron-auth.ts (e.g. send-alerts/route.ts:36, archive-incidents, etc.). This one route reimplements the check inline against env.WATCHDOG_CRON_SECRET:
```ts
const auth = request.headers.get("authorization") ?? "";
const token = auth.startsWith("Bearer ") ? auth.slice(7) : "";
if (!env.WATCHDOG_CRON_SECRET || token !== env.WATCHDOG_CRON_SECRET) {
return NextResponse.json({ error: "unauthorized" }, { status: 401 });
}
```
Why it matters
- Drift: any future hardening to
isAuthorizedCron() (timing-safe compare, multiple-secret rotation, IP allowlist, etc.) silently misses this route.
- Onboarding hazard: a new contributor reading the codebase has to discover two auth patterns and figure out which is canonical.
Suggested fix
Replace the inline check with a call to isAuthorizedCron(...). If WATCHDOG_CRON_SECRET is intentionally a separate secret from the standard cron secret, that distinction should live inside cron-auth.ts (e.g. isAuthorizedCron(headers, { secret: "vlm" })), not in the route handler.
Severity
Med — not a vulnerability today; it's a consistency / future-drift bug.
Where
apps/web/app/api/cron/process-vlm-queue/route.tslines 12–17Problem
Every other cron handler authorizes via the shared
isAuthorizedCron(request.headers.get("authorization"))helper inapps/web/lib/cron-auth.ts(e.g.send-alerts/route.ts:36, archive-incidents, etc.). This one route reimplements the check inline againstenv.WATCHDOG_CRON_SECRET:```ts
const auth = request.headers.get("authorization") ?? "";
const token = auth.startsWith("Bearer ") ? auth.slice(7) : "";
if (!env.WATCHDOG_CRON_SECRET || token !== env.WATCHDOG_CRON_SECRET) {
return NextResponse.json({ error: "unauthorized" }, { status: 401 });
}
```
Why it matters
isAuthorizedCron()(timing-safe compare, multiple-secret rotation, IP allowlist, etc.) silently misses this route.Suggested fix
Replace the inline check with a call to
isAuthorizedCron(...). IfWATCHDOG_CRON_SECRETis intentionally a separate secret from the standard cron secret, that distinction should live insidecron-auth.ts(e.g.isAuthorizedCron(headers, { secret: "vlm" })), not in the route handler.Severity
Med — not a vulnerability today; it's a consistency / future-drift bug.