Is it safe to publish wrangler.toml with account id + zone id?


I’m having a hard time finding out whether or not Account ID and Zone ID are sensitive information. These exist in wrangler.toml and I want to publish to a public git repository. I’m not sure if I should be ignoring this file, or providing these two settings in a different manner. I know my user name + API key are sensitive and are stored in the global configuration & use environment variables in CI.

Private repository: Account ID and Zone ID are fine, as long as username + API Keys are not there.

Public repository: Account ID and Zone ID should be “anonymised” so that you don’t have someone impersonating you.

For public repos, i’d recommend having wrangler.toml within your .gitignore and a wrangler.toml.example file that has all of the configuration required without any identifying information. Your readme would then instruct users to copy wrangler.toml.example to wrangler.toml and to fill out relevant fields before running any wrangler commands.

1 Like

And just to be clear. IF you’ve ever checked in sensitive info into a git repository, do NOT make that repo public. git rm wrangler.toml; git commit -s -v is not sufficient. It’s extremely difficult to forensically scrub sensitive data from git history. Which is a good thing ™ if you’re ever concerned about accidentally deleting something. Git will save you 99% of the time.

Unfortunately, the propensity for data retention is your enemy with sensitive data. It’s honestly easiest, and fails safe, to just tar up a release of the infected repo[0], and untar into a new, empty repo.

If you’re interested in understanding what makes git so sticky with your data, I recommend reading Git from the Bottom Up. In short, as long as anything references the blob which contains the sensitive information, that data still exists in the history. So, if you checked in the sensitive file in the first commit, you would have to rewrite that commit, and every commit since to remove the reference to the sensitive file. Which will mess up all of your git tags, and that’s just for your main development branch. You’d also have to delete the tags, and make sure you track any time you renamed the file and catch those too. Running git gc --prune=now --force Still won’t put you in the clear. There’s references to that damn blob in .git/logs/* So you’ve got to scrub that as well. And don’t forget any time you’ve stashed your work.

So yeah, just don’t post that publicly. Use a clean repo for that task.

/me just had bad flashbacks of scrubbing repos so we could retain the history without the devil-blob :face_with_symbols_over_mouth:.



[0] Without the sensitive data, of course :stuck_out_tongue:

There’s now the possibility to create tokens that access workers only.

You don’t even need to worry about tar, you can just remove the .git folder and re-setup git.

However if your repo is public in theory you’ll still be able to access the orphaned branch when someone pulls it down, so I believe you need to delete the repo on say github and recreate it to get a fresh history.

How would someone impersonate me with this information? Wouldn’t they need Username + API key/token to do that? Or are we talking about social engineering the support team by using those 2 attributes?

More towards this “Or are we talking about social engineering the support team by using those 2 attributes”.

1 Like

I really hope social engineering is not a possibility… If so, CF should at least have procedures that verify second-factor code to verify the person is who he says he is.

Being cautious is an important approach, for sure Cloudflare :orange: has procedures. It is just a bad practice to disclose that data publicly. Social engineering is always developing new vectors.

True that :slight_smile:

Hmm, yes. I wasn’t clear. I was referring specifically to git archive since it automagically excludes files within the source tree that match .gitignore.