Cloudflare Workers security checklist for AI-built apps

Everything inside the Worker is server-side code, so it may hold secrets and talk to databases through bindings. Everything that reaches it is untrusted: the URL, headers, cookies and body of each request. A Worker has no login screen in front of it unless you add one, so each route is public until your code says otherwise.

Configuration is part of the boundary. Cloudflare's documentation says secrets are environment variables whose values are not visible in Wrangler or the dashboard after you define them, and it says not to use vars to store sensitive information in your Worker's Wrangler configuration file. That file is normally committed to git, so a key placed under vars is published with your code.

If the Worker serves a front end as well, the usual rule applies to that part: anything sent to the browser is public.

Cloudflare documents npx wrangler secret put for adding a secret to a deployed Worker, and .dev.vars or .env files for local development. It says those files should not be committed to git and tells you to add .dev.vars* and .env* to your .gitignore. Run the searches below on your own project, move anything sensitive out of vars, and rotate any credential that was ever committed.

grep -nA12 "vars" wrangler.toml wrangler.jsonc 2>/dev/null
grep -nE "\.dev\.vars|\.env" .gitignore
git ls-files | grep -E "\.dev\.vars|^\.env"
git log --all -p -S"sk_live_" | head -50

npx wrangler secret list
npx wrangler secret put STRIPE_API_KEY

A Worker can answer on a workers.dev subdomain, on preview URLs and on your own domain. Cloudflare's documentation recommends running production Workers on a Workers route or custom domain, not on the workers.dev subdomain, and shows workers_dev = false in the Wrangler configuration file to disable that route. It says preview URLs are available publicly when enabled, that they default to matching your workers_dev setting, and that preview_urls = false turns them off. It also describes using Cloudflare Access to restrict previews.

This matters when protection sits in front of your custom domain, for example rules on your zone, while the same code is reachable directly on another address. Confirm in your own project which addresses respond. If a route is private, it should refuse on all of them because the check is in the code.

workers_dev = false
preview_urls = false

curl -i "https://your-worker.your-subdomain.workers.dev/api/private"
curl -i "https://your-domain.example/api/private"

Read the fetch handler as a list of routes and ask of each one: who may call this, and where does the code check? Generated Workers often verify nothing, or compare a header with a secret using ordinary equality. Cloudflare's best practices recommend crypto.subtle.timingSafeEqual() for comparing secrets, and the Web Crypto API instead of Math.random() for anything security-sensitive such as tokens.

For D1, the documentation says binding parameters with bind() to prepared statements prevents SQL injection attacks. For abuse, Cloudflare provides a rate limiting binding. Its documentation advises against using IP addresses as the key, because many users may share one, and suggests stable identifiers such as user ids. It also describes the limiter as permissive and eventually consistent, not an accurate accounting system, so treat it as protection against floods and keep hard spending caps with your paid providers too.

grep -rnE "prepare\(`.*\$\{|prepare\(.*\+" src

const row = await env.DB
  .prepare("SELECT id, title FROM notes WHERE id = ? AND owner_id = ?")
  .bind(noteId, userId)
  .first()

const { success } = await env.MY_RATE_LIMITER.limit({ key: userId })
if (!success) {
  return new Response("Too many requests", { status: 429 })
}

Cloudflare's best practices explain that Workers reuse isolates across requests, so a variable set during one request is still present during the next. Generated code that stores the current user or a request body in a module-level variable can hand one visitor's data to another. Pass state through function arguments instead.

Check the CORS headers the Worker sends. AI tools often add a wildcard origin to clear a browser error. A wildcard is fine for a truly public, read-only API. It is the wrong answer for routes that use cookies or return private data, where the allowed origin should be your own site.

• Putting an API key under vars in the Wrangler configuration file and committing it.
• Committing .dev.vars because only .env was in .gitignore.
• Protecting the custom domain and forgetting the workers.dev address serves the same code.
• Leaving public preview URLs on for a Worker bound to production data.
• Building SQL with template strings from request input.
• Keeping the current user in a global variable.
• Leaving an AI or email route open with no limit per user.

Re-read the Wrangler configuration file in every change that touches it, and repeat the outside probes after each deploy on every address. Pass condition: no credential in config, source or history, private routes refuse on all addresses, queries use bound parameters, and costly routes return 429 when hammered.