Base44のセキュリティは安全？脆弱性の経緯・公式の対策・自分でできる設定まで解説
Base44のセキュリティは大丈夫？
日本語の指示だけでWebアプリを作れるバイブコーディングツールとして人気が高まっているBase44。しかし、いざ業務で使おうとすると、セキュリティ面が気になる方も多いでしょう。
こんにちは、シントビ管理人のなかむーです。
実際に、2025年にはセキュリティ研究者によって脆弱性が発見・報告されたこともありました。一方で、Base44（親会社Wix）は国際的なセキュリティ認証を取得しており、プラットフォーム側の対策も着実に進んでいます。
今回も文系目線でわかりやすく解説していきます。
この記事を読むことで以下のことがわかります。
- Base44のセキュリティ体制
- やるべきセキュリティ設定
安心してBase44を利用するためにも、最後までぜひご覧ください。
なお、Base44についてまずは概要を確認したい方は、「Base44とは？AIでアプリを作れる“バイブコーディングツール”を徹底解説」の記事も参考にしてください。
\ Base44のセキュリティ機能は無料プランでも確認できます /
Base44のセキュリティ基盤
まず押さえておきたいのは、Base44がプラットフォームとしてどのようなセキュリティ対策を講じているかという点です。個人や小規模チームが使うツールとはいえ、企業利用にも耐えうる基盤が整っています。
SOC 2 Type IIとISO 27001を取得済み
Base44は、情報セキュリティの国際的な認証である「SOC 2 Type II」と「ISO 27001」を取得しています。
SOC 2 Type IIは、データの保護やシステムの安全性を第三者が監査する仕組みで、一定期間にわたって運用が適切に行われているかを確認するものです。
ISO 27001は、情報セキュリティの管理体制が国際基準を満たしていることを証明する認証です。
これらは「自称セキュリティ対策」ではなく、外部の専門機関による審査を通過している点が重要です。なお、SOC 2レポートの詳細はNDA（秘密保持契約）のもとで公開されており、Base44のTrust Centerから請求できます。
セキュリティの専門家以外は良くわからないと思いますので、「信頼できる第三者機関からお墨付きを得ている」という風に思ってください。
データの暗号化とサーバーの保管場所
Base44のインフラでは、データの暗号化が標準で適用されています。通信中のデータはもちろん、保管中のデータについても業界標準の暗号化技術が使われています。
サーバーの所在地についても把握しておきましょう。現時点では、Base44のサーバーはすべてアメリカ合衆国内に設置されています。日本国内やその他の地域にデータを保管するオプションは、今のところ提供されていません。
法律や社内規定でデータの保管場所に制約がある場合は、この点を事前に確認しておく必要があります。Base44はGDPRにも準拠しており、EUの個人データ保護基準を満たす取り組みも行われています。
アプリに保存されたユーザーデータはどう守られるのか
SaaSアプリを開発して、ユーザーが個人情報や業務データを入力するケースでは、「そのデータは誰が見られるのか」が最も気になるポイントでしょう。
Base44では、アプリのデータベースに対して「RLS（Row Level Security：行レベルセキュリティ）」という仕組みが用意されています。これは、データベースの各行（レコード）に対して「誰が読めるか」「誰が書き込めるか」を細かく制御できる機能です。この設定を適切に行えば、あるユーザーが別のユーザーのデータを見てしまう、といった事故を防げます（具体的な設定方法は後述します）。
また、アプリの所有権はアプリを作成した本人に帰属するとBase44の利用規約で明記されています。Base44側がアプリの所有者の意志に反してアクセス権を付与することはありません。
「自分の作成したアプリの顧客情報が他人から見られてしまわないか」という懸念には、このデータベースの権限制御で対処可能です。
エンタープライズ向けのSSO・IP制限機能
より高いセキュリティが必要な組織向けに、Base44はエンタープライズ機能も提供しています。
「SSO（シングルサインオン）」は、SAMLやOAuthといった標準的なプロトコルに対応しており、社内で使っているIDプロバイダー（Google WorkspaceやOktaなど）と連携できます。これにより、アプリごとに別々のパスワードを管理する手間がなくなり、不正アクセスのリスクも下がります。
「IP許可リスト」機能を使えば、特定のIPアドレスからのみワークスペースやアプリにアクセスできるよう制限することも可能です。オフィスのネットワークからのみ接続を許可する、といった設定ができます。
これらの機能はエンタープライズプラン以上で利用可能です。
過去に見つかった脆弱性と対応の経緯
Base44のセキュリティを評価するうえで、過去に報告された脆弱性とその対応についても知っておくことが大切です。
2025年7月｜Wiz Researchが発見した認証バイパスの問題
2025年7月、クラウドセキュリティ企業Wiz Researchが、Base44に重大な脆弱性を発見しました。
この脆弱性は、Base44のAPIエンドポイント（ユーザー登録用とワンタイムパスワード検証用）が認証なしでアクセスできる状態になっていたというものです。攻撃者はアプリのIDさえわかれば、本来アクセスできないプライベートアプリにもユーザー登録を行い、SSO設定を回避してログインできてしまう状態でした。
Wiz Researchが7月9日に報告したところ、親会社のWixは24時間以内に修正パッチを適用しました。Wixの調査では、この脆弱性が悪用された形跡は確認されていません。
2025年3月｜Impervaが報告したXSS等の複数の脆弱性
2025年3月には、セキュリティ企業Impervaの研究者がBase44に複数の脆弱性を報告しています。
報告された問題には、アクセストークンが漏洩するオープンリダイレクト、保存型のクロスサイトスクリプティング（XSS）、安全でない認証設計、データの漏洩リスクなどが含まれていました。
これらの脆弱性についても、Base44は報告を受けて速やかに修正対応を行っています。
脆弱性はすべて修正済み｜現在のステータス
上記の脆弱性はいずれも修正が完了しており、ユーザー側で特別な対応は必要ありません。
ただし、こうした事例は「バイブコーディングプラットフォームを業務で使う際にはセキュリティ情報をウォッチしておくべき」という教訓を示しています。Base44のセキュリティページやWizのブログなどを定期的に確認しておくと安心です。
\ Base44はクレカ不要・無料でアカウント作成可能 /
バイブコーディング特有のセキュリティリスクとは
Base44に限らず、バイブコーディングツール全般に共通するセキュリティ上の注意点も理解しておきましょう。
プラットフォーム共有型のリスクを理解する
Base44のようなバイブコーディングツールでは、多数のユーザーが同じインフラ上でアプリを構築・運用しています。これは「マルチテナント型」と呼ばれる構造で、クラウドサービスでは一般的です。
この構造のメリットは、インフラの管理をプラットフォーム側に任せられることです。サーバーの設定やセキュリティパッチの適用を自分で行う必要がありません。
一方で、プラットフォーム側に脆弱性が見つかった場合、その影響がすべてのアプリに及ぶ可能性があるというリスクがあります。2025年7月のWiz Researchの報告はまさにこのケースでした。
自前のサーバーを管理するリスクとプラットフォームに依存するリスク、どちらが自分の状況に合っているかを判断したうえで利用することが重要です。
個人開発者や小〜中規模企業の場合には、トータルでこのマルチテナント型の方が向いています。自社でセキュリティチームを用意できる場合には、自前で用意した方がよいかもしれません。
AIが生成したコードのチェックが甘くなりやすい
バイブコーディングでは、AIが自然言語の指示からコードを自動生成します。この手軽さが魅力ですが、セキュリティの観点では注意が必要です。
従来の開発では、コードレビューやセキュリティテストを経て本番環境にデプロイするのが一般的でした。しかしバイブコーディングでは、ノーコードで手軽にアプリを作れるぶん、生成されたコードの中身を確認する工程が省略されがちです。
たとえば、AIがAPIキーをフロントエンドのコードに直接書き込んでしまったり、データベースのアクセス制御が十分に設定されないまま公開されたりするケースが起こり得ます。
Base44にはこうした問題を検出するSecurity Scan機能が用意されているため、後述する設定を活用して自分のアプリを守ることが大切です。
Claude Codeなどで自身でアプリを作れるようになりましたね。あくまで個人利用の範疇では
Base44でまずやるべきセキュリティ設定3つ
プラットフォーム側の対策に加えて、アプリ開発者自身が行うべき設定があります。Base44には初心者でも扱いやすいセキュリティ機能が揃っているので、優先度の高いものから順に確認していきましょう。
アプリの公開範囲と認証設定
最初に確認したいのは、アプリ全体の公開範囲（Visibility）です。ダッシュボードの「概要」から設定できます。
Base44では以下の3段階から選択できます。
- Private（非公開）：招待されたユーザーだけがアクセスできる
- Workspace（ワークスペース内）：同じワークスペースのメンバーだけがアクセスできる
- Public（公開）：リンクを知っている人は誰でもアクセスできる
セキュリティの基本原則は「最小権限の原則」、つまり必要最低限のアクセス権だけを付与することです。開発中のアプリや社内ツールはPrivateに設定し、公開するアプリでも「ログインを必須にする」オプションを有効にしておくと安全です。
特にユーザーが個人情報を入力するアプリでは、ログイン必須の設定にしたうえで、RLSやFLSを組み合わせてデータ保護を徹底しましょう。
RLS（行レベルセキュリティ）でデータアクセスを制限
RLSは、Base44でアプリのデータを守るために最も重要な設定の一つです。RLSは、「データ」メニューから各エンティティの「権限」画面にて設定します。
各エンティティ（テーブル）をクリックすると権限画面が開き、「作成」「読み取り」「更新」「削除」の4つのタブごとにアクセスルールを設定できます。
選択できるルールは主に以下の4種類です。
- 制限なし：すべてのユーザーがレコードにアクセス可能（デフォルト）
- 作成者のみ：ユーザーは自分が作成したレコードだけにアクセスできる
- エンティティ-ユーザーフィールド比較：エンティティのフィールドとユーザー情報を比較してアクセスを制御する
- User Property Check：ユーザーのプロパティが特定の値と一致するかをチェックする
複数のルールを追加することもでき、その場合はOR条件（いずれかに該当すればアクセス可能）で結合されます。
たとえばタスク管理アプリなら、「読み取り」と「更新」を「作成者のみ」に設定すれば、各ユーザーが自分のタスクだけを閲覧・編集できるようになります。ECサイトなら、商品テーブルの「読み取り」は「制限なし」にしつつ、購入履歴テーブルは「作成者のみ」にする、といった使い分けが効果的です。
設定タイミングとしては、AIチャットでアプリを生成した段階で権限が自動設定されている場合もありますが、必ず手動で確認しましょう。アプリを公開する前、そしてデータエンティティを追加・変更したタイミングで見直すのが安全です。
RLSを設定していないと、すべてのデータが全ユーザーから見えてしまう可能性があります。特にユーザーデータを扱うSaaSアプリでは、最優先で設定してください。
FLS（フィールドレベルセキュリティ）で項目単位の閲覧を制御
RLSが「行（レコード）単位」のアクセス制御であるのに対し、FLS（フィールドレベルセキュリティ）は「列（項目）単位」の制御です。
たとえば、社員名簿アプリで「名前と部署は全員が見られるが、給与情報は人事担当者だけが見られる」といった設定をしたい場合にFLSが役立ちます。
同じテーブル内に公開してよい情報と非公開の情報が混在している場合は、RLSだけでなくFLSも組み合わせて使うことで、より細かいデータ保護が実現できます。
設定後に押さえておきたいセキュリティ運用のポイント
セキュリティ設定は一度行えば終わりではありません。アプリを更新・運用していくなかで、定期的にチェックすべきポイントがあります。
Security Scan（セキュリティスキャン）を定期的に実行する
Base44には「Security Scan（セキュリティスキャン）」という組み込みのセキュリティチェック機能があります。
スキャンでは以下のような問題を自動的に検出してくれます。
- APIキーやトークンなどの秘密情報がフロントエンドのコードに含まれていないか
- RLS（行レベルセキュリティ）の設定に漏れや不備がないか
- 認証が設定されていないバックエンド処理がないか
セキュリティスキャンは、ダッシュボードの「セキュリティ」にて、「セキュリティを確認」をクリックすると実行されます。
セキュリティスキャンを実施して問題があると、以下の画像のように問題の箇所が表示されます。「修正」をクリックすると、すげに修正が行われます。
検出された問題には、わかりやすい説明と改善案が表示されるため、セキュリティの専門知識がなくても対応できます。アプリの機能を更新したら、そのつどスキャンを実行する習慣をつけるとよいでしょう。
また、外部ツールのSafeVibesを使えば、アプリを外部から見たときにどのデータが露出しているかを確認することもできます。
APIキーや秘密情報をフロントエンドに書かない
外部サービスと連携する際に使うAPIキーやトークンなどの秘密情報は、絶対にフロントエンド（ユーザーのブラウザで見える部分）のコードに記述してはいけません。フロントエンドに書かれた情報は、ブラウザの開発者ツールなどから誰でも確認できてしまいます。
Base44では、秘密情報をバックエンド関数（サーバー側で実行される処理）内で管理する仕組みが用意されています。また、エンタープライズプランではワークスペースシークレット機能を使って、チーム全体で安全に秘密情報を共有することもできます。
Security Scanを実行すると、フロントエンドに露出している秘密情報が自動検出されるので、定期的にチェックしましょう。
\ アプリを作り、Security Scanでチェックしてみよう /
まずはセキュリティスキャンから始めよう
Base44は、SOC 2 Type IIやISO 27001の認証取得、データ暗号化、RLSやSecurity Scanなどの組み込み機能により、プラットフォームとしてのセキュリティ基盤は整っています。
一方で、2025年に脆弱性が報告された事実は、バイブコーディングツール全般に共通する「プラットフォーム依存型のリスク」を改めて示しました。いずれも迅速に修正されましたが、セキュリティは一度整えたら終わりではなく、継続的に注意を払うべきものです。
今すぐできることとして、まずは自分のアプリでSecurity Scanを実行してみてください。RLSの設定漏れや秘密情報の露出がないかをチェックするだけでも、セキュリティレベルは大きく変わります。
プラットフォーム側の対策を信頼しつつ、開発者として自分のアプリも自分で守る。この両面からの取り組みが、Base44で安全なアプリを運用するために必要です。
Base44のセキュリティレベルを確認できたけど、「もっとよく知りたい」という方は、「Base44を選ぶ前に知っておきたいこと｜特徴・強み・向いている人を正直にまとめた」の記事も参考にしてください。
最後までお読みいただき、ありがとうございました！！
