5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

個人開発サービスがBotによる攻撃を受けた時の話

5
Posted at

はじめに

こんにちは、ひるげです。

今回は、私が個人開発で運営しているWebアプリ「Co-fitting」が、過去にBotによる攻撃を受けた際の話をします。

※注意※
本記事で取り上げる事象は、 2025年6月(半年以上前) に発生したものです。
すでに適切なセキュリティ対策を完了しており、 現在のCo-fittingは安全です。 安心してご利用ください。

この記事で伝えたいこと(要約)

ざっくり言うと、以下のような内容です。

  • 運営サービスに、Botによる大量のサインアップリクエストが来た
  • 実装していた「メールアドレス認証」のおかげで、不正なログインが可能な「有効なユーザー」は作られず、致命傷には至らなかった
  • とはいえ、DB汚染やメールアドレス乗っ取り時の不正サインアップリスクがあるため、根本対策としてreCAPTCHA認証を導入し、Botがサインアップリクエスト自体を送れないようにした

個人開発サービスを運営している方にとって、セキュリティ対策の一事例として参考になれば幸いです。

前提:私のサービスでの新規登録フロー

本題へ入る前に、Co-fittingの新規登録フローについて共有しておきます。
この流れを把握していただくと、後の話が理解しやすくなります。

Co-fittingは、基本機能をユーザー登録なしで利用できますが、レシピ保存などの便利機能を使うためにアカウント登録ができるようになっています。
登録フローは一般的な「メールアドレス認証」を採用しています。

  1. サインアップフォーム入力
    ユーザーがメールアドレスとパスワードを入力して送信する。
    この時点でデータベースにはユーザー情報が追加されるが、is_active(有効化フラグ)は false となっており、まだログインはできない状態(仮登録)

  2. メールアドレス認証
    入力されたアドレス宛に、認証リンクの記載されたメールが送信される

  3. 本登録完了
    ユーザーがメール内のリンクをクリックすると、対象ユーザーの is_activetrue になり、ログインが可能になる

起きたこと

問題が発生したのは、2025年6月3日のことでした。
なんとなくデータベースの登録ユーザー数を確認していたところ、異常な数の「非有効化ユーザー(仮登録状態のまま放置されているユーザー)」がいることに気づきました。

ユーザー名やメールアドレスを確認してみると、以下のような特徴がありました。

  • メールアドレスのドメインが見たことのない怪しいもの
  • ashdfkajsdf@example.com のようなランダムな文字列

明らかに、プログラム(Bot)によってサインアップフォームに対して無差別にリクエストが投げられている状態でした。

不幸中の幸い

先述の通り、Co-fittingではメールアドレス認証を必須としています。
Botは適当なメールアドレスでサインアップリクエストを送ることはできても、そのメールアドレスの受信ボックスにアクセスして認証リンクを踏むことはできません。

この仕組みが功を奏し、Botは認証を突破できず、「ログイン可能な有効なユーザー」が作られるまでには至っていませんでした。

サービスへの不正アクセスという観点では致命傷を回避できた形ですが、とはいえ手放しで喜べる状況ではありません。

  • データベースに無駄なレコードが大量に作られてしまう(DB汚染)
  • サーバーリソースが無駄に消費される
  • もし実在するメールアドレスが使われ、そのメールアカウントが乗っ取られていた場合、認証を突破されるリスクがゼロではない

こうした状況を踏まえ、「Botにはサインアップリクエスト自体を送らせない」ための根本的な対策を行うことにしました。

講じた対策:reCAPTCHA認証

私が採用した対策は、Googleが提供するBot対策サービス「reCAPTCHA」の導入です。

皆さんご存知、「私はロボットではありません」というチェックボックスをクリックしたり、信号機や横断歩道の画像を選択したりするアレです。

reCAPTCHAにはいくつかのバージョンがあります。ユーザーの操作を阻害しにくい「v3(バックグラウンドでスコア判定)」の導入も検討しましたが、今回は実装容易性の観点から v2(チェックボックス認証) を採用しました。

(具体的な実装コードについては、公式ドキュメントや他のQiita・Zenn記事が存在するため、ここでは割愛します。)

導入の結果

reCAPTCHAをサインアップフォームに導入して以来、Botによる不正なサインアップリクエストは完全に来なくなりました。

データベースに怪しい仮登録ユーザーが増える現象はピタリと止まり、安心してサービス運営を続けられるようになりました。メール認証という最終防衛ラインだけでなく、入口でしっかりと門番を置くことの重要性を痛感した出来事でした。

おわりに

個人開発といえど、インターネットに公開している以上、こうしたBotの標的になる可能性は常にあります。

今回はたまたまメール認証の仕組みが被害を最小限に食い止めてくれましたが、「動けばいい」で済ませずに、最低限のセキュリティ対策を講じておくことの重要性を改めて学びました。
加えて、 色々なサービスで見かけるreCAPTCHAがBotに対して有効に働いてくれることを身をもって感じられた良い経験だったと思います。

この記事が、同じように個人開発サービスを運営されている方の参考になれば幸いです。

5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?