Boltで作ったアプリを、実際の利用者を迎えられる状態に

よくある問題

何で作ったかにかかわらず、レビューが追いつかない速さで育ったアプリによく見られる問題です。ほとんどは、今の環境のまま直せます。

1. ブラウザ向けのコードに入ったキー

   ViteプロジェクトのVITE_のように、ブラウザ向けの接頭辞がついた環境変数は、訪問者全員がダウンロードするJavaScriptに書き込まれます。そこに置いてよいのは公開用のキーだけで、秘密のキーはサーバーに置きます。

2. データベースのルール

   アプリがブラウザから直接Supabaseなどのデータベースにつながる場合、ある利用者のデータを別の利用者から守るのは、データベース自身のアクセスルールだけです。ルールが存在し、しかも正しい必要があります。

3. 画面の上だけで行うチェック

   画面で行う入力チェック、上限、権限は、APIを直接呼び出せば回避できます。データを変更する場所でも、同じチェックを行う必要があります。

4. 依存関係

   生成されたプロジェクトは、その日に最新だったバージョンのまま固定され、使わないパッケージが入っていることもあります。そのままにしておくと、そこがアプリの古く脆弱な部分になります。

5. 元に戻せないデプロイ

   エディタから直接デプロイできるのは手軽です。本番ではそれに加えて、変更を試す別の環境、元に戻す手段、障害が起きたときのアラートが必要です。

6. 変更しにくいコード

   生成された大きなファイルや繰り返されたロジックは、その後の変更を遅く、危うくします。早めに少し構造を整えておけば、後の作り直しを避けられます。

Boltアプリで監査が確認すること

コード・プロダクト監査では、外から見える部分だけでなくコードそのものを読み、すべての指摘を事業への影響で順位づけします。Boltアプリの場合は、次の点を確認します。

• 配信されるバンドルと環境変数に含まれる、すべてのキーとシークレット。
• データベースのアクセスルール。誰が何を見るべきかと照らし合わせて確認します。
• データを変更するすべてのルートに、サーバー側のチェックがあるか。
• 依存関係。使われているもの、古くなっているもの、既知の脆弱性があるもの。
• ホスティング、環境、デプロイ、ロールバック。
• コードの構造と、この先の変更でコストがかかりそうな箇所。
• プロダクトと事業の目標。お話をうかがい、すべての指摘を事業にとっての意味で順位づけします。

公開中のアプリを1日で確認する、固定価格のローンチチェックもご用意しています。認証、RLS（行レベルセキュリティ）とデータアクセス、シークレットを確認し、リスクの大きいものから5件を30分のお打ち合わせでご説明します。 ローンチチェックについて

今の環境のまま、本番で通用する状態へ

基本のご提案は、今のアプリのまま堅牢にすることです。別の技術スタックへの移行は、監査でその費用に見合うとわかった場合にだけご提案します。

Boltアプリを、まず無料チェックで

無料チェックは、配信されているJavaScriptに含まれるキー、ヘッダー、HTTPS、バージョンなど、アプリがすでに外に見せているものをスキャンし、2営業日以内にAaronが結果を確認します。メールでのご確認と、アプリの所有者であることの確認が済んでから実行します。