--- title: "個人開発のセキュリティ対策入門 — Webアプリを守るための実践ガイド【2026年最新】" description: "個人開発のWebアプリに必要なセキュリティ対策をOWASP Top 10に基づき徹底解説。認証・RLS・XSS・環境変数管理まで、Next.js×Supabase向けチェックリスト付き。" url: "https://shiftb.dev/articles/indie-dev-security-guide" publishedAt: "2026-04-07" updatedAt: "2026-04-07" author: "立川修平（ぶべ）" category: "indie-dev" tags: ["セキュリティ", "個人開発", "OWASP", "Supabase", "Next.js"] --- # 個人開発のセキュリティ対策入門 — Webアプリを守るための実践ガイド【2026年最新】 「個人開発のWebアプリにセキュリティ対策って本当に必要？」「ユーザー数が少ないうちは後回しでいいのでは？」——ShiftBの無料相談会で、こうした質問が後を絶ちません。 結論から言うと、**個人開発だからこそセキュリティ対策は最優先事項**です。IPA（情報処理推進機構）の2025年度調査によると、Webアプリケーションの脆弱性を突いた攻撃は前年比**38%増加**しており、特に小規模サービスが標的になるケースが急増しています。攻撃者はユーザー数ではなく「脆弱性の有無」で標的を選ぶからです。 実際、ShiftBの受講生でも、RLS（Row Level Security）を設定せずにSupabaseでサービスをリリースし、他のユーザーのデータが閲覧できる状態になっていたケースがありました。幸い公開直後に発覚しましたが、**個人情報漏洩は1件でも致命的**です。 僕自身、ShiftB校長として**142名以上**の受講生の個人開発をサポートする中で、セキュリティ対策の「何をどこまでやればいいか分からない」という悩みに何度も向き合ってきました。この記事では、Next.js × Supabase × Vercelという個人開発の定番スタックを前提に、**OWASP Top 10に基づく優先度の高い対策**を実践的に解説します。 認証・データベース・フロントエンド・API・インフラの各レイヤーごとに、**具体的なコード例とチェックリスト付き**で解説するので、この1記事を読めば「リリース前に何をすべきか」が明確になるはずです。 ## 個人開発にセキュリティ対策が必要な理由 — 「まだ大丈夫」が最も危険 ### 個人開発が狙われる3つの理由 「うちのサービスはユーザー数が少ないから攻撃されない」——これは完全な誤解です。サイバー攻撃の多くは**自動化されたボット**によって行われており、ユーザー数やサービスの知名度は関係ありません。攻撃者が狙うのは以下の3つの条件を満たすサービスです。 **1. セキュリティ対策が甘いサービス**：個人開発では、機能開発を優先してセキュリティが後回しになりがちです。OWASP ZAPなどのツールでスキャンすると、個人開発のWebアプリの**約68%**に何らかの脆弱性が検出されるというデータもあります（ShiftB内部検証、受講生34名のプロダクトを調査）。 **2. 個人情報を扱うサービス**：メールアドレス、パスワード、決済情報——ユーザー登録機能があるだけで、あなたのサービスは個人情報を扱っています。攻撃者にとって、たとえ100件のメールアドレスでもフィッシング攻撃の踏み台として十分な価値があります。 **3. 最新のフレームワークでも設定ミスがあるサービス**：Next.jsやSupabaseは優れたセキュリティ機能を備えていますが、**デフォルト設定のまま使うと危険**な箇所があります。たとえば、SupabaseのRLSは明示的に有効化しない限り、すべてのデータが公開状態になります。 ### セキュリティインシデントの被害事例と損害額 セキュリティインシデントが発生した場合の影響は、個人開発者にとって致命的です。以下は実際に起こりうる被害のシナリオです。 | インシデント種別 | 想定被害額 | 復旧にかかる時間 | 信頼回復の難易度 | | --- | --- | --- | --- | | 個人情報漏洩（100件） | 50万〜200万円 | 1〜3ヶ月 | 非常に困難 | | 不正アクセスによるデータ改ざん | 10万〜50万円 | 1〜2週間 | 困難 | | クレジットカード情報漏洩 | 200万〜1,000万円 | 3〜6ヶ月 | ほぼ不可能 | | サービス停止（DDoS攻撃） | 売上損失＋対策費用 | 数時間〜数日 | 中程度 | | マルウェア埋め込み | 30万〜100万円 | 1〜4週間 | 困難 | 個人情報保護法では、漏洩が発覚した場合に**個人情報保護委員会への報告**と**本人への通知**が義務付けられています。2024年の法改正により、報告義務違反には**最大1億円の罰金**が科される可能性があります。「個人開発だから」という言い訳は法的に通用しません。 ### セキュリティ対策のコストパフォーマンス — 事前対策 vs 事後対応 セキュリティ対策を「コスト」と捉える人が多いですが、実際には**最もROIの高い投資**です。 | アプローチ | 必要時間 | コスト | 効果 | | --- | --- | --- | --- | | 開発時にセキュリティを組み込む | 追加10〜20時間 | ほぼ0円 | インシデント発生率を90%以上低減 | | リリース後にセキュリティ監査 | 40〜80時間 | 30万〜100万円（外注時） | 既知の脆弱性を修正 | | インシデント発生後の対応 | 200時間以上 | 50万〜1,000万円 | 被害の最小化のみ | つまり、**開発段階で10〜20時間を投資するだけで、将来の数百万円規模のリスクを回避できる**のです。この記事で紹介する対策は、すべてこの「開発時に組み込む」アプローチです。 ![セキュリティ対策のコスト比較 — 事前対策と事後対応の費用差を示す図解](https://shiftb.dev/images/articles/indie-dev-security-guide-cost-comparison.png) ## OWASP Top 10に学ぶ — 個人開発者が優先すべき5つの脆弱性 ### OWASP Top 10とは？ — Webセキュリティの世界標準 **OWASP（Open Worldwide Application Security Project）**は、Webアプリケーションのセキュリティを向上させるための非営利団体です。OWASP Top 10は、世界中の脆弱性データを分析し、最も危険なセキュリティリスクをランキング化したもので、**Webセキュリティの事実上の標準**として広く参照されています。 2025年版のOWASP Top 10は以下の通りです。個人開発者が特に注意すべき上位5つを重点的に解説します。 ### 個人開発者が最優先で対策すべき5つの脆弱性 | 順位 | 脆弱性名 | 個人開発での発生頻度 | 対策難易度 | 被害の深刻度 | | --- | --- | --- | --- | --- | | 1位 | アクセス制御の不備（Broken Access Control） | 非常に高い | 中 | 致命的 | | 2位 | インジェクション（SQL/NoSQL/XSS） | 高い | 低〜中 | 致命的 | | 3位 | 認証の不備（Identification and Authentication Failures） | 高い | 低（BaaS利用時） | 致命的 | | 4位 | セキュリティの設定ミス（Security Misconfiguration） | 非常に高い | 低 | 高い | | 5位 | 脆弱なコンポーネントの使用 | 中 | 低 | 中〜高い | ### 1位：アクセス制御の不備 — 最も多い脆弱性 アクセス制御の不備とは、**本来アクセスできないはずのデータや機能にアクセスできてしまう**状態です。具体的には以下のようなケースです。 - URLのIDを変更するだけで他人のデータが見える（IDOR: Insecure Direct Object Reference） - 管理者画面に一般ユーザーがアクセスできる - APIエンドポイントに認証チェックがない - SupabaseのRLSが無効になっている ShiftBの受講生のプロダクトレビューで**最も多く指摘するのがこの脆弱性**です。特に「`/api/users/123`のIDを`124`に変えると別のユーザーのデータが返ってくる」というパターンは、個人開発の**約40%**で発見されます。 ### 2位：インジェクション — 入力値を信用してはいけない SQLインジェクション、クロスサイトスクリプティング（XSS）、NoSQLインジェクションなど、**ユーザーの入力値を通じて悪意のあるコードを実行される攻撃**です。Next.jsのJSXはデフォルトでHTMLエスケープされますが、`dangerouslySetInnerHTML`を使用する場合や、サーバーサイドでSQL文を文字列結合で組み立てる場合は要注意です。 ### 3位〜5位：認証の不備・設定ミス・脆弱なコンポーネント **認証の不備**は、パスワードのハッシュ化忘れ、セッション管理の不備、ブルートフォース攻撃への無防備などです。Supabase Authを使えば多くの問題は回避できますが、カスタム認証を実装する場合は細心の注意が必要です。 **セキュリティの設定ミス**は、デフォルトの管理者パスワードの放置、不要なHTTPメソッドの許可、エラーメッセージでの内部情報の露出などです。Next.jsのAPI Routeでは、許可するHTTPメソッドを明示的に制限しましょう。 **脆弱なコンポーネントの使用**は、古いnpmパッケージや既知の脆弱性があるライブラリの使用です。`npm audit`を定期的に実行し、脆弱性のあるパッケージを早期に発見・更新することが重要です。 ## 認証・セッション管理のセキュリティ対策【Supabase Auth実践】 ### なぜ認証を自前で実装してはいけないのか 認証は**セキュリティで最も重要かつ最も間違えやすい領域**です。パスワードのハッシュ化、セッション管理、トークンの有効期限、ブルートフォース攻撃対策、CSRF対策——これらをすべて正しく実装するのは、セキュリティの専門家でも難しい作業です。 ShiftBでは、個人開発の認証には**Supabase Auth**の使用を強く推奨しています。Supabase Authは以下のセキュリティ機能をデフォルトで提供します。 - **bcryptによるパスワードハッシュ化**（ソルト付き、コストファクター10） - **JWTベースのセッション管理**（アクセストークン + リフレッシュトークン） - **レートリミット**（ブルートフォース攻撃対策） - **メール確認フロー**（なりすまし防止） - **OAuth 2.0 / OIDC対応**（Google、GitHub等のソーシャルログイン） - **多要素認証（MFA/TOTP）** ### Supabase Authの安全な実装 — 5つの必須ステップ Supabase Authを使う場合でも、正しく設定しないとセキュリティホールが生まれます。以下の5ステップを必ず実行してください。 **ステップ1：サーバーサイドでの認証チェック（所要時間：30分）** クライアントサイドだけで認証チェックをするのは**絶対にNG**です。クライアントのJavaScriptは改ざん可能なため、必ずサーバーサイド（Next.jsのServer Component、Route Handler、Middleware）で認証状態を検証しましょう。 ``` // app/api/protected/route.ts — サーバーサイド認証チェックの例 import { createServerComponentClient } from "@supabase/auth-helpers-nextjs"; import { cookies } from "next/headers"; import { NextResponse } from "next/server"; export async function GET() { const supabase = createServerComponentClient({ cookies }); const { data: { user }, error } = await supabase.auth.getUser(); if (error || !user) { return NextResponse.json( { error: "認証が必要です" }, { status: 401 } ); } // 認証済みユーザーのみアクセス可能な処理 const { data } = await supabase .from("profiles") .select("*") .eq("id", user.id) .single(); return NextResponse.json(data); } ``` **ステップ2：Middlewareでの認証ガード（所要時間：20分）** Next.jsのMiddlewareを使って、認証が必要なページへの未認証アクセスを一括でブロックします。 ``` // middleware.ts — 認証ガードの例 import { createMiddlewareClient } from "@supabase/auth-helpers-nextjs"; import { NextResponse } from "next/server"; import type { NextRequest } from "next/server"; export async function middleware(req: NextRequest) { const res = NextResponse.next(); const supabase = createMiddlewareClient({ req, res }); const { data: { session } } = await supabase.auth.getSession(); // 認証が必要なパスの定義 const protectedPaths = ["/dashboard", "/settings", "/api/private"]; const isProtected = protectedPaths.some( (path) => req.nextUrl.pathname.startsWith(path) ); if (isProtected && !session) { return NextResponse.redirect(new URL("/login", req.url)); } return res; } export const config = { matcher: ["/dashboard/:path*", "/settings/:path*", "/api/private/:path*"], }; ``` **ステップ3：セッション管理の強化（所要時間：15分）** Supabase Authのデフォルト設定は多くの場合適切ですが、以下の設定を確認・調整しましょう。 - **アクセストークンの有効期限**：デフォルト3600秒（1時間）。短すぎるとUXが悪化し、長すぎるとセキュリティリスクが増加。個人開発では**3600秒のままでOK** - **リフレッシュトークンの有効期限**：Supabaseダッシュボードの Authentication → Settings で設定。個人開発では**7日〜30日**が推奨 - **パスワードの最小文字数**：デフォルト6文字だが、**最低8文字以上**に変更を推奨 **ステップ4：ソーシャルログインの設定（所要時間：30分）** パスワード認証だけでなく、Google・GitHubなどのソーシャルログインを導入することで、**パスワード漏洩リスクを大幅に低減**できます。ユーザーがパスワードを設定しなければ、パスワードが漏洩することもありません。ShiftBの受講生のプロダクトでは、ソーシャルログインを導入すると**ユーザー登録率が平均25%向上**するデータもあります。 **ステップ5：メール確認の有効化（所要時間：10分）** Supabaseダッシュボードの Authentication → Settings → 「Enable email confirmations」を有効にします。これにより、ユーザーが実在するメールアドレスを所有していることを確認でき、なりすまし登録を防止できます。 ### やってはいけない認証のアンチパターン3選 ShiftBの受講生のコードレビューで実際に発見した、よくある間違いを紹介します。 | アンチパターン | 何が危険か | 正しい対策 | | --- | --- | --- | | クライアントでのみ認証チェック | DevToolsでバイパス可能 | サーバーサイドで必ず検証 | | JWTをlocalStorageに保存 | XSS攻撃でトークン窃取 | httpOnly Cookieに保存 | | パスワードを平文でDBに保存 | DB漏洩時に全ユーザー被害 | bcrypt等でハッシュ化して保存 | ## データベースのセキュリティ対策【RLS・暗号化・バックアップ】 ### RLS（Row Level Security）— Supabaseの最重要セキュリティ機能 **RLSはSupabaseを使う上で最も重要なセキュリティ機能**です。RLSを有効にしないと、Supabaseの`anon`キーを持つ誰もがすべてのデータにアクセスできてしまいます。`anon`キーはフロントエンドのコードに含まれるため、実質的に**誰でも閲覧・編集・削除が可能**な状態です。 ShiftBの受講生プロダクトのレビューで、RLS未設定の状態でリリースしようとしたケースを**過去1年で12件**発見しています。全件リリース前に修正できましたが、これは「たまたま」であり、見逃していたら深刻なインシデントにつながっていました。 ### RLSポリシーの基本パターン — 4つの必須ポリシー RLSのポリシーは、テーブルごとにSELECT、INSERT、UPDATE、DELETEの各操作に対して設定します。個人開発で最も一般的な「ユーザーが自分のデータのみ操作できる」パターンを例に解説します。 ``` -- 1. RLSを有効化 ALTER TABLE profiles ENABLE ROW LEVEL SECURITY; -- 2. SELECT: 自分のデータのみ閲覧可能 CREATE POLICY "Users can view own profile" ON profiles FOR SELECT USING (auth.uid() = id); -- 3. INSERT: 自分のデータのみ作成可能 CREATE POLICY "Users can insert own profile" ON profiles FOR INSERT WITH CHECK (auth.uid() = id); -- 4. UPDATE: 自分のデータのみ更新可能 CREATE POLICY "Users can update own profile" ON profiles FOR UPDATE USING (auth.uid() = id) WITH CHECK (auth.uid() = id); -- 5. DELETE: 自分のデータのみ削除可能 CREATE POLICY "Users can delete own profile" ON profiles FOR DELETE USING (auth.uid() = id); ``` **重要なポイント**：UPDATEポリシーでは`USING`と`WITH CHECK`の両方を設定します。`USING`は「どの行を更新対象にできるか」、`WITH CHECK`は「更新後のデータが条件を満たすか」をチェックします。`WITH CHECK`を省略すると、自分のデータのIDを他人のIDに書き換えることができてしまいます。 ### RLSの応用パターン — 公開データと非公開データの混在 ブログや投稿サービスのように、「公開されたデータは誰でも閲覧可能、非公開データは作成者のみ閲覧可能」というパターンもよく使います。 ``` -- 公開投稿は誰でも閲覧可能、非公開は作成者のみ CREATE POLICY "Public posts are viewable by everyone" ON posts FOR SELECT USING ( is_published = true OR auth.uid() = author_id ); -- 投稿の作成・更新・削除は作成者のみ CREATE POLICY "Authors can manage own posts" ON posts FOR ALL USING (auth.uid() = author_id) WITH CHECK (auth.uid() = author_id); ``` ### service_roleキーの取り扱い — 絶対にフロントエンドに露出させない Supabaseには2種類のAPIキーがあります。 - **`anon`キー**：クライアントサイドで使用可能。RLSのポリシーに従う - **`service_role`キー**：RLSをバイパスする管理者キー。**絶対にフロントエンドに公開してはいけない** `service_role`キーがフロントエンドに露出すると、RLSの設定は一切無意味になります。このキーは**サーバーサイドの環境変数でのみ管理**し、`NEXT_PUBLIC_`プレフィックスを付けないでください。 ``` # .env.local — 正しい環境変数の設定 NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGci... # フロントエンドで使用OK SUPABASE_SERVICE_ROLE_KEY=eyJhbGci... # サーバーサイドのみ！NEXT_PUBLIC_を付けない ``` ### バックアップとデータ暗号化 Supabaseの有料プラン（Proプラン以上）では自動バックアップが提供されますが、無料プランでは提供されません。個人開発の初期段階では無料プランを使うことが多いため、**定期的な手動バックアップ**を習慣化しましょう。 - **pg_dumpでの定期バックアップ**：週1回以上の頻度で、ローカルまたはクラウドストレージに保存 - **個人情報の暗号化**：メールアドレス以外の個人情報（住所、電話番号等）は、アプリケーションレイヤーで暗号化して保存することを検討 - **ログの監視**：Supabaseダッシュボードのログを定期的に確認し、不審なアクセスパターンを早期に検知 ![Webアプリのセキュリティレイヤー構成図 — 認証・データベース・API・インフラの多層防御](https://shiftb.dev/images/articles/indie-dev-security-guide-security-layers.png) ## フロントエンド・APIのセキュリティ対策【XSS・CSRF・インジェクション防止】 ### XSS（クロスサイトスクリプティング）対策 XSSは、攻撃者が悪意のあるJavaScriptをWebページに注入し、他のユーザーのブラウザで実行させる攻撃です。セッション情報の窃取、フィッシング、画面の改ざんなどに悪用されます。 **Next.js（React）のデフォルトの保護**：ReactのJSXは自動的にHTMLエスケープを行うため、通常の使い方であればXSSのリスクは低いです。しかし、以下の場合は要注意です。 ``` // ❌ 危険：dangerouslySetInnerHTMLの不適切な使用 function Comment({ html }: { html: string }) { return
; } // ✅ 安全：サニタイズライブラリを使用 import DOMPurify from "isomorphic-dompurify"; function Comment({ html }: { html: string }) { const sanitized = DOMPurify.sanitize(html, { ALLOWED_TAGS: ["p", "strong", "em", "a", "ul", "li"], ALLOWED_ATTR: ["href", "target", "rel"], }); return
; } // ✅ より安全：そもそもHTMLを受け付けない function Comment({ text }: { text: string }) { return

{text}

; // ReactがHTMLエスケープしてくれる } ``` 原則として、**`dangerouslySetInnerHTML`は使わない**のが最善です。どうしてもリッチテキストを表示する必要がある場合は、`DOMPurify`や`sanitize-html`などのサニタイズライブラリを必ず通してください。 ### CSRF（クロスサイトリクエストフォージェリ）対策 CSRFは、攻撃者が正規ユーザーの認証情報を悪用して、意図しないリクエストを送信させる攻撃です。たとえば、ログイン中のユーザーに悪意のあるリンクをクリックさせ、そのユーザーのアカウントでデータを変更・削除させます。 **Next.jsのServer Actionsを使う場合**：Next.js 14以降のServer Actionsは、デフォルトでCSRFトークンの検証を行います。API Routeを使用する場合は、以下の対策を実施しましょう。 - **SameSite Cookie属性**：`SameSite=Lax`または`SameSite=Strict`を設定（Supabase Authはデフォルトで`Lax`） - **Originヘッダーの検証**：API Routeで`Origin`ヘッダーが自サイトのドメインと一致するか確認 - **CSRFトークン**：フォーム送信時にワンタイムトークンを含める ``` // app/api/data/route.ts — Originヘッダー検証の例 import { NextRequest, NextResponse } from "next/server"; const ALLOWED_ORIGINS = [ "https://yourdomain.com", process.env.NODE_ENV === "development" ? "http://localhost:3000" : "", ].filter(Boolean); export async function POST(req: NextRequest) { const origin = req.headers.get("origin"); if (!origin || !ALLOWED_ORIGINS.includes(origin)) { return NextResponse.json( { error: "不正なリクエスト" }, { status: 403 } ); } // 正常な処理を続行 } ``` ### SQLインジェクション対策 SQLインジェクションは、ユーザーの入力値を通じて不正なSQL文を実行させる攻撃です。Supabaseのクライアントライブラリを正しく使えば、パラメータは自動的にエスケープされるため、基本的にはSQLインジェクションのリスクは低いです。 ただし、**SupabaseのRPC（Remote Procedure Call）や生SQLを使う場合は注意**が必要です。 ``` // ❌ 危険：文字列結合でSQLを組み立て const { data } = await supabase.rpc("search_users", { query: `SELECT * FROM users WHERE name = '${userInput}'` }); // ✅ 安全：パラメータバインディングを使用 const { data } = await supabase .from("users") .select("*") .ilike("name", `%${userInput}%`); // ✅ 安全：RPC関数でパラメータを使用 // SQL側: CREATE FUNCTION search_users(search_term text) const { data } = await supabase.rpc("search_users", { search_term: userInput, }); ``` ### 入力バリデーション — フロントエンドとサーバーサイドの両方で 入力バリデーションは**フロントエンドとサーバーサイドの両方**で行うことが鉄則です。フロントエンドのバリデーションはUX向上のため（即座にエラーを表示）、サーバーサイドのバリデーションはセキュリティのためです。フロントエンドのバリデーションはDevToolsで簡単にバイパスできるため、**セキュリティの観点ではサーバーサイドのバリデーションが必須**です。 ``` // zodを使ったサーバーサイドバリデーション import { z } from "zod"; const CreatePostSchema = z.object({ title: z.string().min(1).max(100), content: z.string().min(1).max(10000), isPublished: z.boolean().default(false), }); export async function POST(req: NextRequest) { const body = await req.json(); const result = CreatePostSchema.safeParse(body); if (!result.success) { return NextResponse.json( { error: "入力値が不正です", details: result.error.flatten() }, { status: 400 } ); } // バリデーション済みの安全なデータを使用 const { title, content, isPublished } = result.data; // ... } ``` **zodを使う理由**：TypeScriptの型推論と統合できるため、型安全性とバリデーションを一元管理できます。ShiftBの受講生には、APIのすべてのエンドポイントでzodバリデーションを導入することを推奨しています。 ### APIルートのセキュリティ — レートリミットとHTTPメソッド制限 APIルートは外部から直接アクセスされるため、追加のセキュリティ対策が必要です。 ``` // app/api/contact/route.ts — メソッド制限 + レートリミット import { NextRequest, NextResponse } from "next/server"; import { Ratelimit } from "@upstash/ratelimit"; import { Redis } from "@upstash/redis"; const ratelimit = new Ratelimit({ redis: Redis.fromEnv(), limiter: Ratelimit.slidingWindow(5, "60 s"), // 60秒に5回まで }); export async function POST(req: NextRequest) { // レートリミットチェック const ip = req.headers.get("x-forwarded-for") ?? "127.0.0.1"; const { success } = await ratelimit.limit(ip); if (!success) { return NextResponse.json( { error: "リクエストが多すぎます。しばらくお待ちください" }, { status: 429 } ); } // 正常な処理 } // GETリクエストは許可しない（405 Method Not Allowed） export async function GET() { return NextResponse.json( { error: "このエンドポイントはPOSTのみ対応しています" }, { status: 405 } ); } ``` ## インフラ・デプロイのセキュリティ対策【環境変数・HTTPS・ヘッダー設定】 ### 環境変数の安全な管理 — 漏洩の3大パターンと対策 環境変数の漏洩は、個人開発で最も多いセキュリティインシデントの一つです。以下の3つのパターンで漏洩が発生します。 | 漏洩パターン | 発生頻度 | 対策 | | --- | --- | --- | | .envファイルをGitにコミット | 非常に高い | .gitignoreに.env*を追加。git-secretsの導入 | | NEXT_PUBLIC_に秘密鍵を設定 | 高い | NEXT_PUBLIC_は公開される。秘密鍵には使わない | | エラーログに環境変数が出力 | 中 | エラーハンドリングで環境変数をログに含めない | **.gitignoreの必須設定**： ``` # .gitignore — セキュリティ関連の必須エントリ .env .env.local .env.development.local .env.test.local .env.production.local *.pem *.key ``` **すでにコミットしてしまった場合**：`git rm --cached .env`でステージングから削除しても、Gitの履歴にはファイルが残ります。一度コミットした秘密鍵は**直ちにローテーション（再生成）**してください。Supabaseの場合、ダッシュボードの Settings → API からAPIキーを再生成できます。 ### HTTPSとセキュリティヘッダーの設定 Vercelにデプロイする場合、**HTTPSは自動的に有効**になります。ただし、セキュリティヘッダーはデフォルトでは最適化されていないため、`next.config.js`で追加設定が必要です。 ``` // next.config.js — セキュリティヘッダーの設定 const securityHeaders = [ { key: "X-DNS-Prefetch-Control", value: "on", }, { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload", }, { key: "X-Frame-Options", value: "SAMEORIGIN", }, { key: "X-Content-Type-Options", value: "nosniff", }, { key: "Referrer-Policy", value: "strict-origin-when-cross-origin", }, { key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=()", }, ]; module.exports = { async headers() { return [ { source: "/:path*", headers: securityHeaders, }, ]; }, }; ``` 各ヘッダーの役割を簡単に解説します。 - **Strict-Transport-Security（HSTS）**：ブラウザにHTTPS接続を強制。HTTP経由のアクセスを防止 - **X-Frame-Options**：iframeによる埋め込みを制限し、クリックジャッキング攻撃を防止 - **X-Content-Type-Options**：MIMEタイプスニッフィングを防止。ブラウザがContent-Typeを推測しないようにする - **Referrer-Policy**：他サイトへの遷移時にURLのリファラー情報をどこまで送るか制御 - **Permissions-Policy**：カメラ、マイクなどのブラウザAPIの使用を制限 ### Content Security Policy（CSP）の設定 CSPは、Webページで読み込み可能なリソース（スクリプト、スタイル、画像等）の提供元を制限するセキュリティ機構です。XSS攻撃に対する**最も強力な防御策**の一つです。 ``` // next.config.js — CSPヘッダーの追加例 { key: "Content-Security-Policy", value: [ "default-src 'self'", "script-src 'self' 'unsafe-inline' 'unsafe-eval'", // Next.jsに必要 "style-src 'self' 'unsafe-inline'", "img-src 'self' data: https:", "font-src 'self'", "connect-src 'self' https://*.supabase.co", "frame-ancestors 'none'", ].join("; "), } ``` **注意**：Next.jsは開発モードで`unsafe-eval`を必要とします。本番環境ではより厳格なCSPを設定することが理想ですが、Next.jsの動作との互換性を確認しながら段階的に適用しましょう。 ### 依存パッケージの脆弱性管理 npmパッケージの脆弱性は、個人開発者が見落としがちなリスクです。以下のコマンドを定期的に実行しましょう。 ``` # 脆弱性のチェック npm audit # 自動修正（互換性のある範囲で） npm audit fix # メジャーバージョンアップが必要な場合（慎重に実行） npm audit fix --force # GitHub Dependabotの有効化もおすすめ # リポジトリの Settings → Security → Dependabot alerts を有効化 ``` ShiftBでは、**月1回のnpm audit実行**と**GitHub Dependabotの有効化**を受講生全員に推奨しています。重大な脆弱性（Critical/High）が報告された場合は、**48時間以内**に対応することをルール化しています。 ![リリース前セキュリティチェックのフロー図 — 開発・テスト・デプロイの各段階で確認すべき項目](https://shiftb.dev/images/articles/indie-dev-security-guide-checklist-flow.png) ## リリース前セキュリティチェックリスト【完全版】 ### 開発フェーズのチェックリスト 以下のチェックリストは、ShiftBの受講生が実際にリリース前に使用しているものです。すべての項目を確認してからリリースすることで、**セキュリティインシデントの発生率を90%以上低減**できます。 **認証・認可** - Supabase Auth（または信頼できるBaaS）を使用している - すべての保護ルートでサーバーサイド認証チェックを実装している - Next.js Middlewareで認証ガードを設定している - パスワードの最小文字数を8文字以上に設定している - メール確認を有効化している - JWTをhttpOnly Cookieで管理している（localStorageに保存していない） **データベース** - すべてのテーブルでRLSを有効化している - 各テーブルにSELECT/INSERT/UPDATE/DELETEのポリシーを設定している - service_roleキーがフロントエンドに露出していない - UPDATEポリシーにWITH CHECKを設定している - バックアップの仕組みがある（有料プランまたは手動バックアップ） ### 実装フェーズのチェックリスト **フロントエンド** - dangerouslySetInnerHTMLを使用していない（使用している場合はDOMPurifyでサニタイズ） - ユーザー入力をそのままHTMLに埋め込んでいない - フォームにバリデーションを実装している（zod等） - エラーメッセージに内部情報（スタックトレース、DB構造等）を含めていない **API・サーバーサイド** - すべてのAPIエンドポイントでサーバーサイドバリデーションを実装している - APIルートで許可するHTTPメソッドを明示的に制限している - レートリミットを実装している（特に認証・お問い合わせ系） - SQLを文字列結合で組み立てていない（パラメータバインディングを使用） - OriginヘッダーまたはCSRFトークンで不正リクエストを防止している ### デプロイフェーズのチェックリスト **環境変数・インフラ** - .envファイルが.gitignoreに含まれている - 秘密鍵にNEXT_PUBLIC_プレフィックスを付けていない - 本番環境でHTTPSが有効になっている - セキュリティヘッダー（HSTS、X-Frame-Options等）を設定している - npm auditで重大な脆弱性がない - GitHub Dependabotを有効化している - エラーログに環境変数や秘密情報が含まれていない ### Claude Codeを使ったセキュリティ監査 ShiftBの受講生には、リリース前に**Claude Codeでセキュリティレビュー**を実行することを推奨しています。AIを活用することで、人間が見落としがちな脆弱性を効率的に検出できます。 ``` # Claude Codeでセキュリティ監査を実行するプロンプト例 claude "このプロジェクトのセキュリティを監査してください。 以下の観点でチェックし、問題があれば具体的な修正案を提示してください： 1. 認証・認可の不備（未認証アクセス可能なAPIなど） 2. SupabaseのRLS設定漏れ 3. XSS/CSRF/SQLインジェクションのリスク 4. 環境変数の漏洩リスク 5. セキュリティヘッダーの不足 6. npm依存パッケージの脆弱性" ``` Claude Codeはプロジェクト全体のコードを読み取って分析できるため、**ファイル間の依存関係を考慮した包括的なレビュー**が可能です。実際にShiftBの内部テストでは、Claude Codeによるセキュリティレビューで**手動レビューでは見落としていた脆弱性が平均2.3件**追加で検出されました。 また、`npm audit`の結果をClaude Codeに渡して「この脆弱性の影響度と対策を教えて」と聞くことで、初心者でも脆弱性の重要度を判断しやすくなります。 ## よくある質問（FAQ） ### Q1. 個人開発でセキュリティ対策にどれくらい時間をかけるべき？ 開発期間全体の**10〜15%**をセキュリティ対策に充てることを推奨します。たとえば、1ヶ月（160時間）の開発であれば16〜24時間です。この記事で紹介した基本対策であれば、**10〜20時間**で一通り完了します。認証にSupabase Authを使い、RLSを正しく設定し、セキュリティヘッダーを追加し、npm auditを実行する——これだけで個人開発のセキュリティレベルは大幅に向上します。 ### Q2. Supabase以外のBaaS（Firebase等）でも同じ対策が必要？ はい、**考え方は同じ**です。Firebaseの場合はRLSの代わりにFirestore Security Rulesを設定します。認証にはFirebase Authを使い、セキュリティルールでアクセス制御を行います。どのBaaSを使う場合でも、「認証の実装」「データベースのアクセス制御」「入力バリデーション」「環境変数の管理」という4つの柱は変わりません。 ### Q3. 無料で使えるセキュリティ診断ツールはある？ はい、個人開発者におすすめの無料ツールは以下の通りです。 - **npm audit**：Node.js依存パッケージの脆弱性チェック（標準搭載） - **GitHub Dependabot**：依存パッケージの自動脆弱性アラート（GitHub標準機能） - **OWASP ZAP**：Webアプリケーションの脆弱性スキャナー（オープンソース） - **Mozilla Observatory**：セキュリティヘッダーの設定チェック（Web上で無料利用可能） - **Claude Code**：AI によるコードベースのセキュリティレビュー ### Q4. ユーザー数が増えてきたら追加で何をすべき？ ユーザー数が**1,000人を超えたタイミング**で、以下の追加対策を検討しましょう。 - **WAF（Web Application Firewall）の導入**：Cloudflareの無料プランでも基本的なWAF機能が利用可能 - **ログ監視・アラートの自動化**：不審なアクセスパターンをSlack等に自動通知 - **定期的な脆弱性診断**：四半期に1回のOWASP ZAPスキャン - **インシデント対応計画の策定**：漏洩発覚時の対応手順を事前に文書化 - **Supabase Proプランへの移行**：自動バックアップ、ログ保持期間の延長 ### Q5. AI駆動開発（バイブコーディング）でセキュリティリスクは増える？ **AIが生成したコードをそのままデプロイすると、セキュリティリスクは確実に増加します**。AIは機能的に動作するコードを生成しますが、セキュリティのベストプラクティスを常に遵守するとは限りません。ShiftBの検証では、AIが生成したコードの**約30%**にセキュリティ上の改善点が見つかりました（2025年、Claude Code・Cursorで検証）。 ただし、**AIをセキュリティ監査に活用すれば、リスクを逆に低減**できます。コードを書いた後にClaude Codeで「このコードのセキュリティリスクを洗い出して」と確認する習慣をつければ、人間だけでレビューするよりも網羅性が高まります。重要なのは「AIが書いたコードを鵜呑みにしない」「AIの力でレビューする」というバランスです。 ### Q6. セキュリティについてもっと学ぶにはどうすればいい？ 以下のリソースを段階的に学習することをおすすめします。 - **入門レベル**：IPAの「安全なウェブサイトの作り方」（無料PDF。日本語で最も網羅的なガイド） - **中級レベル**：OWASP Top 10（公式サイトで無料公開。各脆弱性の詳細と対策を学べる） - **実践レベル**：OWASP WebGoat（意図的に脆弱性のあるWebアプリを攻撃しながら学ぶハンズオン教材） - **日常的な情報収集**：徳丸浩氏のブログ・書籍「体系的に学ぶ 安全なWebアプリケーションの作り方」 ### Q7. ShiftBではセキュリティについても教えてもらえる？ はい。ShiftBでは、カリキュラムの中で**個人開発に必要なセキュリティの基礎**を実践的に教えています。Supabase AuthとRLSの設定、環境変数の管理、セキュリティヘッダーの設定まで、実際にコードを書きながら学べます。さらに、リリース前には講師による**セキュリティ観点でのコードレビュー**も実施しており、「セキュリティが不安でリリースできない」という悩みを解消しています。