「JamstackはWordPressより安全」とよく言われます。ブラキオのブログでも、なぜJamstackはセキュアと言われるのか？WordPressとの比較と対策で、その理由を紹介しました。

ただ、実際にサイトを運用していると、次のような疑問が出てきます。

• 不正アクセスされていないか、どこを見れば確認できるのか
• 攻撃されるとしたら、どこから入られるのか
• CMSのAPIキーが漏れたら、個人情報まで盗まれるのか

この記事では、弊社のサイトと同じ「microCMS × Next.js（静的書き出し）× Netlify」の構成を例に、これらの疑問に答えます。

Jamstackで「なくなる」攻撃と「残る」攻撃

Next.jsで静的に書き出したサイトは、ビルドのときにHTMLを作り、Netlifyなどのホスティングサービスから配信します。アクセスのたびに動くプログラムも、公開側のデータベースもありません。CMSの管理画面は、サイトとは別のドメインにあります。

そのため、WordPressで典型的な次のような攻撃は、構造上成り立ちません。

• 管理画面のログインページへの総当たり
• プラグインやテーマの脆弱性を突いた侵入
• データベースを狙ったSQLインジェクション

/wp-login.php を探して回る自動スキャンが来ても、404が返るだけです。

ただし、リスクがゼロになるわけではありません。攻撃の的が「サイト」から「アカウント」と「ビルド」に移る、と考えるのが正確です。

なお、Next.jsでもSSRやAPIルートを使ってサーバーを動かす構成では、話が変わります。2025年3月には、Next.jsのミドルウェアで行っている認可チェックを、特定のリクエストヘッダーを付けるだけで素通りできる脆弱性（CVE-2025-29927）が公表されました。同年12月には、React Server Componentsのサーバー関数に細工したリクエストを送ると、認証なしで任意のコードを実行できる脆弱性（CVE-2025-55182、通称「React2Shell」）が公表され、実際に悪用も確認されています。静的に書き出したサイトではミドルウェアもサーバー関数も動かないため、こうしたサーバー側の脆弱性の影響を受けません。

攻撃者はどこから入ってくる？

Jamstackサイトで現実的な経路は、次の4つです。

※「起きやすさ」は、弊社の運用経験からの目安です。

1. アカウントの乗っ取り

いちばん起きやすい経路です。守るべきアカウントは、CMS・ホスティング・GitHubの3つだけではありません。

• その3つにログインするためのメールアカウント（取られると、パスワードを再設定されてしまう）
• ドメインのレジストラとDNS
• Googleアナリティクスなど、サイトにタグを入れているサービス

手口は、フィッシングやパスワードの使い回しが中心です。最近は、PCに入り込んだマルウェア（インフォスティーラー）がログイン中のセッションを盗み、二段階認証をすり抜ける手口も増えています。

2. npmパッケージのサプライチェーン攻撃

自分たちのアカウントが無事でも起きる経路です。乗っ取られるのは、依存しているパッケージの作者のアカウントです。

2025年9月8日には、chalkやdebugといった広く使われている18のパッケージに、不正なバージョンが公開されました。作者のnpmアカウントが、npm公式を装った偽ドメインからの「二段階認証の再設定」メールでフィッシングされたのが原因です。仕込まれたコードはブラウザ上で動き、暗号資産の送金先を攻撃者のものに書き換えるものでした。不正なバージョンは約2時間で取り下げられましたが、その間にビルドしたサイトには、配信するJavaScriptに不正なコードが紛れ込んだ可能性があります。

同じ月には、インストール時に開発者のPCやCIからnpm・GitHub・クラウドの認証情報を盗み、盗んだnpmトークンで同じ作者の他のパッケージにも自動で感染を広げるワーム（Shai-Hulud）が見つかりました。11月には第2波（Shai-Hulud 2.0）が始まり、被害パッケージは数百から千以上に広がっています。

このように、不正なコードはビルドのときに動いて環境変数に置いたAPIキーを盗むこともあれば、配信するJavaScriptに紛れ込んで訪問者のブラウザで動くこともあります。

3. CMSの本文に仕込まれたスクリプト

CMSの本文をHTMLとしてそのまま表示する作りだと、CMSに書き込める人は誰でもスクリプトや、画像タグのイベント属性に仕込んだコードを入れられます。乗っ取られたアカウントだけでなく、正規の編集者が外部サイトからコピーした埋め込みコードを貼ってしまうケースもあります。

静的に書き出すサイトでは、本文がビルドのときにHTMLファイルへ書き込まれます。そのため、ページを開いた時点でスクリプトが実行されます。

4. 書き込み権限のあるAPIキーの漏洩

APIキーは、Gitの履歴やチャット、ビルドログ、メンバーのPCなどから漏れます。読み取り専用のキーなら書き換えはできませんが、書き込み権限があれば、APIから記事を書き換えられます。

APIキーが漏れたら、個人情報まで盗まれる？

多くの場合、問い合わせてきた人の個人情報は盗まれません。

お問い合わせフォームの入力は、Netlify Formsなどのフォームサービスに保存されることが多く、CMSには入っていないからです。CMSにあるのは、ブログ記事や会社情報など、もともとサイトで公開している内容が中心です。

ただし、キーの権限によっては、公開していない情報も取れます。

• 下書きや公開を終えたコンテンツ（APIキーに「下書き全取得」の権限を付けている場合）
• CMSには入れているが、サイトには表示していない項目
• アップロードしたメディアの一覧（マネジメントAPIの権限を付けている場合）

microCMSのAPIキーは、サービス全体に適用される「デフォルト権限」と、APIごとの「個別権限」で、GET / POST / PUT / PATCH / DELETE を個別に設定できます。作成・編集ができるのは管理者だけです。

さらに、書き込み権限があるキーなら、前の章の「CMSの本文に仕込まれたスクリプト」を使って、これから訪問者が入力する情報を盗むこともできます。

ビルドで使うAPIキーは、読み取り（GET）だけにしておきましょう。

「ブログしかないから、改ざんされても痛くない」は本当？

CMSに個人情報がないなら、書き換えられても大した被害はない。そう思われるかもしれません。しかし、被害はデータではなく、会社の信用とサイトの訪問者に出ます。

• 訪問者を攻撃する踏み台にされる：会社のドメインの上で、偽の入力フォームを出したり、詐欺サイトへ誘導したりできます。被害を受けるのは見込み客です。
• SEOスパムを埋め込まれる：見えないリンクやスパムページを仕込まれる「日本語キーワードハッキング」が典型です。Googleに検出されると、検索結果に警告が出たり、順位が下がったりします。回復には時間がかかります。
• 嘘の情報を載せられる：会社の住所や代表者、実在する取引先の名前を使った偽の実績、偽のお知らせなど。取引先とのトラブルにもつながります。
• 全部消される：削除の権限があれば、記事も実績も消せます。バックアップがなければ戻せません（関連記事：そのJamstackサイト、データが消えても戻せますか？）。
• 気づくのが遅れる：見た目を変えずに隠しリンクだけを入れられると、誰も気づかないまま公開され続けます。

企業サイトは「会社の顔」です。改ざんされたという事実だけで、問い合わせや採用への影響は小さくありません。

不正アクセスはどこで確認する？

静的なサイトには、侵入されるサーバーがありません。見るべきなのは、サイトのアクセスログよりも、各サービスの管理画面です。

microCMS

• メンバー：知らないメンバーや、不要な管理者がいないか
• APIキー：キーごとの権限。書き込み権限が付いていないか
• コンテンツの履歴：誰がいつ変更したか
• Webhook：知らない送り先が追加されていないか
• APIの利用状況：リクエスト数が急に増えていないか（キーが漏れたサイン）
• 監査ログ（Enterpriseプラン限定）：管理画面での操作とAPI経由の操作を記録。「サービス設定」＞「データログ」＞「監査ログ」から管理者だけが確認できます

Netlify

• デプロイの履歴：身に覚えのないデプロイ（CLIや手動アップロード、知らないコミットから）がないか
• チームの監査ログ（Pro以上。Proは直近7日分、Enterpriseは全期間）：メンバーの追加や、設定・環境変数の変更
• Build hooks：知らないフックがないか
• 個人のアクセストークンや、連携しているアプリ

GitHub

• セキュリティログ（個人）、監査ログ（Organization）
• コラボレーター、デプロイキー、Webhook
• ブランチの保護ルール
• Dependabotのアラート

Google Search Console

• 「セキュリティの問題」レポート：改ざんやマルウェアをGoogleが検出すると、ここに表示されます。外から改ざんに気づく手段として、登録しておきましょう。

先にやっておきたい対策

• 関係するすべてのアカウントで二段階認証を有効にする（CMS・ホスティング・GitHub・メール・ドメイン・計測タグ）
• ビルド用のAPIキーを読み取り専用にする
• CMSの本文を表示する前にサニタイズする（埋め込みに使うタグだけを許可する）
• 本番に反映されるブランチを保護し、レビューなしでは変更できないようにする
• lockfileで依存パッケージのバージョンを固定し、公開されたばかりの新しいバージョンはすぐに取り込まない
• 退職者や契約が終わった外注先のアカウントを、定期的に棚卸しする
• Google Search Consoleに登録し、通知を受け取れるようにする

まとめ

Jamstackは、サイトそのものを外から突かれるリスクを大きく減らせる構成です。一方で、守る対象がなくなるわけではありません。攻撃の的は、アカウントとビルドに移ります。

裏を返せば、二段階認証やAPIキーの権限、依存パッケージの管理といった運用の基本を押さえれば、Jamstackの安全性をしっかり活かせます。

ブラキオでは、Jamstackサイトの制作だけでなく、公開後の保守・運用もお手伝いしています。「今のサイトの設定が安全か確認したい」といったご相談も、お気軽にお問い合わせください。