「WordPressの脆弱性対応に毎月追われている」——制作会社の保守担当から、よく聞く悩みです。更新を止めれば改ざんや乗っ取りの入り口が開き、更新すればプラグイン同士の相性で表示が崩れることもある。この負担そのものを構造で減らせるのが、Jamstack（静的サイト）という選び方です。ただし「静的だから絶対安全」ではありません。この記事では、なぜ攻撃対象が減るのかと、静的でも残るリスクへの対策を、実装者の視点で整理します。

なぜ攻撃対象領域が小さくなるのか

WordPressは、閲覧のたびにサーバーでPHPが動き、データベースから記事を組み立て、HTMLを返します。この「動く部分」こそ、攻撃者が狙う面です。データベース、PHPの実行環境、プラグイン、テーマ、公開された管理画面——それぞれが侵入口になりえます。

静的サイト（Jamstack）は、ここが根本的に違います。ページはあらかじめHTMLとして書き出しておき、配信時はそのファイルを返すだけ。閲覧のたびにサーバーでコードが動くわけではなく、データベースへの接続も発生しません。攻撃対象領域が減るのは、この構造から来ています。

WordPressと静的サイトの攻撃対象領域の違いを比較した図

WordPressの改ざん被害でよく見られるのは、更新が遅れたプラグインの既知の脆弱性、弱い管理者パスワード、非公式な配布元から入れたテーマ、といった経路とされています。静的サイトでは、そもそもプラグインや管理画面が公開側に存在しないため、これらの経路の多くが最初から閉じています。以前の記事「脱WordPressという選択」でも触れた、保守負担の軽さは、この構造の副産物です。

静的でも残るリスクと、その対策

とはいえ、静的にすればリスクがゼロになるわけではありません。攻撃の面が別の場所に移るだけ、と考えるのが正確です。ここは正直に書きます。

静的サイトでも残る4つのリスクと対策を示した図
  • クライアント側のJavaScript：ブラウザで動く処理は、誰でも開発者ツールで中身を読めます。ここに秘密の値やロジックを埋め込まない、が原則です。
  • 公開リポジトリのAPIキー流出：ソースコードをGitHubなどで公開する場合、鍵をコードに直書きすると危険です。公開リポジトリの秘密情報は自動化されたスキャンにすぐ拾われるとされており、鍵はコードから分離して環境変数などで管理します。
  • フォーム送信API：問い合わせフォームの送信先や、外部サービスの鍵は、ブラウザ側に置けば丸見えです。ここは後述のとおりサーバー側に隠します。
  • 依存パッケージの脆弱性：ビルドに使うライブラリに脆弱性が見つかることはあります。定期的な更新で塞ぐ運用は、静的サイトでも必要です。

鍵はブラウザに出さない — 自サイトの実装

「フォームの送信先APIをどう守るか」は、静的サイトで必ず出てくる論点です。静的ページ自体にサーバー処理はありませんが、送信の受け口だけは動く部分が要ります。

tsudzuri.com では、Cloudflare Workers を薄いサーバーとして挟んでいます。ブラウザから送られたフォームの内容はまず Worker が受け取り、メール送信や通知に使う鍵は Worker 側の環境変数（シークレット）に置いて、ブラウザには一切渡しません。閲覧者が見られるのは「Workerのエンドポイントに投げる」ところまでで、その先の鍵は隠れたままです。

あわせて、フォームには入力欄を装った罠（ハニーポット）と、送信までの時間を署名付きで確認する仕組みを入れ、機械的な連投をはじいています。この構成の背景は「EmDashをCloudflareにデプロイする」でも書きました。

// Worker側（擬似コード）：鍵はここにあり、ブラウザには出さない
export default {
  async fetch(request, env) {
    const data = await request.json();
    // env.MAIL_API_KEY はブラウザから見えない
    await sendMail(data, env.MAIL_API_KEY);
    return new Response("ok");
  },
};

こうして「動く部分」を送信の受け口だけに絞り、そこも鍵を隠すことで、攻撃の面を小さいまま保っています。

どう選ぶか

セキュリティの負担を構造から軽くしたい、頻繁に動的な処理は要らない——そういうサイトなら、静的・Jamstackは有力です。逆に、複雑な会員機能やリアルタイム性が中心なら、動的な構成のほうが素直なこともあります。この見極めと、WordPressからの移行手順は「WordPressからEmDashへ」も参考になります。

「うちのサイトはどちらが向くか」「保守の負担を減らせるか」を、現状を見ながら一緒に整理します。実装まで含めてご相談ください。お問い合わせはこちら。

本記事は2026年7月時点の情報です。各サービスの仕様やセキュリティの前提は変わることがあります。