前回はフロントエンドの脆弱性について解説しました。今回はバックエンド、つまりサーバー側に対してどのような攻撃があるのかを解説します。
セキュリティホールは、絶対に守らなければならないクリティカルなものから、中程度・低程度のものまで非常にたくさん存在します。探せば探すほどいくらでも出てくるためキリがないので、ここでは特にクリティカルな内容に絞ってお伝えします。
1. ブロークンアクセスコントロール（認可チェックの不備）
1つ目は、APIに対して攻撃者が直接リクエストを送って実行する手法です。これはブロークンアクセスコントロールと呼ばれる脆弱性です。
前の動画でも触れましたが、APIはアプリを公開している時点で、それ自体も公開されていることになります。つまり、そのAPIは第三者でも実際に呼び出すことができます。呼び出す方法としては、curlコマンドや、PostmanのようなAPI呼び出しツールなどがあります。こうしたツールを使えば、第三者が公開されているアプリのAPIを叩くことができてしまいます。
たとえばX（旧Twitter）の例で言うと、「ポストを投稿する」「ポスト一覧を取得する」といったAPIがあります。これらは誰でも叩くことができてしまいますが、「投稿する」という操作を第三者が勝手に実行できてしまったら、セキュリティ的にまずいわけです。
そのため、APIの実装の中には認可チェックを含めるのが普通です。実際にログインしているユーザーだけが投稿できるようなコードにしておかないと、誰でも投稿できてしまいます。バイブコーディングをするときなどは、APIを実装する際に「ログインしているユーザーだけが叩けるAPI」という設定にしておく必要があります。
表示系と書き込み系で扱いを分ける
一方で、認可チェックが必須ではないAPIエンドポイントもあります。たとえば「ポスト一覧を取得する」処理は、誰が叩いても構わないわけです。実際にXでも、ログインしていないユーザーでもポストやプロフィール、タイムラインは見ることができます。こうした表示系の処理では、認可チェックは必須ではありません。
整理すると次のようになります。
- 表示系（一覧取得・閲覧など）：認可チェックは必須ではない
- 書き込み系（投稿・削除・編集など）：厳重に認可チェックを実装する
書き込み系の処理については、認可チェックの実装をClaude Codeに確認してもらうと、乗っ取りやハッキングといった被害を避けることができるので、チェックしておくとよいでしょう。最近のAIは賢く、デフォルトで認可チェックを実装してくれることも多いのでそこまで神経質になる必要はありませんが、「バックエンドから直接攻撃される方法もある」ということは頭に入れておいてください。
2. IDOR（安全でない直接オブジェクト参照）
もう一つ、IDOR（Insecure Direct Object Reference）という脆弱性があります。これは認可チェックに関わる脆弱性です。
たとえばxx.comというサービスを公開したと仮定します。あなたがユーザーIDが1番のユーザーとして新規登録・ログインしたとします。本来このページは、ログインしたユーザー自身だけが見られるような設定にしていたはずです。ところが、URLなどのID番号を直接変えるだけで、2番や3番の他のユーザーのページも見られてしまう、ということが起こり得ます。
これも認可チェックに関する問題です。大事なページや大事なAPIに対しては、「アクセスしているのが本人かどうか」のチェックをきちんと挟むようにしてください。
3. DDoS攻撃とレートリミット
もう一つ、API関連の脆弱性としてDDoS攻撃（DoS攻撃）があります。これは、実装したAPIに対してめちゃくちゃ大量のリクエストを投げて、サーバーを落とす攻撃手法です。
オンラインゲームをやっている方なら、「DDoS攻撃を受けてサーバーがダウンした」という話を聞いたことがあるかもしれません。たくさんのリクエストを送ってサーバーを落とす攻撃、と理解しておけば大丈夫です。
対策：レートリミット（回数制限）
DDoS攻撃を防ぐためには、レートリミット（回数制限）を実装することをおすすめします。たとえば「1分間に最大60回までリクエストを送れる」というように設定します。サービスによって適切な回数は変わりますが、「1分間に同じAPIを1000回叩くようなことは現実的にあり得ない」という場合は、60回までに制御するといった実装をしてあげると、DDoS攻撃を防ぐことができます。
このDDoS攻撃に関しては、標準のNext.jsやReactでは守ってくれません。そもそもReactはAPIを作れないので、Next.jsのAPI実装であれば、きちんとレートリミット制限を実装しておいたほうが安全です。
AI機能を実装している場合は特に注意
作っているアプリにAI機能を実装している場合、たとえばチャットでサポートするような機能があると、そのAIを使ったAPIエンドポイントに大量のリクエストを送られてしまったら、その分だけ高額な請求が来てしまう可能性があります。AI機能を作っている場合は、特に対策が重要です。
- API側でレートリミット制限をかける
- AIを提供している側（Gemini、ChatGPTなど）でレートリミット制限をつける：手動で制限をつけることもできますし、無料枠であれば「1日のリクエスト上限が300回まで」「画像生成AIなら1日300回まで」のように事前に上限が決まっています
無料枠の上限を超えるとエラーになります。逆に、それが原因でサービスが動かなくなってしまうこともあります。レートリミット制限を設定すればDDoS攻撃は防げますが、制御を加えすぎると、ユーザーがたくさん来た場合にAIやAPIが動かなくなる原因にもなります。そのため、制限のバランスが大事になります。
なお、DDoS攻撃を受ける対象は、やはり伸びているサービスや大規模なサービスです。月に何百万・何千万人規模のリクエストをさばくようなサービスにそうした危険性があるので、個人開発で始めたプロジェクトでその可能性はかなり低いです。これからサービスを大きくしていく場合やユーザー数が増えてきた場合は、レートリミット制限を見直して、サーバーダウンや不当な請求が来ないようにしておくのがおすすめです。
4. データベースへの攻撃とキー管理
フロントエンドとバックエンドについて説明してきましたが、「データベースに対する攻撃はないのか」という点についてです。
Tursoを使う場合は、基本的にAPI経由でデータを動かすので、直接データベースを攻撃されるようなことはあまり考えにくいです。ただし、Tursoで管理しているAPIキーやトークンといった情報が流出してしまうと、それをもとにデータベースをいじられてしまいます。キーの漏洩・流出には十分気をつけてください。
具体的には、次のような対策を徹底すれば防げます。
.envをGitHubに公開しない- Claude Codeにキーを直接渡さない（Anthropicのサーバーに残ってしまう可能性があるため）
Supabaseを使う場合は特に注意
注意してほしいのが、Supabaseを使った場合です。Firebaseなどでも同様かもしれませんが、Supabaseはちょっと特殊です。Tursoのような構成であればAPIを経由してデータにアクセスするので比較的安心なのですが、Supabaseはフロントエンドから直接データをいじれてしまいます。
そのため、続いての動画では、このSupabaseを取り扱う上での脆弱性について紹介します。個人開発でSupabaseを採用する方も多いと思うので、注意喚起として次の動画もぜひご覧ください。
もちろん、攻撃手法はまだまだたくさんあります。ここで紹介したのはほんの一部にすぎないので、気になる方はAIに聞いてみると面白いと思います。