このビデオは、女性向けデーティングアプリTEAで発生した大規模なデータ漏洩事件について詳細に分析している。ハッカーがFirebaseの公開バケットから数十万件のユーザーの顔写真や身分証明書などの個人情報にアクセスした経緯を解説し、これがいわゆる「バイブコーディング」による問題ではなく、Firebaseの根本的な設計思想とモバイル開発者のサーバー知識不足が原因であることを論じている。データベースを直接APIとして使用する危険性と、適切なサーバー設計の重要性について警告を発している。
TEAハッキング事件の概要
TEAのハッキングは完全に悪夢やで。もしまだ追いかけてへんかったら、これは今一番大きなニュースの一つや。TEAっていうのは女性が今まで付き合った男性についての情報を共有するアプリなんや。これについてどう思うかの詳細には入りたくないわ。みんなそれぞれ意見があるやろうしな。
今日話したいのは、彼らに起こったとんでもないハッキングについてや。そうや、俺はこれをハッキングって呼んでる。反対する人もおるやろうけど、その人らは間違ってる。ここで何が起こってるか詳しく説明していくで。正直、この件はカバーしたくなかったんや。セキュリティ関連のことを上手にやってるYouTuberは他にもぎょうさんおるからな。
でも調べれば調べるほど、これは従来のセキュリティ問題や脆弱性とは違うってことがわかってきた。これは悪い設計判断が原因で、とんでもない量のデータが漏洩することになった、俺が確実にハッキングやと考えるものや。もう一つのホットテイクは、これは全然バイブコーディングのせいじゃないってことや。
多くの人がそう思ってるみたいやけど、違う。それを証明する資料をたくさん持ってる。創設者がブートキャンプ卒業生で、その時に学んだことしか知らず、それ以来あまり学んでないっていう経歴も含めて、裏で動いてる技術についてもな。ネタバレやけど、Firebaseはここで掘り下げるのがめっちゃ面白いで。
他の人がこれをカバーしてるのを見て、あんまり気に入らんかった。だから俺らが詳細に入って、なんでこういうセキュリティ問題が起こるかの合理的な分析をするのがベストやと思うんや。とはいえ、これは時間の無駄遣いやったし、生活費も稼がなあかん。だから今日のスポンサーから一言もらって、そのあと本題に入るで。
スポンサー紹介とアプリ開発の現状
インスピレーションから見栄えの良いアプリケーションを作るのは、今まで以上に簡単になった。このAIツールは本当に優秀や。正しいスタート地点を渡せば、めっちゃ遠くまで持って行ってくれる。でも、その正しいスタート地点を見つけるのは今まで以上に難しくなってる。
サインインページやペイウォールのリファレンスUIをGoogleの画像検索で探そうとすると、見つかるのはゴミばっかりや。Googleの画像で良いインスピレーションを見つけようと時間をかけすぎてきたけど、全然あかんわ。だから良いデザインを作ったり、Figmaで時間をかけずに良いアプリを作ろうとしてるなら、今日のスポンサーがめっちゃ助けになるで。
Mobinは俺のデザインに対する考え方を根本的なレベルで変えてくれた。1000の異なるiOS、Android、ウェブアプリから40万以上のスクリーンがあって、リファレンスとして使えるんや。デザインしてるときに役立つリファレンスポイントを見つけるのがどれだけ簡単かは本当に笑えるくらいや。
例えば、アプリにパスワードを忘れた画面を追加したいとしよう。いろんなところでどう見えるかがこんな感じや。Senseがあって、Universe、Krakenもある。業界カテゴリが違うから心配やとしよう。フォトとビデオの世界は他の場所とは違うやり方をしてる。今度は、どこかにリセットパスワード画面があるフォトとビデオアプリに絞り込んでる。これをニュースアプリのペイウォールを見つけるように切り替えることもできる。
サブスクリプションとペイウォールのニュース。はい、これや。いろんなニュースアプリで異なるペイウォールがどんな風に見えるか。リファレンスポイントとしてめっちゃ役立つ。ウェブをチェックしたいなら、トグルをクリックするだけ。ペイウォールを持つウェブサイトがたくさんあって、自分のデザインを作るときのリファレンスポイントとして使える。
しかも今まで以上に安い。文字通り月10ドルや。これだけ役立つリソースとしては信じられないくらい安い。俺は喜んでチーム全員の分を払うで。結局役に立たないものをGoogleの画像で探し回る時間を減らせるからな。めっちゃお得や。ぜひチェックしてみてくれ。soyv.link/mobinで今日試してみて。
TEAハッキングの詳細分析
さあ、TEAハッキングを分析していこう。俺が入りたい核心的なことがいくつかある。何が起こったか？つまり、ハッキングって何やったん？そしてもっと重要なのは、何が漏洩したか？どうやって起こったか？そしてもちろん、どうやって防げるか？これらの質問全部に答えるよう最善を尽くすで。
まず、何が起こったか？Tアプリは女性だけのものやから、つまり女性だけがサインアップできるから、サインアップする人が確実に認証されるよう多くの作業をしてる。認証プロセスは時々顔をスキャンしたり、時々身分証明書を提出したりする。これら全部がファイルを生成して、どこかに保存せなあかん。
これらのファイルはFirebaseの公開バケットに保存されてて、そのバケット内のデータが漏洩した。つまり、このアプリに参加するために提出した人々の顔写真、身分証明書などの数十万枚の写真が、誰かが全部のURLを見つけて全部のファイルを保存して、今それを世界中に投稿して共有してるから、今では公開アクセス可能になってるってことや。
起こったのは、Tのファイル、特にファイルバケットがアクセスされたってことや。直接じゃなくて、バケットへの設定アクセスがあったけど、ファイルバケット内の全ファイルがアクセスされた。このバケットは2024年以降使われてないことも注目すべきや。だから新しいユーザーのサインアップは影響受けてないけど、初期からいた古いユーザーのデータはほぼ確実にこれで漏洩した。
最初の漏洩では、データはファイル、主にユーザーが身元確認のためにアップロードした画像やった。そんなもん漏洩するのはやばいで。しかも、彼らはこれらのファイルを適切に処理してなかった。だから多くのファイルにまだメタデータが付いてる。iPhoneで写真を撮ると、その情報を全部記録してるからな。
そのデータを削除せずに写真をアップロードしたら、それは永久にその一部になってまう。うん、良くないな。彼らはまた別のハッキングも受けて、アプリ内にあったメッセージデータも全部暴露された。そしてこれが原因でメッセージ機能を完全にシャットダウンした。
ここで何が起こったかの概要と、なんでこれが悪いかの良い部分があると思う。誰もこのデータが暴露されることは望まんやろう。このユーザーやこのアプリを愛してても憎んでても、俺も自分なりの感情があるけど、これは決して良いことじゃない。これは公平じゃない。人々はサインアップするときにこんなことは期待してなかったし、このデータが暴露されたのは最悪や。
これがどうやって起こったかを分析して、彼らがどれだけひどく失敗したかを明らかにしていくから、会社にとってはもっと厳しくなるで。
ハッキングの仕組みと誤解の解明
どうやってこれが起こったか？俺らがみんなここにいる大きな質問や。最もよくある誤解から始めよう。「バケットは公開やった。何もハッキングされてない。」このコメントを何回も見たわ。そしてこれが馬鹿げてる理由が2つある。
最初の理由は、俺らが「ハッキング」という用語を「盗む」という用語と同じように使うからや。誰かが玄関のドアを開けっ放しにしてて、他の誰かが入ってきて、引き出しを漁って、たくさんのものを盗んで出て行ったとしても、ドアが開いてたとしても、その人からまだ盗んだんや。侵入してないかもしれんけど、確実に盗んだ。
ハッキングは侵入プロセスと、そのデータにアクセスして再配布するプロセスの両方を表すオールインワンの用語として使われる。だから、そのデータを取得するために何かを回避する必要がなかったとしても、ハッキングという用語はここで完全に適切や。
だから俺は、ここでハッキングという用語を使うべきじゃないって言うみんなに根本的に反対や。彼らのセキュリティがどれだけ悪かったかは説明できるけど、それでもハッキングって呼ぶことはできる。だってそれはまだハッキングやからな。
多くのサービスがURLを公開で晒してることも注目すべきや。何かのURLを持ってたら、大抵の場合アクセスできるやろう。これには本当に大きなサービスも含まれるけど、限定されない。つい最近まで、Google Photosもアップロードされた全てのものに公開URLを持ってた。でもそれらのURLはランダムに生成されてて推測不可能や。だから全部のファイルを見つけることはできん。
誰かがそれを送ったり、URLがどこにあるかを追跡するような怪しいVPNを使ってたりしたら、そこから取得できる。でも、そのレベルで既に侵害されてたら、とにかくデータにアクセスできるやろう。だから公開で晒されたURLにあるからって誰かがデータにアクセスできる理論的な方法は全部、そもそもそれを取得するためには、おそらくファイルも取得できてたやろうから、ちょっと馬鹿げてる。めっちゃ馬鹿げてる。
だから再び、ポイント1：ハッキングはしばしばここで起こった情報の窃取を表すのに使われる。アクセスが簡単やったとしても、それでもやられた。でもここでもっと重要な部分は、彼らが全部のURLを取得したってことや。URLを取得するのは確実にハッキングや。なぜなら、全部のファイルのURLを取得するために、その情報を晒すようなやり方で叩けるエンドポイントを見つける必要があったからな。
ウェブサイトの全ての公開URLを魔法みたいに嗅ぎつけることはできん。世界はそんな風には動いてない。これらのUUIDタグ付きファイルアップロードは何千億もある。公開やからって魔法みたいに指を鳴らしてそれらを手に入れることはできん。インデックスが必要や。そしてそのインデックスを取得するのは確実にハッキングや。
誰かの車に侵入して、車の中に家に入る鍵があって、それを使って家に入ったとしよう。確かに、俺は家には侵入してないけど、クソ車には侵入した。これがハッキングじゃないって言うのは馬鹿げてる。本当に馬鹿げてる。
PIIとかあるから拡大したくないけど、ここで強調したいのは、色んなサイトからやってきたハッカーがこのデータを取得するために、JSONを通してアクセスせなあかんかったってことや。Firebaseとtapp.appspot.comをやるGoogleAPIにあったから、誰かがウェイバックマシンしてくれてありがたい。
それがFirebaseで多くのものが動く方法や。彼らはこの方法でバケットから全てのアイテムを取得できた。だから彼らはこのエンドポイントを叩いて、全てのデータをリストアップする晒されたエンドポイントを叩くことで、全てのファイルとそのURLを見つけることができた。ここが違いや。
ファイルURLを晒すのはそんなに大きな問題じゃない。プライベートにすべきか？たぶんな。ファイル管理に有能なサービスを使うべきか？ほぼ確実に。俺はuploadthingを強く推薦する。俺らがそれを作った理由がある。本当に良いサービスや。とはいえ、公開URLを持つことは、こういうハッキングを引き起こすのに十分じゃない。URLのリストへのアクセスが必要で、彼らは無能やからそれも持ってた。
チャットハッキングの詳細は持ってないけど、Firebaseの晒されたAPIと似たようなものやと推定してる。だから、その部分を分析する時間やと思う。
Firebaseの根本的問題とバイブコーディングの誤解
なんでこれが起こって、どうやって防げるか？全てが上手くいけば、これがこのビデオの大部分になるやろう。ここが実際に学ぶことがある場所や。
バイブコーディングやったんか？良い質問や。彼らがこれを作ったときにAIを使ってたかどうかは確実には言えん。データの多くは2024年中頃に使用停止になったバケットから来たと思うからな。実際にバイブコーディングしてた可能性は非常に低い。だから多くの理由で、これはバイブコーディングじゃないと思う。それを面白い方法で正当化するで。
Eva、Braun、Logiは結構前からコミュニティの一部やった。彼らはFirebaseサイトの主にハッキングをたくさんやってきた。FirebaseはミスコンフィグレーションNを簡単にするからな。彼らは一つの脆弱性を使って900以上のサイトと1億2500万のアカウントをポーンした。それがFirebaseの動作のデフォルトみたいなもんや。
この時点で、Firebaseは問題やって確信を持って言える。ここだけやなくて、一般的に。でもなんでそう思うかを少し分析したい。俺が開発エコシステム全体で最も嫌いなものの一つについてクソミソに言う絶好の機会を神様から与えてもらった。そして俺はFlutterについてクソミソに言うのと同じくらい、この機会を最大限に活用するつもりや。Firebaseは本当に、本当に悪いからな。
だから俺がなんでそう思うか分析しよう。ここに開発者のスペクトラムがあって、一方にはシステムインフラの人たち、カーネルについてオタクで自分でサーバーを立ち上げたい人、インフラを管理してくれるタイプの人がいる。もう一方にはフロントエンド開発者がいる。一方には深いところまで入る人たち、もう一方にはオタクなフロントエンド開発者、俺のようにステレオタイプにされる人たちがいる。君らも自分が誰かわかってるやろう。俺らが誰かもわかってる。
モバイル開発者はどこに当てはまる？モバイル開発者はどこに行くと思う？チャット、俺の周りに長くいるなら、もう答えを知ってるやろう。モバイル開発者はインフラ側により近づくんか、フロントエンド側により近づくんか、それとも他の場所か。
見てみい。君らは長い間ここにいてくれてる。モバイル開発者はインフラにより近づかん。フロントエンドにより近づくことさえない。はるか、はるか向こうに行く。ポイントを作るために拡大せなあかん。フロントエンド開発者とサーバーの人の間のギャップは、フロントエンド開発者とモバイル開発者の間のギャップとほぼ同じや。
これは俺にとって受け入れるのが難しいことやった。モバイルやってたとき、システムやLinuxやそういうことについて本当にオタクやったからな。でもモバイル開発は本当に楽しくて、俺が気にしてたネイティブなことを取って、人々が使えるように目の前に置くことができた。それは本当にクールやった。
フロントエンド開発者に新しいサーバー技術について話すとき、彼らは本当に馬鹿げたことを言う傾向があることについてよく考える。React界の皆の大好きなサーバーコンポーネントを持ち出すときみたいにな。フロントエンド開発者になんでこれが役立つかを説明しようとするのは歯を抜くようなもんで、理解できへん。彼らが働く世界、つまりブラウザの中のものからあまりにもかけ離れてるから、それを理解する正しいメンタルモデルを持ってないんや。そこにどう到達するかやなくてな。
だからサーバーコンポーネントが起こったとき、モバイル開発者はここの2つの間のどこかにいると思ってたから、それらを理解するのがより良いやろうと思った。間違ってた。モバイル開発者は全部の道の向こうにいる。そしてここで俺らの友達Firebaseの出番や。
もしまだ知らんかったら、Firebaseはあなたのアプリを最高にするための方法や。面白いな。他のブラウザでも動くんか？そこの背景のグレーも見えるけど、神様、Firebaseはほんまにジャンクや。めっちゃジャンクや。俺には…彼らのサイトを見せて良い印象を与えようとしてたけど、不可能や。くそったれFirebase。
Firebaseはバックエンド・アズ・ア・サービス・プロバイダーへの最初の主要な試みやった。目標は、アプリ、ウェブアプリ、モバイルアプリを作りやすくするために、データベースからファイルストレージ、認証、APIまで全てを処理することやった。でも明らかにモバイルにより焦点を当ててた。FirebaseはGoogleに買収されて、それ以来Firebaseの周りにある。
Firebaseの問題は、データについての考え方や。ほとんどのシステムでは、データベースがあって、それは明らかに菱形で、もちろんユーザーがいて、それは明らかに円や。そしてユーザーは明らかにデータベースに直接アクセスしない。ユーザーがアクセスする方法は、間にあるレイヤーを通してで、しばしばAPIと呼ばれる。
これは君が作って、コードを書いたサーバーや。ユーザーが何かしたいとき、ユーザーはこのAPIの名前付きエンドポイント、例えば/getprofileを叩く。だからユーザーはこのget profileエンドポイントを叩く。Get profileは君がAPI内で書いたコードに沿って、select * from profiles where ID equals some IDみたいなクエリをデータベースに送る。だからそれは君がAPIで書いたコードのクエリを実行する。そのリクエストのデータで応答する。APIはそれを再整形したり必要なことをして、ユーザーに送り返す。
これがほとんどのインフラ設計の動作方法や。でも覚えておいて、この図の一部で、これらの人が好まない部分がある。モバイル開発者は、サーバーやAPIってあまりにも大声で言うとすぐに脳みそが落ちる傾向がある。だから、真ん中のこれは彼らにとって怖いんや。そしてFirebaseはこの問題に対して本当に簡単な解決策を持ってた。
APIを削除して、ユーザーにデータベースに直接アクセスさせたらどうや？データベースがAPIやったらどうや？ユーザーが必要なデータをクエリできるようにしたらどうや？そしたらAPIを作る必要がない。ユーザーが必要とする可能性のある全てが既に晒されてる。ただ求めれば与えられる。
明らかやろ？これは問題に対する素晴らしい解決策や。ああ、これが悪いアイデアやってことが見えてることを願ってる。APIが持つことができて持つべき多くのことが、データベースにはデフォルトでないからな。
APIでは、プロファイルを求めてる人がその人かどうかをチェックできる。/getprofileを叩いて、IDをsome IDで叩いたけど、クッキーも持ってて、クッキーのIDが他の誰かやったら、サーバーはこのIDを求めるときに、クッキーをチェックして俺が俺やと言ってる人かどうかを確認する。そしてこの2つが同じじゃなかったら、APIは俺にエラーを投げて、DBには行かん。でも俺が俺やと言ってる人やったら、俺が求めてるデータを取得することを選択できる。
こんなコードを書くのは比較的簡単や。俺らはおそらくみんな人生のこの時点でやったことあるやろう。やったことないなら、自分でAPIを作ることを強く推薦する。インターネット全体がどう動くかをもっと深く理解できるようになる。そしてこれをやったら、データベースをもっと自由にクエリできる。データベースを権限システムに変える必要がない。権限システムはAPIにある。
APIエンドポイントを書くとき、それを書きながらこれをやらなあかんのは結構明らかや。あ、認証をチェックしてない。彼らがこのデータを取得できるかどうか確認してない。これらのチェックを追加するで、みたいにな。ユーザーの意図をユーザーが求めるデータに変えるコードを書いてるからな。ユーザーが求めるデータを取得するために無制限のデータセットにアクセスするクエリを書いてるわけやない。
この方法で書くとき、全てにアクセスできるか何もアクセスできないかの安全な環境でコードを書いてるとき、アクセスすべきものだけにアクセスするコードを書くのがずっと簡単や。でもコードを書いてないなら、代わりにロールや権限や行ベースのアクセス制御を書いてるなら、たくさんの問題に終わる。データベースにはコードがないからな。
データベースでAPIエンドポイントを書くことはない。代わりに、データベースで書いてるのはデータや。そしてデータに権限レイヤーを付ける必要があるなら、それはデータベースにホチキスで留める新しいものや。そしてそれをやる必要があることは明らかじゃない。実際、この方法でやるとき間違ってやってる可能性が非常に高い。
セキュリティ設計の重要性とT3スタックの哲学
非常によくあることで、たくさんのサイトが全く同じ方法でハッキングされる。俺はこういうものを長い間めっちゃ嫌ってきたから、それを中心にT3スタック全体を作った。GraphQLの誤用をよく見るのも俺のお気に入りの一つを含めて、何年もこれをやる色んな技術をクソミソに言ってきた。
よく見る間違いは、人々がGraphQLをデータベースとサーバーの間、もしくはもっと悪いことにデータベースとユーザーの間に置くことや。GraphQLで、ユーザーが特定のデータにアクセスする権限を持つか持たないかのロールを定義するコードになる。それは起こるのを待ってる災害や。
厳しい現実は、ユーザーがデータを必要とするとき、そのデータのための新しいエンドポイントを定義すべきやってことや。だからアプリで作業してて、ユーザーのプロファイルを見せる機能を追加してるなら、そのためのサーバーサイドコードを書くべきや。APIエンドポイントが既に存在してない限り、追加してる新しい機能やったらほぼ確実に存在せんやろう。
新しいデータを必要とする新しい機能を追加するとき、そのデータにアクセスする新しい方法と、そのデータにアクセスする実際のフロントエンドのコードの両方を定義することが不可欠や。
デフォルトで晒されてるのがこれらのプラットフォームの動作方法で、それは悪い。デフォルトが全て晒されてて、欲しいものを求めて、後で特定のものへのアクセスを防ぐルールを追加するって時、悪夢に終わるし、誰もセキュリティを確保しようとしない。理由がないからな。プロセスでそれが意味をなすポイントがない。
でもエンドポイント、関数、ユーザーのリクエストとデータベースの間の仲介となる何かを定義せなあかんなら、これはずっと簡単になる。スポンサーを宣伝するつもりやないけど、これが俺がConvexをめっちゃ気に入ってる理由の一部や。Convexはデータベースを提供してくれるけど、データベースはクライアントから直接アクセスできん。
データベースは、コードベースで実際の関数として定義するクエリとミューテーションを通してアクセスせなあかん。これが実際のT3チャットコードベースや。convexフォルダにいる。ここでは、メッセージテーブルのようなたくさんの異なるものを定義してる。ID、スレッドID、ユーザーID、推論があるけど、代わりにメッセージパートをやってるからもう使ってない。
今、ここにある全部のデータがある。だからConvexがFirebaseと似たようなバックエンド・アズ・ア・サービスやったら、ユーザーはこれにアクセスできるって思うやろ？間違い。APIやユーザーがこのデータにアクセスするための組み込まれた方法はない。晒したいなら、晒すことを選択せなあかん。そして俺はこのデータをmessagesファイルで晒すことを選択してる。ここで俺は、ユーザーを認証する俺のカスタムOクエリヘルパーを使うget by thread IDクエリを持ってる。
それからスレッドIDをチェックする。持ってなかったら、空の配列を返す。ユーザーIDも取得して、スレッドIDが彼らが求めてるものと一致し、ユーザーIDも一致する全てのメッセージを収集する。だからこの2つが一致しなかったら、何も取得できずに空の配列を取得する。それだけ簡単や。
でもデータベースへのアクセスを与えるだけやなくて、これを実際のコードとして定義せなあかんかったから、今ははるかに安全や。全ての行を書くとき、何をする必要があるかが明らかやからな。
そしてこれが俺が強調したい本当の重要なポイントや。全てのデータアクセスはソースコードで示されるべきや。これを指定せなあかんってことが俺を深く傷つける。人々がデータベースがAPIになれるって思ってる時代にまだいるなんて信じられん。なれへんのや。それはデータベースや。
データベースはデータを保存するためのもの。APIはデータにアクセスするためのもの。これらは異なるもので、両方が存在する理由がある。Convexがやってるみたいに、それらをより密接に結びつける方法で構築したいなら、素晴らしい。そのための他の選択肢もたくさんある。でもAPIをデータベースで置き換えようとしてるなら、こういう問題に遭遇するで。
FirebaseでもSuperbaseでも、他の代替手段でもな。これが俺がConvexについて話してるときにイライラする理由でもある。人々は「ああ、Superbaseとそんなに違わない」って言う。これ以上違うことはない。共通点はほとんど何もない。別の時間の長い別の愚痴やけどな。
だからこれは全部楽しいけど、実際にハッキングはどこで起こったんや？何が発生したんや？ユーザーがFirebase組み込みAPIを通してfire storeデータベースに直接アクセスするから、それらの多くがただ晒されてて、tapp.appspot.comのFirebaseストレージエンドポイントのURLを叩くことができた。そしてこのAPIを叩くことで、Firebaseファイルストレージに現在あるアイテム全部をダンプしてくれた。
より良く設計されたアプリでは、これについて少し違うように考えるやろう。また自己宣伝するつもりやないけど、俺らのデータベースにはattachmentsテーブルがある。ファイルはattachmentsテーブルに保存されてない。upload thingが素晴らしいから、まだそこに保存してる。もちろん、それを使ってる。でもそこに保存されてる。そして俺らはこれらのファイルのURLをここに保存してる。
重要な違いは、添付ファイルがattachmentsテーブルに保存されてて、添付された実際のファイルは他の場所にあるURLにあるってことや。だから理論的に俺らをハッキングしたくて、俺らのURL全部が公開やったとしても、attachmentsエンドポイントを叩いて全部を取得することで俺らを爆撃できる。
待って、attachmentsエンドポイントなんてない。俺らはソフトウェアを書くのが有能やからな。Convexが正しい方向に導いてくれるからでもあるけど、全ユーザーの全添付ファイルを提供する/attachmentsっていうエンドポイントを持つ代わりに、認証レイヤーを通してユーザーIDをチェックして、君のファイルの添付ファイルを取得するget my attachments関数を持ってる。
Firebaseはこんな良いパターンを促進しない。Firebaseは始めるのが一番簡単な方法やから、全部を晒すことを軽く促進する。他のプラットフォームは、データにアクセスするためにAPIを書くことを要求する。データを晒すためにコードを書く必要がなければ、サービスは良いセキュリティ慣行に向けて導いてない。
データアクセスコードがないのは、起こるのを待ってるセキュリティ問題や。ユーザーに全部を晒すことを促進するプラットフォームは、構築の良い方法やないから、決してサポートせん。これが俺が長い間Firebaseに反対してきた理由で、サーバーについて学ぶ意欲の欠如を心配してきた理由や。
これが俺がサーバーコンポーネント、Next.js、バックエンドとフロントエンドがどう相互作用するかについて考えるマインドセットにあなたを置く全てのものを強く推す理由でもある。これらのことについて考える必要がある。ここで示したように、システムには3つの部分がある。データベース、APIとサーバー、そしてユーザー、クライアント、フロントエンドで動くコード、全部がある。
そしてこの方法で考えてなければ、これらの異なる部分を持ってなければ、妥協してる。ユーザーがいない場合を除いて。そして本当にユーザーはいるんか？要点はわかるやろ。ここで必要な全てを伝えたと思う。Firebaseのようなものを使うときは注意してくれ。
そしてモバイル開発者、君らは他のことを学ぶのを嫌ってることを知ってる。JavaScriptに対する奇妙で深く根ざした恐怖と、サーバーに対するさらに大きな恐怖を持ってる。ほぼ10年前の元モバイル開発者として、それを乗り越えることを強く、強く勧める。それは君のキャリアをはるかに成功させ、はるかに価値のあるものにするで。特に人々が絶対的なクソをバイブコーディングして、これらのことも理解してない時代にはな。
ここで投げ込む最もホットなテイクは、平均的なモバイル開発者は、サーバーについて話すことに関しては、フルスタックバイブコーダーと区別がつかないってことや。俺がスクリーンショットを撮られて、これがあちこちで共有されることはわかってる。気にしない。
これはモバイル開発者にデータをどこかに保存せなあかんって言うときに起こることの典型や。コンサルティングやモバイル開発者との仕事を通して、キャリアでこれに十分遭遇してきて、これらの会話をしてるだけで脳みそが落ちそうになる。これがFirebaseがまだユーザーを獲得できる理由や。
こういう話は本当にたくさんある。文字通りアメリカのファストフード会社のほぼ全部がやられたのは、モバイル開発者がインフラを構築して、そのインフラがFirebaseで構築されたからや。本当のインフラやなかったからな。ウェブに公開されたデータベースやった。
そしてEvaと友達が作ったFireponeっていうツールがこれらのサイトをスクレイピングして、これらのエンドポイントを見つけて、完全に破壊することができた。再び、全てのデータが晒されてるとき、正しいデータを見つけることや。このハッキングは、アクセスできる全てのデータを調べて、ID0の組織を見つけて、アクセスするのに十分なデータを取得して、このユーザーのロールがスーパーアドミンやと気づいて、他のものを叩くときに彼らのIDを使って、渡してる実際の値以外の何からもIDを取得してないから検証さえされてないことに気づいて、今では全ての管理者データにアクセスできるってことやった。
ちょっとクレイジーで、サーバーの構築方法を知らんときは非常によくあることや。あと、マウスを追いかけてる猫は愛らしい。こんな素敵な小さなサイトを作ってくれてありがとう、Eva。
まとめと提言
だから簡単な核心的な要点はここや。データコードを書け。データベースのデータにアクセスしてるなら、そのためのコードはサーバーで君が書くべきや。Firebaseを使うな。起こるのを待ってる災害や。そしてバブルの中で生きるのをやめろ。
モバイル開発者なら、モバイルだけに焦点を当てるのをやめろ。ウェブ技術を使って何か構築しろ。本当のサーバーを構築して、それらがどう相互作用するかを理解しろ。ウェブ開発者で完全にJavaScriptエコシステムの中で生きてるなら、Goでバックエンドを構築しろ。SwiftとSwiftUIを使ってモバイルアプリを構築しろ。バブルの外で何かやって、スペクトラムの他の側を理解できるようにしろ。
そうしなければ、他の誰もと同じようにこれらのことの犠牲者になる。これらの会社の多くは、やりたくないことをやらなくてもいいっていう約束を売ってるからな。Firebaseはインフラを売ってない。インフラについて考えなくてもいいっていう約束を売ってる。そしてインフラについて考えてなければ、teが犯したのと同じ間違い、アメリカのクソファストフード会社の半分が犯したのと同じ間違い、そしてもっと多くの間違いを犯すまで一歩や。
他の場所でもこれらの間違いを犯すことはできる。でもFirebaseは、この種の人をこの考え方で掴むための奇妙なハニーポットみたいに見える。これをやるのをやめてくれ。本当のエンドポイントを定義するだけや。そんなに難しいことやない。
みんながどう思うか教えてくれ。Firebaseに厳しすぎたか、それとも合理的やったか？モバイル開発者には厳しすぎたけど、信じてくれ、実際には厳しすぎてない。彼らはこれを聞く必要がある。
みんながどう思うか教えてくれ。そして次回まで、平和だオタクども。
コメント