Most of the checks on this blog assume a feature has a URL someone visits or an API endpoint someone calls. Scheduled jobs and background workers, a nightly report generator, a job that syncs data with a third-party service, a cleanup task that runs every hour, don't fit that shape, and I think that's exactly why they get so much less scrutiny than they deserve.
Why these get built with looser assumptions
A background job is usually written with an implicit assumption baked in: only the system itself triggers this, so it doesn't need the same access checks a user-facing route would. That assumption is often true. It's also rarely verified, and background jobs frequently end up with broader database access than any single user-facing feature needs, precisely because they're built to touch a lot of data at once, on a schedule, without a specific person's session attached to the request at all.
Where this actually becomes a real risk
- A job that also has an API endpoint or webhook that can trigger it manually, for testing or debugging, and that trigger endpoint doesn't get the same auth scrutiny as the rest of the app because it 'was only meant for internal use.'
- A background worker running with a service-role or admin-level database key, because it needs broad access for its normal job, but that same broad key is now sitting in the job's environment, a bigger target than any single user-facing credential.
- A scheduled task that processes user-submitted data in bulk, and inherits any input-validation gaps from wherever that data originally came in, except now running with fewer restrictions since it's operating as 'the system' rather than as a specific, limited user.
- Logs or outputs from a background job that get stored or emailed somewhere less protected than the original data, because the job's output wasn't considered as sensitive as the source.
What actually deserves checking here
- Does this job have a broader database key or permission set than it strictly needs for its specific task?
- If there's any way to manually trigger this job, an endpoint, a webhook, a button in an internal tool, does that trigger point have the same auth checks a normal feature would?
- Where does this job's output go, and is that destination protected as carefully as the original source data?
- If this job fails partway through, what state does it leave things in, and could that partial state itself expose something?
None of this is exotic. It's the same underlying question as everything else on this blog, who can trigger this and what can it touch, just applied to a part of the app that doesn't have a URL bar pointed at it and therefore doesn't get thought of as a feature with its own security surface. It has one anyway.