実際に起きている事故を並べていくと、珍しい攻撃手法はほとんど出てきません。出てくるのは、決まったいくつかの型です。しかもその型は、技術で分類するより——間違った前提で分類したほうが、はっきり見えます。
① 「既定値は安全なはず」——設定を触っていない
開発しやすさのための既定
詳しいエラー表示・管理画面が開いている・全部入りの権限
↓ そのまま本番へ
攻撃者にとっての「案内板」
構成・パス・バージョン・内部の値が読める
- 本番でデバッグ表示が有効
- エラー画面に環境変数・ファイルパス・スタックトレースが出ていないか。実際に存在しないURLを開いて、返ってくる画面を自分の目で確認する。フレームワークごとの具体策は フレームワーク別の対策 に
- 管理用の画面が外から開く
- データベース管理ツールや管理コンソールがインターネットから到達できる状態。認証だけに頼らず、IP制限やネットワーク側の遮断を重ねる
- ヘッダが未設定／古い一覧のまま
- 今も効くヘッダと、もう要らないヘッダ。廃止済みのヘッダは足すと害になり得ます
- 保存方式が弱いまま
- パスワードの保存は ハッシュ化とソルト のとおり。「暗号化しています」は保存方式の説明になっていない
- 更新が止まっている
- 言語・フレームワーク・CMSのサポートが切れた版を使い続けている。依存を機械監視する仕組み と サポート終了が意味すること
② 「使っていないものは危なくないはず」——閉じ忘れ
攻撃面は、増やしたものより「やめたもの」から生えます。 使わなくなった瞬間に、監視と点検の対象から静かに外れるからです。
- 公開ディレクトリに残った秘密
.env、バックアップ、ダンプ、設定ファイル。公開ディレクトリに置いてはいけないもの / レンタルサーバーでの配置と設定- 公開設定のままのストレージ
- ブロックを掛けても既存の公開ポリシーは消えません。クラウドストレージの公開設定ミス
- 宙に浮いたDNSレコード
- 資源を消してDNSを消し忘れると、第三者が同じ名前を取って乗っ取れます。サブドメイン乗っ取り（dangling DNS）
- 閉じ忘れた登録・管理経路
- 誰でも登録できる状態が残っていないか。設定ではなくHTTPで実測する（認証と認可の違い）。推測できるURLに「隠してあるだけ」の画面を置かない
- 解約したつもりのアカウント
- 解約と退会（削除）は別で、退会しない限りデータは残ります。レンタルサーバーが不正アクセスされたとき
- 古い鍵・トークン・権限
- 退職者のアカウント、期限のないトークン、広すぎる権限。SSH鍵と最小権限 / パスワードマネージャー
棚卸しの単位を「稼働中のもの」にしない
点検の対象を「いま動いているもの」に限ると、この型は構造的に見つかりません。かつて作ったもの全部を単位にしてください——サブドメイン、アカウント、鍵、バケット、検証環境、外部サービスの契約。やめたものは、消すまで資産のままです。 一覧の作り方は 資産棚卸しチェックリスト に。
③ 「何かあれば気づくはず」——見えていない
事故の被害は、起きた事実より「気づくまでの時間」で決まります。そして多くの環境は、気づく仕組みを持っていません。
よくある状態
・アクセスログはあるが誰も見ていない
・ログイン成否の監査ログが無い（事故後に「何が見られたか」を追えない）
・レート制限は掛けたが到達したことが誰にも見えない
・公開状態が複数層の合成結果で、どこか1つを見ても分からない
結果として、侵入されたかどうかを「分からない」としか言えなくなります。
最低限、入れておくもの
・新規ユーザー登録の通知（1件でも異常に気づける）
・ログイン成否の記録と保持期間の設定
・依存の脆弱性の機械監視（人力では追えません → osv-scanner）
・上限到達の記録と急増時の通知（レート制限と濫用対策）
全部は要りません。1つでも「気づける経路」を作ることが、長期化を防ぎます。
ログが無いときの正しい答えは「無かった」ではなく「分からない」
事故対応で最も危ういのは、記録が無いことを「何も起きていない証拠」と読むことです。記録が無いなら、言えるのは「分からない」だけ。その場合は侵害された前提で、露出した可能性のある秘密を失効・再発行してください。組織としての最低ラインは 組織のセキュリティ基準 にまとめています。
④ 「入力は検証すれば安全なはず」——外部に決めさせすぎ
入力について本当に問うべきは「この値は正しいか」ではなく、「この入力に、どこまで決めさせているか」です。決定権を渡しているものが多いほど、検証は追いつきません。
- 値だけを決めさせている
- 通常の入力。長さ・形式・範囲の検証が効く安全側
- 構造まで決めさせている
- 深いオブジェクトを丸ごと受け取って合成する設計。プロトタイプ汚染
- 型まで決めさせている
- オブジェクトを復元する形式。値の検証に到達する前に決着します。安全でないデシリアライズ
- 置き場所まで決めさせている
- アップロードされたファイルが実行される場所に置かれる設計。ファイルアップロードの脆弱性
- 「誰であるか」を決めさせている
- リクエストヘッダの値を信用して送信元を判断する。X-Forwarded-For 偽装と信頼できるプロキシ
渡している決定権を数えるだけで、危険な箇所は自然に浮かび上がります。 そして多くの場合、構造で解決できるものを検証で解決しようとしているのが原因です——受け取る形を変えるほうが、検証を足すより確実です。
今日から順にやるなら
本番の「見え方」を自分で確認する（①）
存在しないURL、エラーを起こすリクエスト、管理系のパス——実際にブラウザとHTTPで叩いて、返ってくるものを見ます。設定ファイルを読むのではなく出力を見るのが要点です。ヘッダは 診断ツール でまとめて測れます。
「かつて作ったもの」を書き出す（②）
サブドメイン、アカウント、鍵、バケット、外部サービス。稼働中かどうかで絞らないのがコツです。資産棚卸しチェックリスト に沿って一覧にし、使っていないものは削除まで進めます（停止ではなく削除）。
「気づける経路」を1本だけ作る（③）
全部の監視を用意しようとすると、たいてい何も入りません。まず1つ——新規登録の通知、ログイン失敗の急増、依存の脆弱性メールのどれかを動かしてください。動いていることの確認まで含めて1本です（設定しただけの監視は、無いのと同じです）。
入力に渡している決定権を数える（④）
外部データが値だけを決めているのか、構造・型・置き場所まで決めているのかを書き出します。1つでも「値以外」を渡している場所があれば、そこが優先度の高い改修対象です。
更新を仕組みにする（①の再発防止）
①は放っておくと必ず戻ります。依存とフレームワークの更新を機械監視に載せるのが唯一の現実解です（osv-scannerの導入と使い方 / CVE対応の実務手順）。手順書に書くだけでは、忙しい日に飛びます。
当サイトの視点：4つとも「かつて正しかった前提」である
この4つに共通するのは、どれも一度は正しかったことです。既定値は開発中には妥当でしたし、使っていないものは実際に使っていないし、小さいうちは何かあれば気づけたし、入力検証は多くの問題を解決してきました。だから疑われないまま残ります。
当サイトの立場は、「正しかった前提が、いつ正しくなくなったか」を定期的に見ること。技術を追加するより、この確認のほうが安上がりで効きます。そして——チェックリストは「やること」を教えてくれますが、「なぜ抜けたか」は教えてくれません。抜ける理由が同じなら、同じ場所でまた抜けます。
次に読む
- 手順として：セキュリティ最低限チェックリスト（個人・小規模） / 組織のセキュリティ基準
- 棚卸し：資産棚卸しチェックリスト
- 事故から学ぶ：実際に起きた事故の解説（同じ型が繰り返し出てきます）
- 傾向：2026年の侵入経路は「認証情報」型が主流
よくある質問
Qセキュリティ対策は何から手をつければいいですか？
個別の攻撃手法を覚えるより、自分の環境が4つの型のどれに当てはまるかを見るほうが早く効きます。①本番の設定が既定値のままになっていないか、②作ったまま閉じていないものが残っていないか、③異常が起きたときに気づける状態か、④外部からの入力にどこまで決定権を渡しているか。この記事は各型の具体的な確認項目と、詳しい記事への入口をまとめたものです。
Q小さな個人サイトでも同じですか？
型は同じで、優先順位が変わります。個人・小規模でまず効くのは、①既定値の確認（本番でデバッグ表示が有効になっていないか）と②閉じ忘れの棚卸し（公開ディレクトリに秘密が無いか、使っていないサブドメインやアカウントが残っていないか）です。③の監視は仕組みが要るので後回しでよいのですが、最低限『新規登録の通知』のような一点だけでも入れておくと、気づくまでの時間が大きく変わります。
Qチェックリストとは何が違うのですか？
チェックリストは『やること』の一覧で、この記事は『なぜ抜けるのか』の整理です。項目を並べても、抜ける理由が同じなら同じ場所でまた抜けます。4つの思い込みは、どれも一度は正しかったからこそ残っているもので、だから意識しないと再発します。実際の手順が必要なときは、各型からリンクしているチェックリスト記事に進んでください。
Q全部やる時間がありません。1つ選ぶなら？
③の『見えていない』を1つだけ埋めてください。①と②は放っておくと事故になりますが、③が無いと事故に気づけません。事故は起きた事実より、気づくまでの時間で被害が決まります。ログを取る、通知を1つ入れる、月に一度だけ棚卸しする——どれか1つでも、事故の長期化を防ぐ効果が最も大きい投資です。