今回Hacker Newsで話題になったのは、Fiverrに関連する顧客ファイルが外部から検索可能な状態になっていた、という指摘です。
Fiverrは、仕事を頼む人と受ける人をつなぐ gig work / task platform です。
たとえば、デザイン、翻訳、Web制作、税務書類の作成補助のような仕事がやり取りされます。
問題のポイントは、そのやり取りで使われるファイル処理に Cloudinary というサービスが使われていたことです。
Cloudinaryは画像やPDFを扱いやすくするサービスで、ざっくり言うと「ファイルを預かって、Web上で配信してくれる便利屋さん」です。
ただし、便利さには落とし穴があります。
Cloudinaryには、期限付きでアクセスできる signed / expiring URL があります。これは「この人だけ、しかもこの時間だけ見られる」ようにする仕組みです。
一方で public URL は、文字通り「誰でもアクセスできるURL」です。
今回の報告では、Fiverrがこの敏感なファイルに対して、本来なら安全な署名付きURLを使うべきところを、公開URLで出していた とされています。
その結果、Google検索で見つかる状態になり、しかも 税務書類やPIIを含むものが多数あった という話です。
これ、かなりまずいです。
個人的には、単なる「うっかり」よりも、そもそも設計思想が甘い と感じます。
機能として「共有できる」ことと、「世界中から検索できる」ことは、まったく別物ですから。
PIIは Personally Identifiable Information の略で、簡単に言うと「本人を特定できる情報」です。
たとえば、氏名、住所、電話番号、SSN（米国の社会保障番号）、税務情報などです。
こうした情報が公開されると、最悪の場合は：
につながります。
特に今回の話では、確定申告関連の書類のようなもの が見つかったとされていて、かなり生々しいです。
しかも、コメント欄では「低所得者や支援を必要としている人たちの、最も痛いところがさらされている」と指摘されていました。
これは本当に重い話だと思います。セキュリティ事故って、単に「データが漏れた」で終わらず、一番弱い立場の人にしわ寄せが行く んですよね。
普通の公開事故と違って、検索エンジンにインデックスされると、漏えいが静かに、しかし長く続きます。
誰かが偶然見つけるのではなく、検索すれば出る 状態になるからです。
投稿では site:fiverr-res.cloudinary.com form 1040 のような検索例も挙がっていました。
これは「Fiverr関連のCloudinaryドメインで、1040フォーム（米国の所得税申告書）を探す」検索です。
こういう検索で出てしまうのは、かなり象徴的です。
「一部の人が見つけてしまった」ではなく、検索インデックスに乗った時点で広範囲に露出していた ということですから。
Fiverr側は最初の声明で、ざっくり言うと
「プライベート情報を積極的に公開していない。問題のコンテンツは、マーケットプレイス活動の中で、ユーザーが作業サンプルとして共有したものだ」
と説明しています。
でも、これには違和感があります。
なぜなら、SSNや税務書類を“作業サンプル”として共有する状況 は普通ではないからです。
もちろん、実際には「共有ボタンを押すと公開URLが発行される」ような設計だった可能性はあります。
その場合、ユーザーは「相手に見せるだけ」のつもりで操作していても、結果として外に出てしまう。
この意味では、「ユーザーが共有した」という説明が、技術的には一部正しい可能性もあります。
ただし、それでも 安全設計の責任はサービス側にある と思います。
ここ、すごく重要です。
「ボタンを押したのはユーザーだから自己責任です」は、セキュリティの世界ではだいぶ雑です。
ユーザーはURL公開の仕組みまで理解していないことが多いし、ましてや検索エンジンに載るかどうかなんて、普通は意識しません。
投稿者は、40日以上前に security@fiverr.com へ通知したが返信がなかった と書いています。
そのため、CVE/CERTの対象にもなりにくいと考え、公開したとのことです。
Responsible Disclosure は、ざっくり言うと
「問題を見つけた人が、すぐ暴露せず、まず会社に直す機会を与える」
というルールです。
ただ、今回の話ではその窓口が機能していなかったように見えます。
40日放置は、正直かなり印象が悪いです。
個人的には、これが一番の問題のひとつではないかと思います。
バグそのもの以上に、**“通報しても動かない” 会社** という評価がつくのが痛いです。
ここは少し整理が必要です。
Cloudinary自体は、画像・PDF配信を便利にするサービスです。
問題は「Cloudinaryを使ったこと」ではなく、どう設定して使ったか です。
コメントでも「Cloudinaryが止めたら404になった」とあり、少なくとも後から何らかの対応が入った様子がうかがえます。
ただし、実際にどこまで誰が何をしたのかは、元投稿だけでは断定できません。
なので、ここは冷静に見るべきで、
今回の件で、個人的にいちばんゾッとしたのは、
“ファイルが置かれていた” のではなく “検索で見つかった” こと です。
ファイルサーバーに一時的に置いてあっただけなら、まだ限定的な事故で済む可能性があります。
でも検索結果に出るということは、公開範囲の設計がかなり雑だったか、少なくともその状態を検知できていなかったということです。
しかもHacker Newsのコメントには、
もしこれが事実なら、被害はかなり広く、しかも深刻です。
「ただのWeb事故」ではなく、生活に直結する情報の漏えい ですから。
こうした問題は、たいてい「誰かが悪意を持って漏らした」というより、
便利さ優先で、公開設定の危険性を軽く見た ときに起きます。
よくある流れはこんな感じです。
こういうの、技術現場では本当にありがちです。
そして厄介なのは、動いてしまう ことなんですよね。
動くから、危険でも放置されやすい。
個人的には、セキュリティって「壊れていないこと」より「壊れていることに気づけること」のほうが大事な場合が多いと思います。
これはかなり重い案件です。
なぜなら、単なるパスワード漏えいではなく、信頼して預けた書類が外に出る構造 が疑われているからです。
Fiverrのようなマーケットプレイスは、ユーザーが「ここなら安心」と思って使うサービスです。
そこで公開URLの設定ミスが起き、しかも検索可能になっていたとしたら、ブランド毀損はかなり大きいでしょう。
また、セキュリティ報告を40日放置したように見える点も気になります。
技術的なミスはまだしも、報告を受けて何もしない のは、かなり印象が悪いです。
個人的には、ここがいちばん残念です。
今回の件は、
「Fiverrが顧客ファイルを公開し、Google検索で見つかる状態にしていたのではないか」
という深刻な指摘です。
技術的には Cloudinary の URL設定と公開運用の問題が中心に見えますが、本質はそこだけではありません。
この3つが重なって、かなりまずい印象になっています。
セキュリティ事故は、起きた瞬間よりも、起きた後にどう対応するか で会社の評価が決まることが多いです。
今回は、その意味でもかなり苦しい事例だと思います。
参考: Tell HN: Fiverr left customer files public and searchable | Hacker News
