WEBサイト公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す ── 自社と担当サイトの.bak・.old・日付付きの写しを棚卸しする13項目（2026年10月時点）
公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す ── 自社と担当サイトの.bak・.old・日付付きの写しを棚卸しする13項目（2026年10月時点）
目次
01 何が起きたか・いま最新の文書は何か — 公開の場所に残った控えは、名前で探して状態コードで確かめ、外へ移す
控えは、消し忘れだけでなく、作業の副産物としても生まれる
設定を直す前に、元のファイルを写しておく。末尾に.bakや.oldを付けるか、日付を入れて、同じ場所に置く。直し終えたら消すつもりでいて、そのまま数か月が過ぎる。
この記事は、Webサーバーが外へ返すフォルダ（公開の場所）に残った控えを、自分のサイトで棚卸しする手順を扱う。2026年10月23日に、OWASPの検査ガイド、MITREのCWE、ApacheとnginxとcurlとVimの文書を開いて読んだ。結論から書く。控えの問題は、名前で探し、状態コードで確かめ、外へ移し、作る手順を直す、の順に進めれば、中身を開かずに片づけられる。ただし、5段の並べ方は、この記事の提案である。
5段の手順 — 探す、確かめる、見つける、移す、作らない
1段目は、名前で一覧を作る。2段目は、その一覧を外から要求し、状態コードだけを見る。3段目は、名前を変えた控えを、中身の特徴で探す。4段目は、台帳を作ってから、公開の場所の外へ移す。消さない。5段目は、控えが作られない形に、編集と転送の手順を直す。
この記事が根拠にした文書と、その日付
日付の取り方は文書ごとに違う。ページに日付がない文書は、サーバーが返したLast-Modifiedか、ソースの変更履歴の日付を書いた。
| 文書 | 日付（取り方） | 使いどころ |
|---|---|---|
| OWASP Web Security Testing Guide「Review Old Backup and Unreferenced Files for Sensitive Information」（WSTG-CONF-04） | 2026年9月23日（GitHubの履歴） | 探し方、危険、対処 |
| Apache「Security Tips」 | 2026年9月29日（Last-Modified） | 既定の動き |
| Apache「core」、httpd.conf.in（設定の雛形） | 2026年6月8日（Last-Modified）、2026年3月16日（GitHubの履歴） | 名前での拒否 |
| nginx「core」「access」 | 2026年10月22日（Last-Modified） | locationと拒否 |
| MITRE CWE-530 | 2026年4月30日（ページ末尾の表記） | 弱点としての位置づけ |
| curlのマニュアル、Vimのオプションの文書 | curlは2026年10月22日（Last-Modified）。Vimは2026年10月18日（Last-Modified） | 状態コード、エディタの控え |
02 なぜ・背景 — 控えは、エディタと手作業から、元のファイルの隣に生まれる
OWASPは、控えが平文のまま返る危険を挙げている
OWASPのガイドの項目は、冒頭の要約で、控えが外から読める理由を書いている。
"Because these often keep a different extension or name than the original (e.g. login.asp.old alongside login.asp), they tend to be served as plain text/source rather than executed, exposing server-side code, credentials, and internal details."
（訳: こうしたファイルは、元の名前と別の拡張子や名前を持つことが多い（たとえば、login.aspの隣にあるlogin.asp.old）。そのため、実行されずに、平文のソースとして返されやすく、サーバー側のコード、認証情報、内部の詳細が見えてしまう。）
危ないのは、元のファイルの隣に置かれた写しである。元が守られていても、写しは別の名前なので、同じ守りに入らないことがある。同じ文書は、脅威に、いまの版では直した脆弱性が古い控えに残ること、も挙げている（要旨）。古い版の脆弱性の件で、更新のあとに確かめることは、記事「PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録」で扱った。
MITREのCWEは、控えを独立した弱点として登録している
CWE（Common Weakness Enumeration・共通脆弱性タイプ一覧）には、この問題の専用の項目、CWE-530がある。
"A backup file is stored in a directory or archive that is made accessible to unauthorized actors."
（訳: 控えのファイルが、許可されていない者にも見られるディレクトリやアーカイブに置かれている。）
この項目が挙げる対策の1つは、公開の場所でソースの控えを作ることを禁じる方針である。探して移すだけでは足りず、控えを作らない決まりが、対策の本体になる。5段目が、そこに当たる。
控えは、エディタの設定や手作業からも作られる
OWASPは、対処の方針の最初に、サーバー上での直接の編集を挙げている。
"Editing files in-place on the web server or application server file systems. This is a particularly bad habit, since it is likely to generate backup or temporary files by the editors."
（訳: Webサーバーやアプリケーションサーバーのファイルシステムの上で、ファイルを直接編集すること。エディタが控えや一時ファイルを作りやすいので、とくに悪い習慣である。）
Vimの文書には、控えの置き場所を決めるbackupdirの具体的な説明がある。
"A directory "." means to put the backup file in the same directory as the edited file."
（訳: ディレクトリとして「.」を指定すると、控えのファイルは、編集したファイルと同じディレクトリに置かれる。）
Unixの既定の先頭は「.」で、控えの名前に足すbackupextの既定は~である。backupの既定はオフだが、残す設定にすると、控えは編集したファイルの隣、公開の場所の中に置かれる。
見えない名前の控えもある — lsでは出ず、findでは出る
Vimのスワップファイル（編集中の内容を保存する作業用のファイル）も、既定では編集したファイルの隣に置かれる。文書には、Unixではファイル名の先頭にドットが付き、一覧には出ない、とある。探すときは、findで名前を指定する。
検索結果にも出うる — noindexは、外から読めない設定の代わりにならない
OWASPは、一覧を閲覧できるディレクトリに控えが置かれていれば、検索エンジンが存在を知っている可能性がある、と書いている（要旨）。noindexとrobots.txtが何を止めるかは、記事「noindex・nofollow・robots.txtは、それぞれ何を止めているのか ── 混同しやすい3つの設定を確認する15項目」で扱った。ガイドは、robots.txtのDisallow: /backupの行も、手がかりの例に挙げる。止めるつもりの行が、置き場所を教える形になる。
Apacheは、拒否の設定がなければ、URLに対応するファイルを返す
Apacheの「Security Tips」は、既定の動きを、こう説明している。
"if the server can find its way to a file through normal URL mapping rules, it can serve it to clients."
（訳: サーバーが、通常のURLの対応づけの規則でファイルにたどり着けるなら、それをクライアントに返せる。）
読み取れるのは、名前で拒否する設定を足さなければ、公開の場所の中のファイルは、名前に関係なく返ることである。
03 用語 — 控えの棚卸しで使う5つの言葉
控えファイル、公開の場所、状態コード、存在しない名前での確認、台帳
用語
控えファイル：元のファイルの写しや、編集の途中で作られる一時のファイル。OWASPは、old・backup・unreferenced（参照されていない）と呼ぶ。
用語
公開の場所（ドキュメントルート）：Webサーバーがファイルを探しに行く起点のフォルダ。ApacheのDocumentRootの説明は、「Directory that forms the main document tree visible from the web」（訳: ウェブから見えるドキュメントの木の根になるディレクトリ）である。
用語
状態コード：サーバーが、応答の最初に返す3桁の数字。200は返せた、403は拒否した、404は見つからない、という意味になる。
用語
存在しない名前での確認：存在しないと分かっている名前を、同じ方法で要求し、控えの候補と結果を並べること。独自の「見つかりません」の画面が200で返る環境を、見分けるためである。
用語
台帳：移したファイルの元の道すじと、md5（中身から計算する32桁の目印）を、1行ずつ記録した表。移したあとの値と並べて、中身が変わっていないことを確かめる。
04 型別 — 名前の型を5つに分けて、探し方と守り方を決める
OWASPは、ファイルの種類を6つに分けて、公開してよいかを書いている
OWASPのガイドの表を、日本語にまとめた。例は、表の一部である。
| 種類 | 例（一部） | OWASPの扱い |
|---|---|---|
| 認証情報と秘密 | .env、.pem、.htpasswd、.inc、.config | 原則、公開しない |
| ソースと設定 | .yaml・.yml・.json（想定した場所の外） | 原則、公開しない |
| 控えとアーカイブ | .bak、.old、.orig、.swp、~、.zip、.tar、.gz | 原則、公開しない |
| データの成果物 | .db、.sqlite、.csv | 中身しだい |
| 公開してよいことがある | .txt、.md、.log、.pdf | 公開してよい場合がある |
| 拡張子ではなく、場所 | .git/、.docker/ | 道すじで見る |
OWASPは、ヒットは候補にすぎない、と注意している。次から、この記事の提案の5つの型を説明する。
型A — 末尾に付く名前（.bak・.old・.orig・~・.swp）
最も多い型で、findの-iname '*.bak'のように、末尾で指定できる。OWASPの推測の手順にも、~、bak、old、origなどを、元の拡張子の前・後ろ・代わりに付けて試す例がある。探す形が違うと、あるものも見つからない。その例は、記事「仕組みは在った。運ぶ気もあった。探す形が違っていた ── サムネイルが本番から消えていた日、ログは一度も鳴らなかった」で扱った。
型B — 日付・番号・copyが名前の途中に入った写し
手作業の複写では、index_20261001.phpやheader-copy.phpのように、名前の途中に日付やcopyが入る。末尾は.phpのままなので、型Aの条件では漏れる。日付の形は、正規表現で指定して探す。OWASPは、Windowsの複写で「Copy of 」で始まる名前になることも書いている。
型C — アーカイブとダンプ
圧縮した控え（.zip、.tar、.gz）やデータベースの書き出し（.sql）は、1本で多くの内容が読める。ただし、公開してよいアーカイブもある。配布用の.zipが、公開の場所にあって当然の場合である。ここは、1本ずつ決める。
型D — 名前を変えて置かれた設定（.txtや.inc）
PHPの設定を.txtの名前で写して置くと、実行されずに、中身が文字のまま返る。OWASPの例にも、connection.incを直接要求すると、データベースの接続情報が返る場面がある。この型は、拡張子では見分けられない。そこで、中身の特徴で探す。特徴は、行頭にPHPの開始タグがあること、接続情報らしい書き方を含むこと、の2つにした。
型E — 設定ファイルの控え（.htaccess.bakなど）
ドットで始まる名前は、Apacheの既定の拒否の対象に入る場合がある。設定の雛形には、こうある。
"The following lines prevent .htaccess and .htpasswd files from being viewed by Web clients."
（訳: 次の数行は、.htaccessと.htpasswdのファイルが、ウェブのクライアントから見られるのを防ぐ。）
この下の記述は、<Files ".ht*">の中にRequire all deniedを書いたものである。Filesの文書は、名前の指定を、こう説明している。
"The filename argument should include a filename, or a wild-card string, where ? matches any single character, and * matches any sequence of characters."
（訳: ファイル名の引数には、ファイル名か、ワイルドカードの文字列を書く。?は任意の1文字に、*は任意の文字の並びに当たる。）
この説明のとおりに読むと、.ht*は、名前が.htで始まるファイルに当たり、.htaccess.bakも含まれる。ただし、文書の書き方からの読み取りである。配布パッケージや貸しサーバーの設定が、雛形のままとは限らない。実機で状態コードを確かめるまでは、守られているとは言えない。
05 控えの棚卸しで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。状態コードの項目は、自分が運営するサイトにだけ行う。
- サーバーの設定ファイルを開き、公開の場所（ドキュメントルート）のパスを1つ書き出す
- 06章の1段目の
findを、公開の場所に1回流し、出た本数を数えて書く - 出た一覧を、型A・型B・型Cの3つの束に分け、束ごとの本数を書く
findで名前が.htで始まるファイルを探し、見つかった本数を数える- 一覧の上位10本について、末尾を外した元のファイルが、同じ場所に今もあるかを
lsで確かめる - 一覧の控えのURLを、自分のサイトに、HEADで1本ずつ要求して、状態コードを表に書く
- 存在しないと分かっている名前を、同じ方法で1本要求し、状態コードと応答の大きさを書く
- 状態コードが200だった控えを、台帳に書いて、外へ移す対象にする
- 拡張子が
.php以外で、行頭にPHPの開始タグがあるファイルを、grep -lで数える - 接続情報らしい書き方を含むファイルの名前を出し、公開の場所に置く理由を1行ずつ書く
robots.txtを開き、Disallowの行のうち、控えやbackupを指す行を数えて書く- 移す先を公開の場所の外に決め、移す前のmd5を台帳に書き、移したあとのmd5と並べる
- 編集の道具を1つ選び、控えの置き場所の設定を書き出し、3週間後に
findを再実行する日を、予定に入れる
時間がないときは、項目2・6・7・8の4つだけでも、状況はつかめる。
06 代替・他の選択肢 — 控えの扱いを表で比べ、5段の手順で進める
控えの扱いは4つある
| 選択肢 | できること | 残る問題 |
|---|---|---|
| 消す | 公開の場所からなくなる | 戻せない。要らないと確かめた控えだけに使う |
| 公開の場所の外へ移す（この記事の提案） | 外から読めなくなり、台帳で戻せる | 置き場所と台帳の管理が要る |
| 設定で拒否する | ファイルを動かさずに、外から読めなくする | ファイルは残り、設定が変わると読める |
| 控えを作らない手順に直す | 新しい控えが増えない | いまある控えは、別に片づける |
1段目 — 探す。名前で一覧にする（中身は開かない）
公開の場所のディレクトリを1つ渡すと、控えらしい名前を、日付・大きさ・道すじ（公開の場所から見た位置）で出す。本文は読まない。末尾の条件に加え、日付の形（bk20260710のように名前に直結した形も）とcopyを含む名前も拾う。3列目の道すじをcut -f3で取り出してpaths.txtにすると、そのまま2段目と4段目の入力になる。-printfはGNU版のfindの機能である。
DOCROOT="${1:?公開の場所のディレクトリ}"
find "$DOCROOT" -type f \( \
-iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' \
-o -iname '*.swp' -o -iname '*.tmp' -o -iname '*~' \
-o -iname '*.zip' -o -iname '*.tar' -o -iname '*.gz' -o -iname '*.tgz' -o -iname '*.sql' \
-o -iname '*copy*' \
-o -regextype posix-extended -iregex '.*[._-](19|20)[0-9]{2}[-_]?[01][0-9][-_]?[0-3][0-9].*' \
-o -regextype posix-extended -iregex '.*(bk|bak)[-_]?(19|20)[0-9]{6}.*' \
\) -printf '%TY-%Tm-%Td\t%s\t/%P\n' | sort
OWASPは、この作業を定期の予定にし、頻度の低い手作業の確認と組み合わせる案も挙げている（要旨）。
2段目 — 確かめる。状態コードだけを見る（自分のサイトにだけ）
一覧の道すじを自分のサイトのURLに足して、状態コードを見る。curlのマニュアルは、-I（--head）を、こう説明している。
"Fetch the headers only. HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document."
（訳: ヘッダーだけを取得する。HTTPサーバーには、文書のヘッダーだけを取るためのHEADという命令があり、これはそれを使う。）
次のスクリプトは、パスの一覧（paths.txt）を読み、先頭に、存在しないと分かっている名前を1本入れて、同じ方法で確かめる。他人のサイトに使ってはいけない。使うのは、自分が運営するサイトだけである。
BASE="${1:?自分のサイトの根のURL}"; LIST="${2:?パスの一覧}"
probe() { curl -sI --max-time 10 -o /dev/null -w '%{response_code}\t%{size_header}\t%{url_effective}\n' "$BASE$1"; }
printf 'CTRL\t'; probe "/zz-no-such-file-$$.bak"
while IFS= read -r p; do [ -n "$p" ] && { printf 'TEST\t'; probe "$p"; }; done < "$LIST"
2段目の続き — 状態コードの読み方
OWASPは、200が有効なリソースの発見を普通は示すが、独自の「見つかりません」の画面を200で返すサーバーは別だ、と書く。301・302・401・403・500も、調べる価値のある手がかりになる、とも書く。この記事での読み方は、次の図のとおりである。
OWASPは、自動の探索が報告するのは状態コードと指紋であって、ファイルが機密を含むかではなく、誤検出も見落としもよくある、と書く（要旨）。403だから安全、404だから無い、とは言い切れない。外から読めないと分かっても、安心はできない。読めたものを先に移し、読めないものは、残す理由を台帳に書いて、棚卸しを続ける。ログの状態コードも、種類を取り違えると数が変わる。HTTPのログだけを見ていた例は、記事「AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた」で扱った。
3段目 — 見つける。名前を変えた控えを、中身の特徴で探す
型Dは、名前に控えらしさがない。次のスクリプトは、2つの特徴で探す。1つ目は、拡張子が.php以外で、どこかの行頭にPHPの開始タグがあるファイル。ファイルの先頭とは限らない。2つ目は、接続情報らしい書き方を含むファイルである。grep -lはファイル名だけを出すので、一致した行は表示されない。
DOCROOT="${1:?公開の場所のディレクトリ}"
echo '--- A. 拡張子が .php 以外で、どこかの行頭にPHPの開始タグがあるもの'
find "$DOCROOT" -type f ! -iname '*.php' -exec grep -lI -m1 '^<?php' {} + 2>/dev/null
echo '--- B. 接続情報らしい書き方を含むもの（ファイル名のみ）'
grep -rlIE "DB_(PASSWORD|USER)|define\(.{0,3}DB_|'password' *=>" "$DOCROOT" 2>/dev/null
2つ目は、本物の設定ファイルにも当たる。当たったものは、公開の場所に置く理由があるかを、1本ずつ決める。OWASPの方針は、こうである。
"Data files, log files, configuration files, etc. should be stored in directories not accessible by the web server, to prevent both information disclosure and, where permissions allow writing, data modification."
（訳: データのファイル、ログのファイル、設定のファイルなどは、情報の漏えいと、権限が書き込みを許す場合のデータの改ざんの両方を防ぐために、Webサーバーから見えないディレクトリに置くべきである。）
4段目 — 移す。公開の外へ置く（消さない）
消さずに、台帳を作ってから移す。控えが要るか要らないかは、見ただけでは決められず、消すと戻せないからである。次のスクリプトは、元の道すじを保ってコピーし、md5が一致したものだけ元を消す。移し先が公開の場所の中なら、フォルダを作る前に止まる。移したファイルが0本なら、終了コード1で終わる。一覧が合っていないとき、何も移らないまま成功に見えないようにするためである。入力はpaths.txtでよい。
set -eu
DOCROOT="$1"; DEST="$2"; LIST="$3"
case "$(cd "$(dirname "$DEST")" && pwd -P)/$(basename "$DEST")/" in
"$(cd "$DOCROOT" && pwd -P)/"*) echo "移し先が公開の場所の中です" >&2; exit 2;; esac
OUT="$DEST/$(date +%Y%m%d)"; mkdir -p "$OUT"; chmod 700 "$OUT"
LEDGER="$OUT/MANIFEST.tsv"; : > "$LEDGER"
while IFS= read -r rel; do
rel="${rel#/}"
[ -f "$DOCROOT/$rel" ] || { echo "無い: $rel" >&2; continue; }
printf '%s\t%s\n' "$(md5sum "$DOCROOT/$rel" | cut -c1-32)" "$rel" >> "$LEDGER"
done < "$LIST"
n=0
while IFS="$(printf '\t')" read -r sum rel; do
mkdir -p "$OUT/$(dirname "$rel")"; cp -p "$DOCROOT/$rel" "$OUT/$rel"
if [ "$(md5sum "$OUT/$rel" | cut -c1-32)" = "$sum" ]; then rm -- "$DOCROOT/$rel"; echo "移した: $rel"; n=$((n+1))
else echo "md5が一致しない。元を残す: $rel" >&2; fi
done < "$LEDGER"
[ "$n" -gt 0 ] || { echo "移したファイルが0本です。一覧を確かめてください" >&2; exit 1; }
台帳にはmd5と元の道すじが残るので、戻すときは、その道すじのとおりに戻せる。
注意
移す前に、そのファイルを読む処理がないかを確かめる。控えのつもりのファイルを、別のページや定期処理が読んでいることがある。移した直後に、主要なページの状態コードを確かめる。
4段目の続き — 設定で守る（Apache）
新しい控えは、いつか作られる。控えらしい名前の拒否を設定に足すと、二重の守りになる。次の例は、この記事で作ったもので、公式の例ではない。
<FilesMatch "(?i)(\.(bak|old|orig|save|swp|tmp|sql)|~)$">
Require all denied
</FilesMatch>
この正規表現は、模擬の名前にPythonで当てて確かめた。Apacheの実機では動かしていない。.sqlなどを公開する用途があるサイトでは、その拡張子を外す。Apacheの文書は、主設定ファイルに触れるなら、.htaccessではなくそちらに書くべきだと説明している。
4段目の続き — 設定で守る（nginx）
nginxは、locationに正規表現を書いて拒否できる。文書は、前に~*を付けると大文字と小文字を区別しない照合、~を付けると区別する照合、と説明している。拒否は、アクセス制限のモジュールのdenyで書く。次の例も、この記事で作ったもので、nginxの実機では動かしていない。
location ~* (\.(bak|old|orig|save|swp|tmp|sql)|~)$ {
deny all;
}
正規表現のlocationは、最初に一致したところで探索が終わる、と文書に書かれている。書く順番で結果が変わるので、足したら、模擬のファイルで状態コードを確かめる。nginxの文書には、控えの拒否の専用の例は見つからなかった。
5段目 — 作らない。エディタ、転送、デプロイの手順を直す
エディタの控えの置き場所を、公開の場所の外にする。Vimならbackupdirの「.」を外し、外の道すじにする。ほかのエディタも、置き場所の設定があるかを確かめる。転送とデプロイから、控えを除く。*.bak・*.old・*~・*.swpを、送らない条件にする。サーバー上で直接編集しない。手元で直して、決まった手順で送る。どうしても直すときは、控えを公開の場所の外に置いてから直す。そして、1段目のfindを、週1回の予定にする。
07 この記事を書くために確かめたことと、確かめていないこと
開いたものと、手元で動かしたこと
2026年10月23日に、01章の表の文書を開いた。OWASPのページは、取得しても本文が得られなかったので、元のMarkdown（GitHubのOWASP/wstg）を取り直して読んだ。引用した英文10件（引用の枠9件と、用語の欄の1件）は、空白と引用符の形をそろえたうえで、開いた文書の本文と機械で照らし、すべて一致した。照らせなかった文は、引用の形にしていない。
06章の4つのスクリプトは、手元の模擬の公開の場所で動かした。一覧は、末尾型のほか、bk20260710のように日付が直結した名前も拾った。3列目の道すじで、移す手順まで通した。移し先が公開の場所の中だと、フォルダを作る前に終了コード2で止まり、移すものがないと終了コード1で終わった。行頭にPHPの開始タグがある探索は、ファイルの途中の行頭も拾った。状態コードは、手元の簡易のWebサーバーに対して確かめ、控えが200、存在しない名前が404だった。中身はダミーの文字列である。
確かめていないこと
5つある。1つ目は、ApacheとnginxのFilesMatchとlocationの例が、実機で拒否するかである。2つ目は、.htaccess.bakが、各社のサーバーの既定の設定で拒否されるかである。3つ目は、日本語版のページの文言である。英語の文書を読んで書いた。4つ目は、BSD版のfindでスクリプトが動くかである。5つ目は、GNU版のfindの公式マニュアルである。アクセスが拒否されて開けなかったので、引用していない。
当サイトの運営の記録
当サイトでは、2026年10月23日に、公開の場所の控えを棚卸しした。①.htaccessの控えを、公開の場所の外へ移した。②公開の場所の控えを外から要求し、読めた（200だった）ものを、公開の場所の外へ移した。③phpなどの控えは、外から403で読めないことを確かめた。数えた範囲の403の控えは、移していない。読めたものは移し、読めないものは残して、棚卸しを続けている。この範囲の記述は、運営の記録による。数、置き場所、名前、設定の中身は、書かない。
数え方の限界
5つの型は、この記事の整理で、OWASPの表の分類とは別である。findの条件は、名前の形だけを見る。名前から分からない控えは、中身の特徴の探索でしか拾えない。「0本だった」は、安心の根拠になりにくい。記事「「リンク切れ0本」を確認して、安心しかけた ── 自社ブログの内部リンク、59.2%はnoindexへの飛び先だった」は、その形を扱った。
08 このテーマの、これまで — OWASPは、拡張子の項目を控えの項目に統合した
「拡張子の扱い」の項目は、「控え」の項目に統合された
OWASPのガイドには、「File Extensions Handling for Sensitive Information」（WSTG-CONF-03）という項目がある。ソースのMarkdownを開くと、本文は、「Review Old Backup and Unreferenced Files for Sensitive Information」（WSTG-CONF-04）に統合された、という注記だけになっていた。統合の時期は、確かめていない。いまの項目には、クラウドのストレージに残った忘れ物も加わっている。クラウドを使うサイトは、ガイドの該当の節（Cloud Object Storage Artifacts）も読んでほしい。
当サイトでこの周辺を扱った記事
記事「削除したページに何を返すか ── 404・410・ソフト404の使い分けを確認する15項目」は、削除したページに何を返すかを扱った。移したあとの元のURLの話に近い。ブログの記事「記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.69を、記事を公開したその日に上げるまで」では、記事のチェック項目を自分のサイトに当てる形で、サーバーの点検を扱った。
現在の貴方のIPアドレス
このサイトで書いている人
