1
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?

バイブコーディングやプログラム初心者が気をつけるべきセキュリティ事項

Last updated at Posted at 2025-08-12

はじめに

初めまして!ホニャ太郎と申します。
普段は note の方もよく書いているので、よければ読んでみてください!

最近、AIだけでアプリを実装するバイブコーディングが流行っていますね。

そして少し前ですが、バイブコーディング的に作ったアプリのセキュリティの問題が話題になっていました。

なので今回は、バイブコーディングで作ったものを実際にリリースする際に気にした方が良いことをまとめてみます!

以下のようにしっかりまとまった記事はすでにありますが、一定システム開発をわかってる人向けなので、バイブコーディングしてる人だと内容がわからなかったりすると思います。

Web 関連のセキュリティだと徳丸さんの本も有名で、読んでおくのは非常に重要ですが、最近のWebフレームワークだとデフォルトで防がれてるものも一定あるのと、おそらくAIが書いたコードだと防がれてることが多いはずです。

ということで今回は、バイブコーディングのみで開発をしてる人が踏みやすそうかつ致命的な問題について解説していこうと思います。

前提、全ての問題を解説するのは不可能なので、一部なのをご理解ください。

フロントエンドだけで完結するサービス

まずはフロントエンドだけで完結するサービス(ネイティブアプリも含む)のセキュリティ観点を書いていきます!

フロントエンドだけで動くアプリは、ユーザーのブラウザ(またはスマホ)の中だけで全ての処理が終わるため、サーバーを持つアプリに比べてセキュリティリスクは低めです。

なぜなら、攻撃の対象となるサーバーが存在せず、データベースに保存された個人情報などが漏洩する心配がないからです。

一方で、APIキーなどの秘匿情報を含んでいないかは要注意です。

例えば、OpenAI のAPIを使う場合は API キーを利用しますが、これをフロントエンドアプリと一緒にデプロイしてしまうと、誰からでもAPIキーが見れてしまいます。
このような状況だと、知らない人があなたのAPIキーで有料APIを使い放題になってしまい、ガチで破産します。数百万レベルの請求が来るのはあるあるです。

リリースの際は、フロントエンドのコードにAPIキーが含まれていないかは絶対に注意しましょう!

バックエンドやDBを含むサービス

バックエンドやDBがあり、データのやり取りが発生するサービスでは様々なセキュリティリスクが考えられます。
全てを挙げるのは不可能なので、ここではバイブコーディングなどで、とりあえず動くサービスを作った場合に発生しがちなものを紹介します。

ユーザー毎のデータのフィルタリングが適切にされていない

ユーザーのデータをサーバーにリクエストすることはよくあります。
この際に、ユーザーAがユーザーBのデータを取得できないようになっているかは非常に重要です。
フロントではユーザーAのデータしか取得していなくても、サーバーに直接リクエストを送ってユーザーBのデータを取得できてしまいます。

対策としては、ユーザー毎のデータ取得を行うエンドポイントに必ずユーザーによるバリデーションを入れるとともに、データが守られているかを確認できるテストを追加しましょう。

インジェクションが可能になっている

Web サービスで代表的な攻撃がインジェクション攻撃です。
インジェクション攻撃は、ユーザーが任意のテキストを送ってサーバー側で実行させられるようになっている場合に発生します。

例えば、SQL インジェクションは、以下のようにユーザーから与えられた内容を直接クエリとして実行させているコードが問題となります。

  const sqlQuery = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;

対策としては、クエリに文字列を埋め込むのではなくプレースホルダを利用したり、ORMに沿ってDBアクセスを行いましょう。

ユーザー投稿型コンテンツで、HTML などを入力できる場合も危険です。他のWebページへの誘導などを書かれる可能性があります。
ユーザーの入力テキストを表示する際はエスケープを行うようにしましょう。

また、生成AIの場合にもインジェクションが考えられます。
ユーザーからリクエストされた内容をAIに直接投げられるような実装になっていると、非常に長い文字列をリクエストされてコストが大変になったり、もしかしたらAIを勝手に操作してサーバーやデータを操作されてしまうかもしれません。

こちらもユーザーの与えたテキストをそのまま実行させないようにするなどの対策を行いましょう。

ログに重要な情報を吐いてしまっている

サーバーサイドにおいてはバグやユーザー行動を調査するためにロギングを行うのが重要です。

しかし、生成AIにロギングをさせると、ユーザーが入力したパスワードやAPIキーなどをそのままログに吐いてしまうことがあります。
また、ユーザー情報などをデバッグのためにログに吐いたのをそのままにしてしまうこともあるでしょう。

ログ上のデータは悪意のあるハッカーに盗まれてしまう可能性が0ではないので、重要なデータは出力しないようにしましょう。
不必要ログ自体、できるだけ吐かないようにするのも重要です。

データアクセス権限の設定ミス

サービスを運用する際に画像などのファイルを GCS や AWS S3 などのストレージにアップロードすることがあると思います。
これらは公開する必要がないものは絶対に private 設定にしましょう。設定不足による漏洩事件は定期的に発生しています。

また、最近では Supabase や Firebase などを利用している人も多いと思います。
これらが提供するDBはユーザーからの直接アクセスの権限があったりしますが、不必要なデータにアクセスされないよう、絶対に適切な設定を行いましょう。

以下の記事を見ると、Supabase はデフォルトで作成したテーブルは誰でもCRUDできるように設定されてしまうようで非常に危険です(最新だと変わってるのかもですが)。

とにかく、セキュリティは適切に設定されているか確認するだけでなく、しっかり動作確認したり権限のテストを実装し、絶対に問題が起きないようにしましょう。

データアクセス制限の設定方法がわからない場合はそもそも、そのサービスを利用すべきではないです。

CORS で全てのオリジンを許可してしまっている

フロントエンドとバックエンドが分かれた Web サービスを運用する際には CORS の設定が必須です。

CORS は初心者だとわかりづらい概念のため、とりあえず全オリジンを許可してしまってる人がいるかもしれませんが、必ずリクエスト元のオリジン(Web サービスならばフロントエンドのドメインなど)のみを指定するようにしましょう。

利用しているフレームワークやライブラリのメンテナンスをしない

リリースしたアプリを運用していると、毎日のようにフレームワークやライブラリにアップデートが入ります。
ライブラリには定期的に致命的なバグのアップデートが入ったりします。
そのため、ライブラリのアップデートは常に監視して、重要度が高いものはすぐに修正を取り込むようにしましょう。

一般的には GitHub に dependabot を入れてライブラリアップデートを監視します。

デプロイは必ず https で

http のサイトとの通信は暗号化されていないため、第三者から情報を抜き取られる可能性があります。
必ずサービスは https でデプロイしましょう。

開発に利用しているサービスに2段階認証を設定していない

開発したものをデプロイする際はクラウドであったり、デプロイ用サービスだったり、GitHub だったり様々なものを利用すると思います。

これらには必ず2段階認証を設定しましょう。

今まで解説した対策をいくらしていたとしても、開発に利用しているサービスに攻撃者が入った段階で全て無駄です。全ての情報を抜き取られた上に、勝手に利用されて大量の課金を課せられる可能性もあります。人生が終わる可能性も全然あります。

ということで、開発に利用するサービスには必ず2段階認証を設定しましょう。

パスワードを平文で保存しない

基本中の基本ですが、パスワードは平文で保存してはいけません。
漏洩した時にパスワードをそのまま利用されてしまうからです。
必ずハッシュ化しましょう。

というより、基本的に認証周りは自分で実装しないようにしましょう。
安全な認証を個人レベルで作るのは難しいです。

Admin ページには誰もアクセスできないように

Rails や Django などのフレームワークだと、デフォルトで /admin に Admin ページが作られることがあります。
推測されやすい場所に admin ページをおくと、ユーザーデータが漏洩したり、サービスを破壊されたりと大変なことになるので、絶対やめましょう。

モバイルアプリの場合

自分はモバイルアプリにそんなに詳しくないのですが、思いつく範囲(経験した範囲)で書いておきます。

高負荷を与える処理を行わない

モバイルアプリの場合、負荷が高い処理を入れるとデバイスがすぐに発熱して、デバイスが動かなくなったりします。
必ずテストは実機で行い、デバイスの負荷が酷くないか確認しましょう。
各プラットフォームでCPU利用率を見れる機能が X Code や Android Studio にはついてたと思います。

大量のデータ通信を行わない

画像や動画を閲覧する系のサービスの場合、それらの容量が大きすぎてあっという間に通信容量を食い潰してしまうことがあります。
特にモバイルの場合は Wifi 環境でないことも多いので、影響がでかいです。
画像や動画については可能な限り圧縮を行いましょう。

最後に

まだまだ気をつけるべきことはたくさんありますが、今回は一旦以上としようと思います。

AI に上記を気をつけさせるのも当然ですが、デプロイなどAIだけではできない部分にセキュリティリスクが潜んでいることも非常に多いので、気をつけてください。

もしこの問題も致命的だと思うというのがあれば足しますので、ぜひコメントいただけると幸いです!

また、自分でチェックするのが不安だったりわからないという方は、以下の募集やXなど経由でご依頼も受けてますのでよければです。

1
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
1
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?