Public Cron Endpoint Check — Can Anyone Run Your Scheduled Jobs?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
A cron or trigger endpoint without an auth check lets anyone run your scheduled job on demand — draining email quotas, mutating data mid-cycle, or fanning out jobs continuously.
Why AI tools generate it
Cron handlers trust the scheduler and skip the check; Vercel sends CRON_SECRET precisely so the handler can verify it, and AI scaffolds never read that header.
How DevMeth detects it
A code scan cross-references vercel.json cron paths (and /cron, /scheduled, /trigger routes) for handlers that do real work with no Authorization check, and flags queue dashboards mounted without auth middleware.
Cron jobs and queue dashboards are publicly reachable
WHAT WE FOUND
C43 — masked sample
The fix, in three steps
Verify the Authorization header against CRON_SECRET before any work in the handler, and mount queue dashboards behind your admin auth middleware.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
Vercel already secures cron routes, right?
Vercel SENDS a bearer secret with each invocation when CRON_SECRET is set — but your handler must verify it. Skipping the check accepts the request from anyone who knows the URL.
Why is this repo-side only, not probed live?
Confirming reachability live would trigger the job — real emails, real mutations, on your production users. A scanner must not do that; the missing check in code is the evidence.
What's the fix?
One guard at the top of the handler: verify Authorization equals Bearer CRON_SECRET, else 401. Queue dashboards: mount behind the admin auth middleware.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.