WordPress

WordPressのようなCMS（コンテンツ管理システム）は、長年にわたりブログや企業サイトで広く使われてきた。しかし、近年その「セキュリティ設計の甘さ」が問題視されている。なぜCMSは脆弱になりやすいのか？本記事では、構造的な問題に焦点を当てて解説する。 よくあるCMS脆弱性の具体例 CMSの脆弱性は単に構造だけでなく、具体的な技術的ミスや攻撃ポイントに根ざしている。よくある脆弱性には次のようなものがある： 管理画面への総当たり（ブルートフォース）攻撃 プラグインのアップデート漏れによる既知脆弱性の放置 クロスサイトスクリプティング（XSS） データベースインジェクション（SQLi） これらはすべて、CMSが常に動的に動作し、かつ管理画面が公開されているという構造的特徴に起因している。 管理・表示・生成が同居する「一枚岩構成」 WordPressの典型的な構成は、以下のような「オールインワン型」だ： PHP + MySQL のLAMP環境 管理画面（/wp-admin）が公開サーバ上に存在 ページ生成はアクセス時にPHPでリアルタイム実行 つまり、「管理（入力）」「表示（出力）」「生成（ビルド）」の3機能がすべて1つの公開サーバで同時に動作している。この構成は利便性を優先する代わりに、セキュリティやスケーラビリティの面で明らかな犠牲を払っている。 公開サーバに管理画面がある不自然さ 管理画面が公開サーバに設置されているというのは、よく考えると不自然だ。攻撃者は、/wp-adminという予測しやすいURLを狙えば、管理インターフェースに直接アクセスできてしまう。仮にログイン試行を防げたとしても、「そこに管理画面がある」という事実自体がリスクを生む。 しかも、管理操作はPHP経由でDBを直接叩く構成であるため、脆弱なプラグインや設定ミスによって、システム全体への侵入経路になりうる。 リアルタイム生成のムダと脆弱性 WordPressは、アクセスのたびにPHPがHTMLを動的に生成し、DBにアクセスして内容を取得する。そのため、静的な内容であっても常に処理が走る。これは次のような問題を引き起こす： 負荷が高い：アクセスが増えるとサーバーがボトルネックになる 攻撃対象が広い：リクエストに応じて処理が走るため、DoS攻撃や脆弱性スキャンに弱い 静的なコンテンツであれば、ビルド時にHTMLを生成してCDNに載せるだけで済むはずなのに、それを「毎回動的にやる」というのは本質的に非効率かつ危険だ。 理想的な構成：管理・生成と表示の分離 ではどうすべきか？ひとつの解として、管理・生成サーバと表示サーバを完全に分離する構成がある： この構成の特徴： 管理画面やDBは公開されないネットワークに閉じ込める 静的HTMLをCI/CDでビルドして表示サーバにpush 表示サーバは静的ファイル配信のみを担当し、攻撃面積を最小化 セキュリティ上のベストプラクティスであるゼロトラスト原則やDMZ分離構成を取り入れることで、CMSに起因する大部分のリスクを構造的に排除できる。 CMS疲れからの脱却に向けて CMSの設計思想は「便利で何でもできる」ことにあったが、それゆえに「すべてが公開され、攻撃対象になる」というジレンマを抱えている。今こそ、構造的に堅牢なWeb構築を見直す時期に来ているのではないか。 SSG（静的サイトジェネレーター）やHeadless CMSといった手法は、このようなセキュリティ課題を根本から解決する構成を可能にする。CMS疲れに悩む人ほど、一歩引いてその構造を見直してみてほしい。 CMSとSSGの違いや、それぞれの特性を整理した以下記事もあわせてどうぞ。CMSに限界を感じたとき、どのような選択肢があるのかを俯瞰する第一歩として役立つはずだ。 SSGのすすめ ― CMS（WordPress）のセキュリティ対策にうんざりしてきたあなたに

10年前、「Webサイトを作るならWordPressだよ」と誰もが口を揃えて言っていた時代があった。管理画面が整っていて、テーマもプラグインも豊富、何よりレンタルサーバーに「3クリック」で導入できる。その利便性に惹かれて、当時は多くの個人・企業がWordPressを採用していた。 だが、2020年代も半ばに差し掛かり、改めて情報発信を始めようとしたとき、様子が違うことに気づく。「WordPress セキュリティ」で検索すると、出てくるのは不安を煽る記事ばかり。脆弱なプラグイン、放置されたテーマ、改ざん被害、管理画面への攻撃……。10年前の「常識」が、今やリスクの温床と化していたのだ。 CMS構成の「構造的な欠陥」 WordPressを始めとする従来型CMSの最大の問題点は、「表示」「管理」「生成」という3つの役割を1つのサーバーでまかなっている点にある。管理画面は公開URLの直下にあり、ページは毎回PHPとDBを叩いて生成され、攻撃者にとっては「やりがいのある」構成だ。セキュリティパッチの更新も頻繁で、更新のたびに表示が崩れるリスクと戦うことになる。 しかも、サーバーは常時PHPとMySQLを動かし、静的ページすらも“動的に”生成される。この構造のまま「表示速度」「安定性」「セキュリティ」をすべて満たすのは、もはや不可能に近い。 なお、CMS構成のこうした構造的リスクについては、以下の別記事にて、設計レベルから詳しく解説している。「なぜ管理画面が公開URLにあるのか？」「リアルタイム生成は本当に必要なのか？」といった素朴な疑問から、理想的な分離構成まで踏み込んで考察している。 CMSはなぜ脆弱なのか？　よくある攻撃例と設計上の欠陥を解説 Markdown + SSG + CDNという現代的解 そこで注目されるのが、**SSG（Static Site Generator）**という選択肢だ。SSGはあらかじめ記事をHTMLとして生成し、CDNで配信する。PHPもMySQLも要らない。表示は爆速、攻撃対象はほぼゼロ、コストは無料同然。さらにMarkdownで記事を書くため、装飾ではなく中身に集中できる。Gitとの親和性も高く、生成AIによる支援（構成案→記事化→整形）との相性も抜群だ。 なお、MarkdownとSSGの組み合わせがもたらす執筆効率の高さについては、以下の別記事で詳しく紹介している。装飾に煩わされず、思考と構造に集中できる執筆体験を、ぜひ知ってほしい。 SSG×Markdownで発信が劇的にラクになる理由 「思考の邪魔」をしない執筆体験 WordPressのGUI操作は、Markdownに慣れた者にとっては“地獄”に近い。太字にするだけでもボタンをクリックし、装飾の見た目がテーマ依存で変わってしまう。構造化されていない文書は、生成AIによる解析にも向かない。コンテンツの中身ではなく、見た目に気を取られた時点で、知的生産としては遠回りなのだ。 一方、Markdownは構造が明快で再利用しやすく、AIにも優しい。文章の意味と構造が分離されているため、自動処理・変換・連携もやりやすい。まさに「考えることに集中できる」執筆環境であり、今後の情報発信の主軸となるにふさわしい。 SSGを使うという“設計思想” SSGは単なるツールではなく、「セキュリティ設計」「コスト設計」「執筆思想」すべてに関わる選択である。構造的に堅牢で、表示高速、拡張も容易。そして何より「攻撃されにくい」という安心感がある。WordPressのように「防衛し続ける構成」ではなく、そもそも「狙われない構成」を作るべき時代になった。 CMSに疲れたすべての人にこそ、SSGという選択肢を知ってほしい。いま、Web発信の構造は、大きく変わろうとしている。