個人開発でWebサービスを公開すると、ユーザーが数人のうちから自動化されたスキャンやボットのアクセスが届きます。「小さなサービスだから狙われない」と考えがちですが、攻撃の多くは規模ではなく設定の甘さを機械的に探しています。
この記事では、個人開発者が最低限おさえておきたいセキュリティ対策の基本を、認証・データベース・インフラ・公開設定の順に整理しました。多数の個人開発サイトを自動監査してきたローンチガード編集部が見てきた「抜けやすいポイント」もあわせて紹介します。
ローンチガード編集部
個人開発アプリの法令表記・UXを自動監査するツール「ローンチガード」を運営しています。本記事は一般的な情報提供であり、法的助言ではありません。個別の判断が必要な場合は専門家にご相談ください。
この記事でわかること
個人開発でセキュリティ対策の基本が必要な理由
企業のサービスと違い、個人開発にはセキュリティ担当者もレビュー体制もありません。設計から公開まで1人で担うぶん、見落としがそのまま本番に出やすい構造です。
狙われるのは規模ではなく設定の弱さ
攻撃者の多くは、特定のサービスを狙うのではなくインターネット全体を自動でスキャンしています。公開された管理画面、漏れたAPIキー、古いライブラリなどが見つかれば、サービスの知名度に関係なく攻撃対象になります。
さらにAIを使った開発が広がり、動くコードを短時間で作れるようになりました。その一方で、生成されたコードの認可チェックや秘密情報の扱いを確認しないまま公開するケースも増えています。
開発者本人に直接返ってくる被害
個人情報が漏えいした場合、運営者には個人情報保護委員会への報告や本人への通知が求められることがあります。クラウドの不正利用で高額な請求が届く、ドメインが迷惑メール送信に悪用されるといった被害も起こりえます。
💬 編集部コメント
「ユーザーがいないから大丈夫」という声をよく聞きます。ただ、公開直後のアクセスログを見るとボットが大半を占めていることも珍しくありません。見ているのは人より機械が先だと考えておくと安心です。
個人開発者が優先すべきセキュリティ対策の5領域
Webアプリの脆弱性として国際的に参照されるのが、OWASP Top 10です。すべてを一度に対策するのは大変なので、個人開発で被害につながりやすい領域から優先度をつけると進めやすくなります。
最優先はアクセス制御と入力値の扱い
もっとも多いのが、ログインはしているのに他人のデータを読めてしまう「アクセス制御の不備」です。URLのIDを書き換えるだけで他ユーザーの情報が表示される状態は、個人開発で頻繁に見られます。
次に重要なのが、ユーザーの入力をそのままSQLやHTMLに埋め込むことで起きるインジェクションやXSSです。優先度の目安を表にまとめました。
| 優先度 | 領域 | 起きがちな例 | 基本の対策 |
|---|---|---|---|
| 1 | アクセス制御 | IDを変えると他人のデータが見える | サーバー側で所有者を毎回確認 |
| 2 | インジェクション・XSS | 入力値をSQLやHTMLに直接連結 | プレースホルダとエスケープ |
| 3 | 認証 | 自前のパスワード保存やセッション管理 | 実績ある認証サービスを利用 |
| 4 | 設定ミス | デバッグ表示やヘッダー未設定 | 本番用の設定を分ける |
| 5 | 脆弱なコンポーネント | 古いライブラリを放置 | 依存パッケージの定期更新 |
仕組みで防ぐ認証・設定ミス・依存パッケージ
3位から5位の領域は、個別のコードより「仕組み」で防ぐほうが確実です。認証は外部サービスに任せ、設定は本番と開発で分け、依存パッケージは自動で更新通知を受け取れるようにしておきます。
認証・データベースのセキュリティ対策
ユーザー情報を扱うサービスでは、認証とデータベースの権限設計が被害の大きさを左右します。ここでの判断ミスは、後から直すのにも手間がかかる領域です。
認証の外部サービス活用
パスワードのハッシュ化、セッションの有効期限、ブルートフォース対策、パスワードリセットの安全な流れなど、認証には考慮点が数多くあります。Supabase Auth、Firebase Authentication、Auth.jsなどの実績ある仕組みを使うと、多くの落とし穴を避けられます。
外部サービスを使う場合でも、次の点は開発者側で確認が必要です。
- メールアドレス確認を有効にしているか
- パスワードリセットのリダイレクト先を自サイトに限定しているか
- ログイン試行回数の制限が働いているか
- トークンをlocalStorageに長期間保存していないか
データベースの行単位の権限設定
Supabaseのようにフロントエンドから直接データベースへアクセスする構成では、RLS（Row Level Security）の設定が生命線です。RLSが無効なテーブルは、公開キーさえあれば誰でも全件を読み書きできる状態になります。
管理者権限を持つservice_roleキーのような秘密鍵は、サーバー側だけで使います。クライアントのコードに含めた時点で、ブラウザの開発者ツールから誰でも取り出せると考えてください。
💬 編集部コメント
RLSは「テーブルを作ったあとで有効にする」運用だと漏れがちです。テーブル作成のマイグレーションにRLSの有効化とポリシーをセットで書く習慣にすると、抜けを防ぎやすくなります。
🛡️ 公開中のサイトの設定、外から確認してみませんか
ローンチガードはURLを入れるだけで、HTTPS・セキュリティヘッダー・法令表記など26項目を自動でチェックします。自分では気づきにくい抜けを洗い出すのに役立ちます。
無料で診断してみる →インフラ・公開設定のセキュリティ対策
コードが安全でも、デプロイ時の設定で穴が空くことがあります。VercelやCloudflare Pagesなどのホスティングは多くを自動化してくれますが、開発者が決めるべき設定も残っています。
環境変数とシークレットの管理
APIキーの漏えいは、主に3つの経路で起きます。いずれも一度起きると、キーの再発行と影響調査が必要になります。
- .envファイルをGitにコミットしてしまう
- NEXT_PUBLIC_などの公開用接頭辞を秘密鍵に付けてしまう
- ビルド後のJavaScriptにキーが埋め込まれたまま配信される
.gitignoreの確認に加え、GitHubのシークレットスキャンを有効にしておくと、誤ってプッシュした場合にも気づけます。
HTTPSとセキュリティヘッダーの設定
主要なホスティングではHTTPSが標準で有効になります。そのうえで、ブラウザに安全な動作を指示するセキュリティヘッダーを追加すると、クリックジャッキングやXSSの被害を抑えられます。
| ヘッダー | 役割 | 設定例 |
|---|---|---|
| Strict-Transport-Security | HTTPSでの接続を強制 | max-age=31536000; includeSubDomains |
| X-Frame-Options | 他サイトへの埋め込みを防止 | DENY |
| X-Content-Type-Options | MIMEタイプの推測を禁止 | nosniff |
| Content-Security-Policy | 読み込めるスクリプトの出どころを制限 | default-src 'self' |
| Referrer-Policy | 外部へ送るURL情報を制限 | strict-origin-when-cross-origin |
依存パッケージとCORSの設定
npm auditやGitHubのDependabotを使うと、既知の脆弱性を含むパッケージを自動で検出できます。個人開発ではプルリクエストの自動作成まで設定しておくと、更新が滞りにくくなります。
APIを公開する場合は、CORSのAccess-Control-Allow-Originに「*」を指定したままになっていないかも確認してください。認証付きのAPIでは、許可するオリジンを自分のドメインに限定するのが基本です。
自動監査で見えた個人開発サイトのセキュリティ対策の傾向
ローンチガードでは、リリース前後の個人開発サイトを外部から自動でチェックしてきました。その中で、コードの脆弱性より「公開設定の抜け」のほうが目立つという傾向が見えています。
抜けやすいのはセキュリティヘッダー
HTTPS自体はほとんどのサイトで有効になっています。一方で、HSTSやX-Frame-Options、CSPといったヘッダーは、未設定のまま公開されているサイトが少なくありません。
ホスティングが自動で付けてくれると思い込み、実際のレスポンスを確認していないことが主な原因と考えられます。設定ファイル1つで直せるため、もっとも費用対効果の高い対策の1つです。
セットで抜けやすいセキュリティと法令表記
ヘッダーが未設定のサイトでは、プライバシーポリシーや特定商取引法の表記も不足している傾向があります。公開前の確認項目を持っていないと、技術面と法務面の両方で抜けが出やすくなります。
よく見られる組み合わせは次のとおりです。
- アクセス解析を入れているのにプライバシーポリシーに記載がない
- 決済を導入しているのに特定商取引法に基づく表記がない
- お問い合わせフォームがHTTPのページから送信される
💬 編集部コメント
ブラウザの開発者ツールでNetworkタブを開き、トップページのレスポンスヘッダーを一度眺めるだけでも発見があります。「設定したつもり」が反映されていないケースは想像以上に多いです。
やりすぎないセキュリティ対策の基本方針
個人開発で完璧なセキュリティを目指すと、開発そのものが止まってしまいます。大切なのは、守る範囲を決めたうえで、限られた時間を効果の大きい対策に使うことです。
想定する脅威の範囲の決め方
自動スキャンや機械的な不正アクセス、よくある脆弱性を突く攻撃は想定に入れます。国家レベルの標的型攻撃のように、個人で防ぎきれない脅威は想定の外に置くと判断しやすくなります。
1か所の破綻に備える多層防御
API側の認可チェック、認証サービスのトークン検証、データベースのRLSというように、層ごとに役割を分けておきます。どこか1つにミスがあっても、次の層で被害を止められる構成です。
リリース前のセキュリティ対策チェックリスト
ここまでの内容を、公開前に確認できるチェックリストにまとめました。すべてを一度に満たす必要はありませんが、上から順に確認すると重要度の高いものから潰せます。
開発・実装フェーズの確認項目
コードを書く段階で確認しておきたい項目です。後から直すほど手間が増えるため、機能ができた時点で見直します。
| 項目 | 確認のしかた |
|---|---|
| 他人のデータにアクセスできない | 別アカウントでIDを書き換えて試す |
| 入力値をサーバー側で検証している | APIに直接不正な値を送る |
| RLSが全テーブルで有効 | 管理画面でテーブルごとに確認 |
| 秘密鍵がクライアントに含まれていない | ビルド成果物をキー名で検索 |
デプロイ・公開後フェーズの確認項目
本番環境に出したあとは、外から見た状態を確認します。自分の環境ではなく、実際に配信されているレスポンスを基準にするのがポイントです。
- HTTPSにリダイレクトされ、HSTSが付いているか
- セキュリティヘッダーがレスポンスに含まれているか
- エラー画面に内部情報が表示されないか
- Dependabotなどの更新通知が有効になっているか
- プライバシーポリシーなど法令表記が公開されているか
💬 編集部コメント
チェックリストは公開時の1回だけでなく、大きな機能追加のたびに見直すのがおすすめです。新しいテーブルや外部サービスを足したタイミングで、設定の抜けが生まれやすくなります。
個人開発のセキュリティ対策に関するよくある質問
個人開発者からよく寄せられる疑問をまとめました。迷ったときの判断材料にしてください。
セキュリティ対策にどれくらい時間をかけるべき？
この記事で紹介した基本項目であれば、既存のサービスを使う前提で数時間から1日程度で一通り確認できます。ユーザー情報や決済を扱う場合は、その部分に重点的に時間を割くとよいでしょう。
AIで書いたコードはセキュリティリスクが高い？
AIが生成するコードは動作を優先しがちで、認可チェックや入力検証が省かれることがあります。生成後に「このAPIは他人のデータを返さないか」とAI自身にレビューさせるのも、手軽な確認方法の1つです。
無料で使える診断ツールはある？
依存パッケージはnpm auditやDependabot、公開サイトの設定はブラウザの開発者ツールや外部診断ツールで確認できます。本格的な脆弱性診断が必要な規模になったら、IPAの「安全なウェブサイトの作り方」も参考になります。
まとめ
個人開発のセキュリティ対策の基本は、アクセス制御と入力値の扱いを最優先にし、認証やデータベースの権限は実績ある仕組みに任せることです。そのうえで環境変数の管理とセキュリティヘッダーの設定を済ませれば、よくある被害の多くを防げます。
完璧を目指すより、守る範囲を決めて多層で備え、公開後も定期的に外から確認する運用が長続きします。まずはリリース前のチェックリストから、できるところを1つずつ進めてみてください。