Hey Will,

Thanks for the comment.

You are right about that.
There are two types of secrets you typically deal with.

1. Secrets that your client-side app needs to use when talking to a provider are still visible in the JS bundle or API calls.
These are secrets like your Google API key that needs to be sent in an HTTP request to Google, for example.

For these types of secret usually, you need accompanying security measures. For example, Google lets you limit an API key to a domain or limit it to specific Google services.

Even for this type, it is a good practice not to hardcode in the source, which makes the secret management based on the environment more accessible.
Updating your secret to rotate it can be more challenging once you put it in the code spread across branches and devices.
I did not explain this part too much, and I linked this other article that does a good job.
https://blog.gitguardian.com/secrets-credentials-api-git/

Here is another resource from Google on "Best practices for securely using API keys."

Which suggest not to store API keys in source code.

https://support.google.com/googleapi/answer/6310037?hl=en

Github will send you a warning email if you push your Google API key.

They have this automatic secret scanning going on.

https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning

2. Secrets that are just required as part of the build but not after that.
For example, if my build process can query my content repository(headless cms) to prerender some pages to generate static pages.

In that case, I do not need the content repository's API key after the build is done. I will only take the results (static pages) to deploy them.
So I can genuinely secure my key.

I hope this answer helps 👍