よく環境変数を仕込んだり、Nuxt.js 界隈だと privateRuntimeConfig （publicRuntimeConfig – サーバーサイドからしか参照できない環境変数とフロントエンドしか参照できない環境変数という意味を理解していない）に仕込んだりとかブログに書いている人がいるが、それはサーバーサイドでやる前提であり、SPA や SSG でフロントエンドの JavaScript から参照する場合には、必ずソースコード中に含まれているか、DeveloperTools の変数参照やネットワークのリクエストを見ることで確認できてしまうということがわかっていない人が多く感じる。
※これは素のCSSが書けない人が増えてきているのと同様に、応用技術を早く覚えすぎたあまり、基礎がなっていないからだと思ってしまう
これを解決はたったひとつで、必ずサーバーサイドのプログラムを用意する必要がある。
例えば、microCMS POST API にも書かれているように、X-WRITE-API-KEYのリクエストヘッダー（POST、PUT、PATCH、DELETE API リクエストに必要な認証キーを設定するヘッダー）を使う場合には、
API-KEY / WRITE-API-KEYはサービス内の全API共通となります。
そのため、クライアントサイドから直接APIを呼び出すことでユーザーがキーを把握できてしまう場合、エンドポイントさえ分かれば他のAPIも呼び出せてしまうことにご注意ください。
対処法としては、サーバサイドからAPIを呼び出す、またはJamstack構成にするなどしてキーを漏洩しないことが挙げられます。
https://document.microcms.io/content-api/post-content
とあるように、サーバーサイドでAPIキーを呼び出すようにする。
※この場合のJamstack構成というのは、意図しないサーバーサイドプログラムが実行されないからという意味であり、webpack で逐次的にチャンクデータにビルドされるからといって、JavaScript 中にそのまま埋め込んでいいということではない。
具体的な解決方法としては API キーをサーバーサイドプログラムでラップしAPIリクエストする方法である。
特定のCROSの制限をかける、あるいはIP制限、WPだとnonceを発行するなどして、特定の環境下のリクエストのみを受け付けるエンドポイントを用意し、そのエンドポイントでフロントエンドのリクエストにAPIキーを追加しAPIをリクエストするような処理にする（reCaptchaもパブリックキーとシークレットキーがあるのはそういう理由）。
最悪制限がかけられない場合でも、環境変数に書いたり、一度Ajaxで取得するなどソースコードに書かないことで、Githubに誤って上げてしまい700万円を請求されるなんてことがなくなるため、そのようなリテラシーをもってAPIキーを管理して欲しいものだ。