Bubbleのセキュリティについて日本一詳しく解説！基本知識や必ず対策すべき5つの項目を紹介
ノーコードツールBubbleを導入する上で気になる「セキュリティ」の話。「ノーコードはセキュリティに弱いのではないか」という先入観を持つ方は少なくないと思います。
本記事では、そんなBubbleのセキュリティに関して日本一詳しく解説していきます。さらにBubbleを導入する上で、利用者がセキュリティ観点で絶対に対策すべき項目についてもご紹介します。
この記事からわかること
Bubbleのセキュリティについて
・Bubbleの開発プラットフォームとしてのセキュリティ強度
・PaaSを利用する上でのセキュリティ原則
・Bubble利用者が注意すべきセキュリティ対策
また、セキュリティに優れたBubbleアプリを開発したい方には、Bubble特化の開発会社への相談をおすすめしております。
当社Swoooは、国内初のBubble公式開発試験に合格したBubble開発会社です。
技術力だけでなく、特に新規事業の文脈における包括的な支援も得意としております。
- 新規事業を立ち上げたいが、開発に大きな予算はかけられない
- 企画やデザインを含め、ワンストップで支援してくれる開発会社に頼みたい
- 補助金/助成金やWebマーケティングの支援まで包括的にサポートしてほしい
このような方はぜひ一度、当社Swoooにお問い合わせくださいませ。
また、Swoooではアプリ開発費用の即時見積もりツールをご提供しており、効率的にお見積もりを比較できます。こちらもぜひご利用ください。
▼そもそもBubbleとはなにか？を知りたい方はこちらをご覧ください
目次
結論：Bubbleセキュリティの安全性を星5で表すと？
※弊社の社内エンジニアにヒアリングしてまとめた情報になります。
総合的に判断し、Bubble安全性は「★★★★☆（4.0 / 5）」程度と考えております。
Bubble自体のプラットフォーム基盤は、十分な水準のセキュリティ機能を備えているのです。
- HTTPSの強制（通信の暗号化）
- データベース単位でのアクセス制御（Privacy rules）
- 認証・権限管理の仕組み
結論として、「正しく設計すれば十分に安全」といえます。
ただし、満点ではない理由は明確です。
セキュリティの最終的な強度は、開発者の設計に大きく依存するからです。
「Bubbleだから安全」ではなく「安全に設計したから安全」。この前提を忘れないでください。
具体的に、どんなミスが多いんですか？
実際の開発現場でよく見かけるセキュリティ事故のパターンを、優先度順に紹介します。
1位：Privacy rulesの設定漏れ
最も多いミスです。
Bubbleでは、データ型（Type）を作成した時点では「誰でも読める」状態になっています。
Privacy rulesを設定しないまま放置すると、本来見せたくないデータが外部から取得できてしまいます。
2位：Workflowからの意図しないデータ参照
画面上で非表示にしていても安心できません。
Workflow経由でデータを取得・更新できる設計になっていると、UIとは無関係にデータへアクセスされるリスクがあります。
3位：API Connectorの認証情報管理ミス
外部サービスと連携する際のミスです。
APIトークンやシークレットキーを、クライアント側で扱う設計にしてしまうケース。
ブラウザの開発者ツールから認証情報が丸見えになる危険があります。
まずこれだけ｜リリース前セキュリティチェックリスト
Bubbleのセキュリティ設定、どこから手をつければいいかわからない…
Bubbleでの情報漏えいは、発生パターンがある程度決まっています。Privacy rules、API、ファイル、権限設定…この4つが主な原因です。
まずは”致命傷”になりやすいポイントを先に潰しましょう。以下の6項目を確認してから、詳細な対策に進むのが効率的です。
1. Privacy rules：全データタイプに「非公開」ルールがあるか
確認すること：Data typeごとに「誰がどのフィールドを読めるか」が定義されているか。匿名ユーザーに広く公開されていないか。
なぜ重要か：ブラウザに返ったデータは見られる前提です。返す前に制御しないと漏えいにつながります。
確認場所：Data → Privacy（各Data type）
新規Data type追加時は「非公開をデフォルト」にするテンプレートルールを作っておくと安心です。
2. API / Data API：エンドポイントに認可・条件があるか
確認すること：Data APIやAPI workflowを有効化している場合、呼び出し条件や認可が設計されているか。
なぜ重要か：UIで隠しても、APIが”裏口”になってデータを取得・更新されることがあります。
確認場所：Settings → API（Data APIの有効/無効、公開範囲）、Backend workflowsのエンドポイント設定
3. Backend workflows：サーバー側で権限チェックを入れているか
確認すること：重要処理（更新・削除・決済連携など）で「このユーザーが実行して良いか」をWorkflow内で判定しているか。
なぜ重要か：画面側の制御だけでは、想定外の呼び出し経路で処理が実行されるリスクがあります。
確認場所：Backend workflowsの各WFの冒頭条件、Only when、ユーザーの一致チェック
4. ファイル：URLを知れば見える前提で運用しているか
確認すること：アップロードファイルは「URL共有で閲覧され得る」前提で、機密データの取り扱い基準を決めているか。
なぜ重要か：Privacy rulesではファイル自体の閲覧制御ができないケースがあります。
確認場所：File uploaderの保存先・公開運用、該当データフィールド、削除フロー
5. アプリ保護：開発版にパスワード保護がかかっているか
確認すること：Development版（staging相当）にRun-mode passwordを設定し、関係者以外がアクセスできない状態か。
なぜ重要か：開発中は権限設定が甘く、インデックスや共有リンクで露出しやすい状態です。
確認場所：Settings → General（「Limit access to this app with a username and password」）
6. アカウント/共同編集：2FA・権限・招待メンバーが最小化されているか
確認すること：Bubbleアカウントは2FAを有効化し、共同編集者は必要最小限か。退職・外注終了時に即削除しているか。
なぜ重要か：アプリより先に「管理画面を乗っ取られる」と全データが危険にさらされます。
確認場所：Bubbleアカウント設定（2FA）、アプリのCollaborators/権限
このチェックで防げること／防げないこと
防げること：匿名ユーザーによるDB閲覧、API経由の想定外アクセス、開発版の意図しない露出、管理画面乗っ取りの初歩的リスク。
防げないこと：アプリ仕様として公開している情報の漏えい、運用ミス（誤送信など）、外部連携先での漏えい、端末自体の侵害。
まずはこの6項目をクリアしてから、次のセクションで各設定の詳細を確認しましょう。
「自社のBubbleアプリ、セキュリティ設定が不安…」という方は、Swoooの無料相談をご活用ください。Bubble公認エージェンシーのエンジニアが、設定状況をチェックいたします。
【結論】Bubbleのセキュリティは安全！大企業でも安全に利用できる基盤が整っている
最初に、開発プラットフォームとしてのBubbleのセキュリティ性について紹介します。
Bubbleは強固なセキュリティを担保することを非常に重要視しており、これまでさまざまな対策を実施してきています。
ここではその一例として、Bubbleが公式サイト（https://bubble.io/security）で公表しているセキュリティに関する主な実績を4点まとめてご紹介します。
国際的に認められた複数の規格に準拠したセキュリティ基盤が提供されている
Bubbleでは、SOC2、GDPRなどのセキュリティ規格に準拠したプラットフォームが提供されています。
SOC2（Service Organization Control type 2）は、米国公認会計士協会によって定められた、サイバーセキュリティに関するフレームワークです。Bubbleのようなクラウドサービスにおいて、顧客データの保護などのセキュリティ性を評価するために用いられます。
GDPRは（EU一般データ保護規則）は、個人情報の保護や取り扱いについての規則を詳細に定めた、EU各国に適用される法令のことです。
いずれもクラウドサービスのセキュリティ性を担保する指標として国際的に認められた規格であり、これらに準拠したプラットフォームが提供されています。ただし、プラットフォームの準拠と、その上で開発されるアプリのセキュリティは別の話である点に注意が必要です。（参考：Bubble公式Docs – SOC 2 Type II）
世界最大のクラウドサービスAWS上に構築されている
Bubbleは、世界最大のクラウドサービスであるAWS（Amazon Web Service）上に構築されています。
AWSは、システムを構築するためのサーバーやストレージ、ネットワークなどのインフラ整備を提供しているクラウドサービスです。
世界最大のクライドインフラサービスとして、当然ながらAWSも世界トップレベルの強固なセキュリティ対策をとっており、公式サイトでは軍隊や国際銀行などの非常に高い機密性が求められる組織のセキュリティ要件を満たせるように構築されていると明言されています。（引用：AWS公式サイト）
このようなインフラ環境上で構築されていることからも、Bubbleというプラットフォームのセキュリティが強固であることは想像に難くないでしょう。
Cloudflareを用いたセキュリティ保護が標準で採用されている
またBubbleでは、Cloudflareとの統合が標準で採用されています。Cloudflareは広く利用されているCDN（Content Delivery Network）サービスであり、サイトの表示やコンテンツ配信の高速化に寄与しています。
Cloudflareには、WAF（Web Application Firewall）やDDoS（Distributed Denial of Service）保護と呼ばれるセキュリティ対策が備わっています。WAFにより、Webサーバーの前段で通信を解析・分析し、攻撃を遮断することでWebアプリケーションを保護することができます。また、DDoS保護機構により、悪質な同時大量アクセスからサーバーを守り、アプリケーションの実行を維持することができます。
ただし、アプリ固有の情報漏えい（Privacy rulesの設定ミス等）は開発者側の設計に依存するため、別途の対策が必要です。（参考：Bubble公式Docs – Security features）
脆弱性に対する独自の厳しいテストを定期的に実施している
さらにBubbleでは、独自の侵入テストや脆弱性テストを定期的に実施しており、情報漏洩が起こらないための厳しい対策をとっています。
上記のような数多くの厳しいセキュリティ対策の結果、Bubbleのセキュリティ性の高さは広く世界で認められており、スタートアップから大企業まで幅広い組織で利用されています（導入事例は公式の紹介ページやコミュニティ事例を参照）。
以上から、Bubbleのプラットフォームとしてのセキュリティ基盤は、国際的な規格に準拠した水準にあります。
Bubbleのセキュリティは安全だが、利用者の力量に委ねられる部分も大きい
以上からBubbleは、世界的な大企業でも安心して利用することができる、強固なセキュリティ性を持った開発プラットフォームであることがお分かりいただけたと思います。しかし、だからといって、Bubbleで開発されたアプリが全て強固なセキュリティを備えているわけではありません。
Bubbleは他のノーコードツールと比べて、開発の自由度が非常に高いことが特長です。しかしその分、開発したアプリやデータ自体の保護に関しては、使用者側の力量に委ねられている側面が強いのも事実なのです。Bubbleを使う側のセキュリティに対する理解や対策が甘ければ、おのずと完成するプロダクトのセキュリティも脆弱なものとなってしまいます。
Bubbleのセキュリティに対する責任は大きく2つに分かれる｜PaaSのセキュリティの原則を理解しよう
そもそもBubbleのセキュリティと一口で言っても、その責任範囲は大きく二つに分かれています。一方は、当然ながらサービスのプロバイダであるBubble自身、そしてもう一方は、Bubbleを利用する立場である私たちです。つまりセキュリティ性の高いアプリをBubbleで開発・運用するために、利用者である我々はセキュリティ対策をBubbleに求めるだけでなく、自分たち自身でも対策を施す必要があるのです。
これは、Bubbleがクラウドサービスの中でもPaaS（Platform as a Service）というカテゴリに分類されることによります。
PaaSとは、OSやミドルウェア、ハードウェア、ネットワークなど、アプリやゲームの開発・実行に必要な環境（プラットフォーム）をインターネット上で提供するサービスのことです。
プロバイダのセキュリティ責任範囲｜ハードウェア、OSなどのプラットフォームの管理責任を負う
PaaSのプロバイダは、自身が提供しているプラットフォーム全体のセキュリティ保護に関して責任を負っています。
つまりBubbleにおいては、OSやハードウェア、ミドルウェア、ネットワーク等のセキュリティ脆弱性については、プロバイダであるBubble自身が対処する必要があります。
Bubble利用者のセキュリティ責任範囲｜データ、アプリケーションの管理責任を負う
一方でPaaSの利用者は、そのプラットフォームを利用して開発したアプリケーションや、そのアプリ上でやりとりされるデータそのものに対してセキュリティ責任を負っています。例えば、Bubbleアプリのユーザーアカウントに含まれるパスワードやメールアドレスなどの個人情報が漏洩した場合には、その責任はプロバイダではなく、Bubbleを用いてそのアプリを開発した利用者自身が負うことになります。
PaaSのセキュリティに関する原則をご理解いただいた上で、ここからは利用者である我々がBubbleで開発をするときに最低限対策すべきセキュリティ項目について、順にご紹介していきます。
Bubble使用者がチェックすべき5つのセキュリティ対策｜具体例や失敗例とともに安全に導入するコツを紹介！
先述の通りBubbleはその開発自由度の高さゆえに、セキュリティに関して利用者が対策すべき事項も多岐に渡ります。
本記事ではそのうち5つの超基本的なポイントに絞って、私たちがBubbleでの開発を実施する際に注意すべきセキュリティチェック項目を、例とともにご紹介します。
①プライバシールールの設定｜ただ画面上で非表示にするだけでは不十分！
一つ目は、プライバシールールの設定です。
プライバシールールとはBubbleアプリのデータベースに設定できる、データの表示・書き込み制限機能です。
ユーザーのブラウザ（クライアント）に渡ったデータは、開発者ツール等で確認できる前提で設計する必要があります。そのため、重要なのは「そもそも閲覧権限のないデータをクライアントへ返さない」ことで、BubbleではPrivacy rulesがその中心になります。
特定のユーザーにしか表示させたくない情報があったとき（例えば本人の生年月日や氏名、住所などの個人情報は、そのユーザー自身とシステム管理者権限を持ったアカウントしかアクセスできないようにしたい）、ページ上の要素を隠すだけでは不十分なのです。この状態でも、要素とその中身はコード情報としてクライアント側に存在しており、開発に精通した人間が開発者ツールなどで確認すれば、一瞬で機密情報を抜き出すことができてしまいます。
プライバシールールを設定することで、サーバーからデータを呼び出す前にそのユーザーの権限を確認して、条件をクリアしたユーザーからのリクエストのみを許可し、クライアント側にデータを読み込むことができるようになります。
プライバシールールの設定漏れは、発生頻度が最も多いセキュリティ対策ミスの一つです。
- 取引先や請求に関する情報にプライバシールールが適用されておらず、脆弱なセキュリティのままアプリが公開がされていた
- 月額課金制のアプリにおいて、課金が完了していないユーザーでも有料コンテンツの中身が閲覧できるような設定になっていた
このような失敗事例は、挙げればキリがありません。
Bubbleでは、ユーザーデータのうちメールアドレスとパスワードについてはデフォルトでプライバシールールが設けられていますが、その他のデータに関しては一切のプライバシールールが設定されていません。データの保護についてはほぼ完全に利用者（開発者）に委ねられているため、重大な情報漏洩が起きてしまう前に、必ずプライバシールールの確認・設定をしておきましょう。
②クライアント側での通信の確認｜重要な処理は必ずサーバー側で実行しよう
また、セキュリティ上重要なロジック処理については、サーバー側で実行する必要があることにも注意しましょう。
先述の通り、クライアント側に渡ったデータは開発者ツール等で確認できます。つまり、ユーザーが簡単にデータを改竄できてしまう状態にあります。
例えばメール送信機能や、決済金額に応じたポイント付与などの処理をクライアント側で組むと、メールの送り先や送信内容に含まれる個人情報が簡単に抜き出せてしまったり、本来の条件とは異なるポイント付与をユーザー側で勝手に実行できてしまうことになります。
こういった処理をサーバー側で実行する（BubbleではAPI Workflow、Backend Workflowと呼びます）ように組むことで、よりセキュリティの高い処理を実現できます。なお、Backend Workflowでもデータの認可条件（誰がそのワークフローを実行できるか）を適切に設定する必要があります。
③アクセス制限の実施｜開発したアプリやアカウントを適切に保護しよう
さらに、不正アクセスへの対策も漏れなく実施することが重要です。
例えば、ページのアクセス権限の設定です。システム管理者権限を持つアカウント専用のページに一般ユーザーが入ってきたら、一般ユーザー向け画面にリダイレクトさせるなどの対策は、あまりに基本的であるが故にチェックが甘くなりがちでもあります。
また、開発環境やBubbleアカウント自体の保護も必要になります。
開発版（Development / custom version）は「Limit access to this app with a username and password（Run-mode password protection）」で保護できます。必要に応じて「Do not apply password for live」を使い、開発版だけに適用する運用も可能です。（参考：Bubble公式Docs – General settings）
加えて、Bubbleアカウントに以下のようなセキュリティ対策を設定しておくことで、アカウント内部の個人情報やアプリへの攻撃・データ改ざんから保護することができます。
- 安全な（推測されにくい）パスワードを使用する
- 設定したパスワードは、パスワードマネージャーアプリ上で管理しておく
- アカウントログイン時に、Google Authenticatorなどを用いた2段階認証を求めるようにする（参考：Bubble公式Docs – Account security）
④機密データの処理方法の確認｜DB上から削除してもサーバーには残っているかも…！？
その他、個人情報が含まれる電子ファイルや、社会保障番号などの機密情報の取り扱いにも注意が必要です。
Bubbleのファイル保存に関しては、以下の仕様を理解しておく必要があります。
- File uploader等で保存されたファイルは、URLを知っている人がアクセスできる前提であり、Privacy rulesでは保護できない
- データベースのフィールドからファイルを消しても、ファイル自体はサーバーに残る可能性がある（必要なら別途削除運用が必要）
こういった機密情報をサーバーに保持し続けることはセキュリティ上リスクが高いため、細心の注意を払うべきです。（参考：Bubble公式Docs – Files）
機密ファイル（本人確認書類・医療/金融情報など）については、以下の対策を検討してください。
- Bubble標準ストレージに置かない判断基準を設ける
- 置く場合の最低限：URL共有リスク、保存期間、削除フロー（運用）を決める
- 可能であれば外部ストレージ/署名付きURL/アクセス制御つきの仕組みを検討する
また、社会保障番号などの機密情報には、より強固なセキュリティ対策が必要です。プライバシールールの設定やサーバーサイドでの処理実行だけでなく、データベース上にも暗号化した状態で保存させることが望ましいでしょう。
さらに言えばこのような機密情報は、専用の外部プラットフォームとBubbleアプリを連携させた上で管理する体制をとることが理想的です。
例えばクレジットカード番号については、暗号化した状態であってもデータベースに保存することは適していません。Stripeなどの安全性・信頼性の高い決済プラットフォームと連携して、Bubbleアプリ側では保管しないようにしてください。
⑤セキュリティチェックの実施｜定期的な点検で抜け漏れを防ごう
最後に重要なのが、セキュリティチェックを定期的に実施することです。
これまでに述べたようなセキュリティ対策は、要件定義や設計の段階からドキュメントとして落とし込んでチーム全体で仕様を共有した上で、リリース前にも厳格なセキュリティ監査を実施することが必要です。
Bubble公式では、セキュリティ設定の確認に役立つドキュメントやチェックリストが提供されています。リリース前やアップデート時には、これらを参照して設定ミスがないか確認することをおすすめします。（参考：Bubble公式Docs – Security features）
また、外部のセキュリティ監査サービスを活用することも有効です。Fluskなど、Bubble専用のセキュリティチェックツールを導入することで、マンパワーだけでは見落としがちな脆弱性を検出できます。
以下のようなダッシュボード画面で、検知したデータ漏洩などの脆弱性を一覧で確認・管理することが可能です。
当社Swoooは、Fluskから認められた日本唯一のFlusk agencyでもあります。パフォーマンスはもちろんのこと、セキュリティまで盤石のBubble開発を行っています。
Bubbleのセキュリティ対策にお困りの方は、ぜひ一度即時見積もりサービスから当社にご相談ください。
【大企業向け補足】Enterpriseプランで、より強固なセキュリティ基盤を利用できる
Bubbleの導入を検討されている大企業の方は、Enterpriseプランを利用することもおすすめです。
データ保管リージョンや専用環境が要件になる場合は、EnterpriseのDedicated instance（専用インフラ）を検討します。Dedicated instanceでは選択可能なリージョンが公式に案内されているため、契約前に要件（データ所在地・監査・SSO等）と照合してください。（参考：Bubble公式Docs – Dedicated instance regions）
月額費用がかなり高額になるため、中小規模以下の企業で利用することはあまり現実的ではありませんが、より高いレベルのセキュリティ・コンプライアンスを求める大企業にとっては、Enterpriseプランは積極的に導入を検討すべきメリットがあると言えるでしょう。
▼Bubbleの料金体系に関してもっと詳しく知りたい方はこちら
盤石なセキュリティのもとでBubbleを導入するなら、Bubble特化の開発会社の利用がおすすめ
Bubbleのセキュリティ対策についてご紹介してきましたが、他にも注意すべき事項は多岐に渡ります。ノーコードツールと言えど、開発経験が十分なエンジニア・組織でないと、これらを漏れなく実行することは非常に困難です。
盤石なセキュリティ対策のもとでBubbleを導入するためには、Bubbleの活用に特化した開発会社を利用することをおすすめしております。
当社Swoooは、国内初のBubble公式開発試験に合格したBubble開発会社です。
また、Bubble専用のセキュリティチェックツール「Flusk」に認められた国内唯一のFlusk agencyでもあり、国内トップレベルの確かなBubble開発力を有しています。
技術力だけでなく、特に新規事業開発の文脈において、企画・営業・マーケティング・KAIZENまで含めた包括的な支援も強みとしております。
- 新規事業を立ち上げたいが、開発に大きな予算はかけられない
- 企画やデザインを含め、ワンストップで支援してくれる開発会社に頼みたい
- 補助金/助成金やWebマーケティングの支援まで包括的にサポートしてほしい
このようなお客様はぜひBubbleの導入をご検討の上、当社の即時見積もりツールで開発費用をお確かめください。
最終更新日：2025年1月
参考：Bubble公式ドキュメント
