目次
画像を追加できないので、uploadsの権限を広げる。会員向け資料だから、投稿を非公開にしてPDFを置く。こうした操作では、書き込めること、読めること、プログラムとして実行されることを混同しない確認が必要です。WordPressでファイルを扱う際は、管理画面の権限だけでなく、保存先と配信経路まで見ます。
この記事は2026年10月18日にWordPress公式資料とOWASPのファイルアップロード資料を確認した実務ガイドです。Linux系の一般的な考え方を扱いますが、実際の設定値はPHPの動作方式やレンタルサーバーの構成で変わります。特定サイトへ一律の権限変更を勧めるものではありません。
スポンサーリンク
誰が書き込み誰が配信するかを分ける
WordPress公式の権限資料は、所有者、グループ、その他の利用者への読み書きなどを説明し、適切な設定はホストによって異なるとしています。FTPやSSHを使う利用者と、PHPやWebサーバーの実行ユーザーが一致するとも限りません。出典：WordPress公式：Changing File Permissions。
そのため、権限の数字だけを見て安全性を判断しないでください。「誰が所有するか」「どのプロセスが書く必要があるか」「誰へ配信するか」を確認します。同じ設定値でも、実行ユーザーや共有するグループが違えば、許される操作の範囲が変わります。
まず保守担当と、コアのコード、テーマやプラグイン、アップロード、キャッシュ、設定ファイルの用途を分けます。画像を書き込む必要があることと、アプリケーションのコード全体を書き換える必要があることは同じではありません。更新の方式も踏まえて、必要な範囲へ絞る設計にします。
アップロードできない原因を777で隠さない
公式資料は、777による広い書き込み権限の危険性を説明しています。画像追加に失敗したときは、保存先、所有者、容量、サーバー側の制限などを調べ、事業者の推奨設定を確認してください。すべてのファイルへ同じ権限を再帰的に適用する変更は、原因を見ずに行わないようにします。出典：WordPress公式：ファイル権限と777の危険性。
本サイトの提案は、失敗した操作と時刻、対象ディレクトリ、現在の所有者と権限、容量の状態を記録して相談する方法です。正常な別のディレクトリと比較する際も、用途が同じかを先に確認します。数値を順に広げて偶然動く状態を探すより、どの主体の書き込みが拒否されているかを特定します。
レンタルサーバーでは利用者が変更できない所有権や制限もあります。その場合は、自分で保護を外すのではなく、事業者へ変更を依頼します。設定を変えた後は、アップロードの成功だけでなく、不要な書き込みが広がっていないこと、通常の更新が維持できることも確認してください。
スポンサーリンク
メディアライブラリとフォーム添付は入口が違う
管理画面から画像を追加する機能と、未ログインの訪問者が使うお問い合わせの添付機能は、扱う相手も必要な制限も違います。フォーム用プラグインや独自APIが追加する入口は、その製品の仕様と設定で確認してください。メディアライブラリが動くので、すべての入口も同じ保護を持つと考えないことが重要です。
OWASPは、必要な拡張子の許可リスト、ファイル形式の検証、サイズ制限、認可された利用者への制限などを組み合わせる方法を説明しています。Content-Typeヘッダーだけを信用せず、単一の検証方法で安全を保証しない考え方です。出典：OWASP公式：File Upload Cheat Sheet。
運用担当者は、受け付ける種類が業務に必要かを確認します。たとえば応募フォームでPDFのみ必要なら、圧縮ファイルや実行可能な形式まで受け付ける理由を見直します。一方、拡張子の制限だけで内容が安全になったとは判断せず、処理するライブラリの更新や検査も別の確認事項にします。
保存できても公開してよいとは限らない
WordPressの公式資料は、ファイル自体へ直接リンクする場合と、添付ページへリンクする場合を分けています。投稿の画面と、ファイルを配る経路は区別して確認する必要があります。出典：WordPress公式：Use image and file attachments。
説明用に、会員向けの申請書を通常のメディアへアップロードし、非公開ページからリンクする例を考えます。そのページを見られなくても、ファイルのURLを直接開いたときの認可まで実装されているとは限りません。実際の構成で、ログアウトした利用者や対象外の会員から取得できないことを確認します。
検索結果へ出さない設定や、推測しにくいファイル名は、閲覧権限の確認を置き換えません。機密資料には、必要な人だけへ配る仕組みを使います。期限付きURLを使う場合も、期限内の共有、ログへの記録、キャッシュの扱いなど、どこまで制限できるかを理解してください。
スポンサーリンク
アップロードした内容をコードとして扱わない
OWASPは、別サーバーや公開領域の外への保存、最小限のファイルシステム権限などを検討するよう説明しています。保存先からプログラムを実行できる状態は、単にファイルを置く状態とは異なる危険を持ちます。出典：OWASP公式：保存場所とファイルシステム権限。
既存のWordPressで保存先を一律に移動すると、画像URL、生成したサイズ、CDNやバックアップとの連携に影響する場合があります。本サイトでは、公開画像と非公開の添付資料を分け、現在の製品が対応する方式を使うことを提案します。一般論の保存方式を、そのまま既存サイトへ適用しないでください。
サーバー側でアップロード領域のスクリプト実行を制限する場合も、ApacheかNginxか、PHPの処理がどこで決まるかを確認します。ある環境の.htaccessを別の環境へ貼り付けて、保護できたと判断しません。権限の実行ビットだけで、Web経由の処理まで制御できると考えないことも重要です。
設定と作業用ファイルを公開領域へ残さない
設定ファイルやデータベースの出力には、接続情報や非公開のデータを含む場合があります。保守作業で作った複製、圧縮ファイル、古い設定、ログを、画像と同じ配信先へ置かないようにします。便利な作業場所と、一般公開してよい保管先を分けてください。
本サイトの提案は、保守で一時ファイルを作る際に、保存場所、取得できる人、削除する時期を決める方法です。作業が終わった後に一覧を確認し、サーバー上のコピーだけでなく、CDNなどへ配信されたものがないかも調べます。ファイルを消しても、すでに配信された内容まで回収できるとは限りません。
wp-config.phpのような設定は、PHPが正常に動作しているかどうかだけに保護を依存させず、所有権と読み取り範囲、サーバーの配信設定を保守担当と確認します。別サイトで使った数値を一律に適用するより、実行主体と契約先の案内に合わせて決めます。
容量と処理量も制限の対象にする
大きなファイルや多数の添付によって、保存容量だけでなく、画像変換や検査の処理も増える場合があります。必要な上限を、単一ファイル、リクエスト全体、回数、保存期間という別の観点で決めます。どの層の上限が先に働くかも確認してください。
たとえばフォームの表示では小さな上限があっても、サーバー側で同じ条件が検証されているとは限りません。逆に、CDNやPHPの上限が低く、アプリケーションへ届く前に失敗する場合もあります。利用者への案内と、実際の許可条件が一致するように調整します。
期限が過ぎた添付を削除する際には、必要な保管要件とバックアップの扱いを確認します。容量削減だけを理由に一括削除せず、どの業務のデータかを把握してください。個人情報を含む資料なら、閲覧できる担当と保管期間を明確にすることも安全対策です。
添付の検査で外部サービスを使う場合は、送信してよい情報かも確認します。履歴書、契約書、本番の設定ファイルを、手軽さだけで公開型の解析サービスへ送らないでください。検査先の取り扱いと自組織のルールを確認し、機密情報を含む場合は承認された検査環境を選びます。検査結果と、資料を第三者へ渡してよいかは別の判断です。
無害なファイルで許可と拒否を確認する
以下は本サイトが提案する検証項目です。侵入コードを本番へ配置する試験ではなく、検証用の無害なファイルを使い、認可や上限の設定が意図どおりかを確かめます。スクリプト実行制限の試験が必要なら、保守担当が管理する隔離環境で行ってください。
- 許可する形式とサイズのファイルを、想定した利用者が追加できる。
- 対象外の形式、上限を超えるファイル、認可されていない利用者は拒否される。
- 非公開にする資料は、ファイルの直接URLでも対象外の人から取得できない。
- 公開画像の表示、縮小画像、CDN、フォーム添付など、必要な経路が動く。
- 保存先、所有者、権限、配信や実行の制限、削除の条件を説明できる。
確認結果は、試験した入口と保存先ごとに残します。一つのフォームで成功した結果を、別のフォームやAPIへ広げないようにしてください。変更後に画像が表示されなくなった場合も、保護を全面解除する前に、どの配信経路が止まったかを切り分けます。
ファイルの安全性は、拡張子や権限の数字だけで決まりません。誰が入れ、どこへ保存し、誰が読み、何として処理されるかを分けて確認することが、継続して守れるWordPress運用につながります。
スポンサーリンク
