Base44

Base44アプリに誰が入れて、何が見えるのかを確かめる

Base44は、アプリとデータとサインインをまとめて作ります。それが速さの理由です。その一方で、誰がデータを見られるかはほとんどアクセス設定で決まり、その設定は作り始めた日のまま残されがちです。

よくある問題

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

  1. プラットフォームと、所有者が管理する層

    プラットフォームそのものの欠陥は、プラットフォームが直すものです。アプリの所有者が管理するのは、その上の層、つまりアクセス設定、データのルール、アプリが動かすコードです。監査で確認するのはこの層です。

    Base44では、プラットフォームそのものに認証を回避できる脆弱性が見つかったことがあります。 The Hacker News(英語)

  2. 誰でもサインアップできるアプリ

    社内ツールやお客様向けのポータルが誰でもサインアップできる状態だと、新しいアカウントはどれも、サインインした利用者に見えるものをすべて見られます。

  3. どの利用者でも読めるレコード

    サインインしているかどうかだけを確認し、どのレコードが本人のものかを確認しないデータのルールでは、あるお客様が別のお客様のデータを見られてしまいます。

  4. 外部サービスのキー

    決済、メール、AIサービスとの連携に使うキーは、サーバー側に置く必要があります。ブラウザから読めるコードや設定に置いてはいけません。

  5. プロンプトによる変更

    プロンプトで変更するたびに、新しいコードが生まれます。レビューと、重要な流れを試す手段がなければ、ある場所の修正が別の場所にすき間を作ることがあります。

    Veracodeの調査では、AIによるコード生成タスクの45%で脆弱性が入り込み、モデルが進歩してもセキュリティ面の成績は「時間がたっても変わっていない」とされています。 Veracode、BusinessWire経由(英語)

  6. 入り口がひとつしかない、業務に欠かせないツール

    社内ツールが業務に欠かせなくなったら、オーナーのアカウントを複数にし、データを書き出せるようにし、問題が起きたときの計画を持っておく必要があります。

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

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

  • アプリのアクセス設定。誰がサインアップでき、誰がサインインでき、ロールごとに何が見えるか。
  • あらゆる種類のレコードのデータのルール。誰が何を見るべきかと照らし合わせて確認します。
  • 外部サービスとの連携と、そのキーの置き場所。
  • バックエンドの関数と、ブラウザから受け取るものをどこまで信用しているか。
  • オーナー権限、データの書き出し、復旧。アカウントを失ったときやデータが消えたときにどうなるか。
  • プロダクトと事業の目標。お話をうかがい、すべての指摘を事業にとっての意味で順位づけします。

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

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

基本のご提案は、Base44のまま本番の運用に耐えられるようにすることです。Base44からの移行は、監査でその費用に見合うとわかった場合にだけご提案します。

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

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