WordPressの「ファイルパーミッション」最適化ガイド：セキュリティを守る正しい設定値と777のリスク

1. ファイルパーミッションの基本とセキュリティ上の役割

WordPress を構成するファイルやディレクトリ（フォルダ）には、それぞれ「誰が」「どのような操作をできるか」を定義する属性が付与されています。
これをファイルパーミッションと呼びます。
パーミッションを適切に管理することは、ウェブサイトの改ざんや機密情報の流出を未然に防ぐための、サーバー管理における最も基本的なセキュリティ対策の一つです。

ウェブサーバー上では、WordPress のプログラムを実行するユーザー、ファイルの所有者、そしてサイトを閲覧する一般ユーザーなど、複数の主体がファイルにアクセスします。
パーミッションの設定が不適切であると、本来変更を許可すべきでない第三者がファイルを書き換えたり、設定ファイルを盗み見たりすることが可能になります。
特に WordPress のように世界的にシェアの高い CMS では、自動化されたボットによる脆弱性の探索が恒常的に行われており、不適切なパーミッション設定は即座に攻撃の標的となります。

本記事では、WordPress.org の公式ドキュメントおよびサーバー管理の業界標準に基づき、各ファイルやディレクトリに適用すべき最適なパーミッション設定について解説します。

2. パーミッションを表す数字の仕組み

パーミッションは通常、「755」や「644」といった 3桁の数字で表現されます。
この数字を正しく理解することは、セキュリティ設定の第一歩となります。
それぞれの数字は「所有者（Owner）」「グループ（Group）」「その他（Others/Public）」の 3つのカテゴリーに対する権限を表しています。

2.1 3つの主体

左の数字（所有者）: ファイルを作成したユーザーや、サーバー上でファイルを管理するメインのアカウント。
真ん中の数字（グループ）: 所有者が属する特定のユーザーグループ。
右の数字（その他）: 上記以外のすべてのユーザー。
インターネットを通じてサイトを閲覧する一般ユーザーもここに含まれます。

2.2 数字と権限の計算

各桁の数字は、以下の 3つの権限の合計値で構成されます。

4: 読み取り（Read / r）
2: 書き込み（Write / w）
1: 実行（Execute / x）
0: 権限なし

例えば、「7」は 4 + 2 + 1（読み取り・書き込み・実行のすべて）を意味し、「5」は 4 + 0 + 1（読み取りと実行のみ）を意味します。
典型的な推奨値である「755」であれば、「所有者はすべてが可能、グループとその他は読み取りと実行（フォルダの中身を見るなど）のみが可能」という状態を指します。

3. なぜ「777」の設定は危険なのか

ファイルパーミッションにおいてすべての権限を解放する「777」は、かつての CGI プログラム（メールフォーム等）の設置や、古いサーバー環境でのトラブル解決策として、歴史的に「とりあえずの設定」として言及されることがありました。
しかし、現代の WordPress 運用環境（本番環境）において「777」を使用することは、意図的にセキュリティホールを作ることに等しく、極めて重大なリスクを招きます。

3.1 負の遺産としての「777」

かつてのサーバー環境や古い PERL スクリプト等では、プログラムがファイルに書き込むためにパーミッションを 777（あるいは 666）にするよう指示するマニュアルが一般的でした。
ウェブサイト制作の現場でこの習慣が残り、WordPress のメディアアップロードや自動更新の失敗（Permission denied）に遭遇した際、根本原因を解決する代わりに「一時的に 777 にして解決を図る」という誤った対処法が取られてしまうケースが依然として存在します。

3.2 全ユーザーへのフルアクセスの解放

「777」は、所有者、グループ、その他のすべての主体に対して「読み取り」「書き込み」「実行」の全権限を許可する設定です。
これは、同じサーバー内にアカウントを持つ他のユーザーや、ウェブサイトの脆弱性を突こうとする攻撃者に対しても、ファイルの編集や削除を許可していることを意味します。

3.3 改ざんとマルウェア設置の温床

攻撃者が WordPress の脆弱性やプラグインの不備を突いてサーバーに一時的にアクセスした場合、パーミッションが 777 になっているディレクトリがあれば、そこへ自由に不正なスクリプト（PHPファイルなど）を設置することが可能になります。
一度マルウェア（バックドア）を設置されると、攻撃者はその後いつでもサイトを操作できるようになり、会員情報の漏洩、詐欺サイトへのリダイレクト、SEOスパムの埋め込みといった深刻な被害へと繋がります。

3.4 共有サーバー環境でのリスク

特に安価な共有レンタルサーバー環境などでは、ディレクトリが 777 になっていると、同じサーバーを利用している他の契約者のスクリプトから、自分のサイトのファイルを書き換えられるリスクが生じる場合があります。
サーバーの構成にもよりますが、原則として 777 は「誰に対しても鍵を開け放している状態」であり、正規の運用において必要とされる場面は存在しません。
もし 777 に設定しなければ動作しないプラグインやテーマがある場合は、そのソフトウェア自体の設計や、サーバー構成に問題がある可能性を検討すべきです。

4. WordPress における推奨パーミッション設定

各ディレクトリやファイルは、WordPress が正常に動作するために必要な最小限の権限に絞り込むことが理想的です。
以下に、公式ドキュメント（Codex）およびセキュリティのベストプラクティスに基づく推奨値を示します。

4.1 ディレクトリ：755 または 750

WordPress のすべてのディレクトリ（フォルダ）は、原則として 755 または 750 に設定します。

755 (rwxr-xr-x): 所有者はすべてが可能、グループとその他は読み取りと実行が可能。
750 (rwxr-x—): 所有者はすべてが可能、グループは読み取りと実行が可能。
その他（全世界）からは一切のアクセスを許可しない。

多くのレンタルサーバー環境では、サーバーの処理プログラム（PHP）がディレクトリにアクセスし、画像などのファイルをアップロードするために、所有者に対して「書き込み」権限（数字の 2）が必要です。
一方で、第三者が勝手にディレクトリを作成したり削除したりすることを防ぐため、真ん中と右の数字（グループ・その他）には書き込み権限を与えないのが標準的な設定です。

4.2 ファイル：644 または 640

WordPress を構成する大部分の PHP ファイルや画像ファイルは、644 または 640 に設定します。

644 (rw-r–r–): 所有者は読み書きが可能、グループとその他は読み取りのみ可能。
640 (rw-r—–): 所有者は読み書きが可能、グループは読み取りのみ可能。
その他からはアクセス不可。

PHP ファイルを実行するのはサーバー側のインタプリタであり、ファイル自体に「実行（x）」権限を付与する必要はありません。
したがって、ファイルに 7（実行権限）が含まれる設定は不要であり、不適切なコード実行のリスクを低減させるためにも避けるべきです。

5. 特定の重要ファイルに対する厳格な設定

すべてのファイルに対して 644 を適用するだけでなく、サイトにとって極めて重要な機密情報を含む特定のファイルについては、より厳格なパーミッションを適用することが推奨されます。

5.1 wp-config.php：最も重要な防衛線

wp-config.php には、データベースの接続情報（ホスト名、データベース名、ユーザー名、パスワード）や、セキュリティキー（SALT）が含まれています。
このファイルが漏洩したり書き換えられたりすることは、サイトの支配権を奪われることに直結します。

推奨される設定値は以下の通りです。

600 (rw——-): 所有者だけが読み書き可能。
440 (r–r—–): 所有者とグループが読み取りのみ可能。
400 (r——–): 所有者だけが読み取り可能。

サーバーの構成（suPHP, FastCGI 等）によっては、600 または 400 に設定することで、意図しないユーザーやプログラムからのアクセスを完全に遮断できます。
ただし、設定を厳しくしすぎると一部のプラグインが設定を書き換えられなくなるため、400 を試してエラーが出る場合は 600、それでも不都合があれば 640 というように、環境に合わせて調整が必要です。

5.2 .htaccess：サーバー制御の要

Apache サーバーを使用している場合、.htaccess は URL のリダイレクトやセキュリティ制限（IP制限など）を司る重要なファイルです。

推奨値: 644 または 600

攻撃者はこのファイルを書き換えて、自分のページにアクセスしたユーザーを偽のフィッシングサイトへと転送しようとします。
手動でセキュリティ設定を固定した後は、パーミッションを 600 に下げることで、攻撃だけでなくプラグインによる意図しない設定上書きを防ぐ効果も期待できます。

5.3 wp-content ディレクトリ

プラグイン、テーマ、そしてアップロードされた画像が格納される wp-content は、外部からの書き込みが最も発生しやすい場所です。
基本はディレクトリ 755、ファイル 644 ですが、セキュリティプラグインの中には uploads フォルダ内で PHP ファイルの実行を禁止するなどの措置を講じるものもあります。
このディレクトリ内のパーミッションが緩んでいると、画像のアップロード機能を悪用して PHP ファイルを設置され、実行されてしまうリスクがあるため、定期的な確認が不可欠です。

6. パーミッションの変更方法

設定値を変更するための主な手段は、FTP/SFTP クライアント、サーバー管理パネル（cPanel等）、および SSH によるコマンドライン操作の 3種類があります。

6.1 FTP/SFTP クライアントによる変更

FileZilla や WinSCP などのツールを使用する場合、対象のファイルを右クリックして「ファイルパーミッション」や「属性の変更」を選択します。
そこで数字を入力するか、チェックボックスで権限を選択することで変更が完了します。
一度に多くのフォルダに対して階層的に（再帰的に）設定を適用できる機能もありますが、ディレクトリとファイルを一括で同じ設定（例：すべて 755）にしないよう注意が必要です。

6.2 コマンドライン（SSH）による変更

サーバーに SSH で直接接続できる場合、chmod コマンドを使用するのが最も効率的です。
以下のコマンド例は、カレントディレクトリ以下のディレクトリとファイルの権限を一括で修正するための代表的な手法です。

# すべてのディレクトリを 755 に設定
find . -type d -exec chmod 755 {} \;

# すべてのファイルを 644 に設定
find . -type f -exec chmod 644 {} \;

このように、種類（ディレクトリかファイルか）を判別して個別に設定を適用することが、誤設定を防ぐポイントです。

7. 「所有権（Ownership）」との重要な関係

パーミッションの数字（755 や 644 など）は、そのファイルの「所有者」が誰であるかという前提条件に強く依存します。

7.1 実行ユーザーの不一致による問題

多くのトラブル（ファイルのアップロード失敗や自動更新のエラー）は、パーミッションの数字そのものではなく、所有権の設定ミスに起因しています。

ウェブサーバーユーザー: Apache や Nginx（一般に www-data や apache という名前）
FTP/SSH ユーザー: 管理者がログインに使用するユーザーアカウント

もしファイルの所有権が管理者にあり、サーバー側のプログラム（PHP）が「その他（Others）」として扱われる設定になっている場合、PHP からファイルを書き換えるためには、パーミッションの右端の数字に書き込み権限（例：777 や 666）が必要になってしまいます。
これが「777 にしないと動かない」という誤解を生む原因です。

7.2 安全なサーバー環境（suPHP, FastCGI 等）

最近のモダンなレンタルサーバー環境では、PHP が「そのサイトの契約者（所有者）」と同じ権限で動作する仕組み（suPHP や FastCGI + PHP-FPM）が採用されていることが一般的です。
この環境であれば、ディレクトリ 755、ファイル 644 という「所有者だけに書き込みを許可する設定」だけで、WordPress の自動更新やプラグインのインストールが安全に行えます。

もし 777 を設定しなければならない環境であれば、それはサーバーの構成が古いか不適切であることを示唆しています。
その場合はパーミッションを緩めるのではなく、サーバー会社に「 suPHP や FastCGI などのセキュアな実行環境への移行」を相談するか、よりセキュリティ意識の高いホスティングサービスへの移行を検討することが推奨されます。

8. トラブルシューティング：パーミッション起因のよくあるエラー

パーミッションを厳しく設定しすぎたり、所有権の不整合が発生したりすると、サイトの運営に支障をきたすエラーが発生します。
ここでは、実務で頻出するトラブルとその解決基準を整理します。

8.1 「403 Forbidden」エラーが発生する場合

サイトにアクセスしようとした際に 403 エラーが表示される場合、ウェブサーバーが対象のディレクトリやファイルに対して「読み取り」権限を持っていない可能性があります。

原因の特定: ディレクトリが 700 や 600 など、所有者以外を完全に遮断する設定になっていないか確認します。
解決策: ディレクトリを 755（または 750）、ファイルを 644（または 640）にリセットします。
特に .htaccess ファイルの読み取り権限が不足していると、サイト全体が 403 エラーになることがあります。

8.2 メディアのアップロードに失敗する場合

「ディレクトリを作成できませんでした」「書き込み権限がありません」といったメッセージが表示される場合、wp-content/uploads ディレクトリの権限に問題があります。

チェックポイント: 所有権を確認します。
サーバーの PHP 実行ユーザーがディレクトリに対して「2（書き込み）」の権限を持っている必要があります。
安易な 777 の回避: ここで 777 を設定して解決を図るのではなく、所有者をサーバー側のユーザー（www-data 等）に変更するか、所有ユーザーと同じグループに所属させた上で 775 等の設定を検討します。

8.3 公式アップデートやプラグイン更新が停止する場合

WordPress 本体やプラグインの更新時に「ファイルのコピーに失敗しました」というエラーが出る場合、WordPress コアファイルが含まれるディレクトリの所有権やパーミッションが原因です。
特に VPS 等で手動構築した環境では、FTP ユーザーと Web ユーザーが分かれているために、更新プログラムがファイルを上書きできないケースが目立ちます。
この場合も、適切な所有権の設定が解決の鍵となります。

9. サーバー環境ごとの挙動と設定の差異

パーミッションの「正解」は、利用しているサーバーの実行モデルによって微妙に異なります。

9.1 共有レンタルサーバー（suPHP / FastCGI 採用環境）

国内の主要なレンタルサーバーの多くは、各ユーザーの PHP プログラムを「契約者ユーザー」として実行します。
この環境はセキュリティ的に優れており、以下の設定で完璧に動作します。

ディレクトリ: 755
ファイル: 644
メリット: 所有者権限だけで更新作業が完結するため、外部（Public）への権限を最小化できます。

9.2 手動構築した VPS（mod_php 採用環境）

Apache のモジュールとして PHP を動作させている場合、PHP は apache や www-data といったシステムユーザーとして動作します。
この場合、ファイルの所有者が「自分（SSHユーザー）」であれば、サーバーからは「その他（Others）」として扱われることになります。

リスク: この構成で更新を可能にするためには、右端の数字を 7（例：757）にする必要がありますが、これは 777 と同等のリスクを孕みます。
推奨される対策: ファイルの所有グループをウェブサーバーユーザーに変更し、グループ権限（真ん中の数字）を 7 または 6 に設定する（例：775, 664）手法が取られます。

10. セキュリティ監査のためのパーミッション・チェックリスト

サイトの公開前や定期的なメンテナンス時に確認すべき項目を整理しました。
これらを機械的にチェックすることで、意図しない設定変更や攻撃による痕跡を早期に発見できます。

10.1 定期確認項目

wp-config.php: 440, 600, または 400 に設定されているか。
.htaccess: 600 または 644 に設定されているか。
ディレクトリ全般: 755 (または 750) に統一されているか。
777 設定が混入していないか。
ファイル全般: 644 (または 640) に統一されているか。
実行（x）権限が不要なファイルに付与されていないか。
所有者（Owner）: サーバーの正当な実行ユーザーに設定されているか。

10.2 自動化ツールによる監査

手動での確認が困難な大規模サイトでは、WP-CLI やセキュリティプラグインを活用した自動監査が有効です。
例えば、WP-CLI を使用すれば、以下のコマンドで不適切なパーミッションを持つファイルを抽出するスクリプトを構築できます。

# パーミッションが 777 のディレクトリを検索
find /path/to/wordpress -type d -perm 0777

# 所有者が root なファイルを検索（セキュリティリスクの兆候）
find /path/to/wordpress -user root

定期的に cron 等でこれらのチェックを実行し、異常があれば通知を受け取る仕組みを整えることが、プロフェッショナルな運用における標準的なアプローチです。

11. 運用フェーズにおけるパーミッション管理の鉄則

パーミッション設定は「一度設定すれば終わり」ではありません。
サーバーの移転、プラグインの改修、あるいは緊急時の対応など、様々なシーンで設定が書き換わる可能性があります。

11.1 「最小権限の原則」の徹底

セキュリティの基本原則は、各ユーザーやプログラムに「必要最小限の権限のみ」を与えることです。
もしある機能の実装に 777 が必要だと言われた場合、それはその機能の設計自体がセキュリティ原則から逸脱している可能性が高いと判断すべきです。
常に「一段階厳しい設定」を試み、エラーが出た場合にのみ必要に応じて緩和するという、引き算の考え方で管理を行います。

11.2 改ざん被害発生時の「緊急ロックダウン」

万が一、サイトの改ざんが発覚した、あるいは不正アクセスの疑いがある場合、被害の拡大を防ぐためにパーミッションを一時的に最大限厳しくする「ロックダウン」が有効です。

wp-config.php の 400 化: 外部からの書き換えを物理的に遮断します。
uploads ディレクトリの書き込み禁止: さらなるマルウェアの設置を防ぐため、一時的に 555 (読み取りと実行のみ) に設定します。

11.3 サーバーログの監視

パーミッション設定のミスは、サーバーのログ（error_log）に記録されます。
「Permission denied」のログが頻発している場合、それは単なる設定ミスだけでなく、攻撃者が権限のないファイルにアクセスしようとしている予兆である可能性もあります。
パーミッションの設定とサーバーログの監視は、セットで考えるべき運用項目です。

11.4 パーミッションとキャッシュプラグインの相性

高性能なキャッシュプラグイン（WP Rocket, W3 Total Cache 等）を使用している場合、プラグインが wp-content/cache ディレクトリ内に静的な HTML や結合された CSS/JS ファイルを生成します。

書き込み権限の必要性: これらのディレクトリには、サーバーユーザーによる書き込み権限が必須です。
セキュリティのバランス: キャッシュディレクトリが 777 になっているケースが散見されますが、これも 755 で運用できるよう所有権を調整すべきです。
実行権限の排除: キャッシュディレクトリ内で PHP ファイルが実行されることはないため、.htaccess でこのディレクトリ内でのスクリプト実行を禁止し、セキュリティを二重化することが推奨されます。

11.5 静的サイトジェネレーター (SSG) 利用時の考慮事項

WordPress をヘッドレス構成（SSG 変換）で運用している場合、公開用サーバーと管理用サーバーでパーミッションの考え方が分かれます。

管理サーバー（Source）: 本記事で解説した標準的なパーミッション（755/644）を適用します。
公開サーバー（Static Site）: 公開サーバー上には静的な .html, .css, .js しか存在しないため、すべてのディレクトリを 555 (r-x)、すべてのファイルを 444 (r–) に設定して「完全な読み取り専用」にすることが可能です。
これにより、どれほど脆弱性を突かれたとしても、サーバー上のファイルが物理的に書き換えられることを防げます。

11.6 高度な管理：WP-CLI によるパーミッションの一括監査

WP-CLI は、管理画面を介さずに WordPress を操作できる強力なツールですが、パーミッション管理にも活用できます。
例えば、定期メンテナンス時に全ファイルの整合性を確認する際、チェックサムの検証と併せてパーミッションの検証を行うことで、改ざんの有無を多角的に判定できます。

# コアファイルの整合性をチェック
wp core verify-checksums

このコマンドはファイルの整合性をチェックするものですが、エラーが出る場合はパーミッション設定が壊れていることが多いため、トラブルシューティングの第一歩として非常に有効です。

12. まとめ

WordPress のファイルパーミッション管理において、最も重要なことは「777 の危険性を正しく認識し、WordPress.org が推奨する標準値を維持すること」です。

本記事で解説した以下のポイントを改めて整理します。

ディレクトリは 755、ファイルは 644 が鉄則。
wp-config.php は 600 または 440 で厳重に保護する。
777 設定は本番環境では一切不要 であり、深刻な脆弱性となる。
パーミッションは「所有権」とセット で初めて機能する。

正しいパーミッション設定は、攻撃者に対して「このサイトは管理が行き届いている」という強力な無言のメッセージとなります。
逆に、設定が杜撰であれば、他のどの高度なセキュリティ対策を講じていても、根本的な部分で崩壊してしまうリスクを抱えることになります。

本レポートが、皆様の WordPress サイトの安全性を高めるための、堅実な一歩となれば幸いです。