セキュリティ対策
パスワード・MFA・端末・公共Wi-Fi・サーバー・依存関係・Git・公開環境。今日から手を動かせる「守り方」を、目的別の実務ガイドで。
クラウドストレージの公開設定ミス — 「ブロック有効」は穴が無いことを意味しない
バケットからの漏えいは攻撃ではなく設定で起きる。公式ドキュメントの要点は『パブリックアクセスブロックは既存のポリシーやACLを変更しない』——つまりブロックは穴を塞がず覆うだけで、外せば公開が戻る。だから目標は『ブロックが有効』ではなく『ブロックを外しても公開されない状態』。ブロックはバケット単位でなくアカウント単位で掛ける（バケットポリシーはバケット側の設定を無効化できるため）。そして『公開』の定義は直感より広い。
よくあるセキュリティの失敗は、技術ではなく「前提」の失敗 — 4つの思い込みで整理する
事故は珍しい攻撃ではなく、決まった型から起きる。技術分類ではなく『誤った前提』で整理すると4つになる——既定値は安全なはず（設定を触っていない）、使っていないものは危なくないはず（閉じ忘れ）、何かあれば気づくはず（見えていない）、入力は検証すれば安全なはず（外部に決めさせすぎ）。どれも個々の技術知識ではなく、確認の習慣で塞がる。自分の環境で何を見ればよいかを型ごとにまとめた。
安全でないデシリアライズ — 危ないのは「データ」ではなく「データに型を選ばせること」
デシリアライズの危険は『変なデータが入ること』ではなく、形式によっては『どの型のオブジェクトを組み立てるか』を外部データが決められることにある。だから被害はデータの破損では終わらず、OWASPはサービス停止・アクセス制御の迂回・リモートコード実行を挙げる。対策の軸は2つ——JSONやXMLのような純粋なデータ形式に切り替えて型を選ばせない、そしてシリアライズ時に署名し、署名の無いものは復元しない。一部の仕組みは設定では安全にできず、使うのをやめる以外にない。
パスワードリセットの設計欠陥 — 認証を固めても、ここが弱いと全部通る
リセット機能は『パスワードを知らない人に、パスワードを作らせる仕組み』＝それ自体が認証経路。だから認証本体をいくら固めても、リセットが弱ければそこが実際の認証強度になる。壊れる型は5つ——推測できるトークン／失効しないトークン／メールに残り続けるリンク／リンクの宛先を外から差し替えられる（Hostヘッダ）／応答の差でアカウントの存在が分かる。OWASPが明示している要件と、仕様が数字を決めていない部分（長さ・期限）を分けて扱うのが実装の勘所。
プロトタイプ汚染（Node.js）— 本体が「脆弱性ではない」と定めた領域は、自分で守るしかない
プロトタイプ汚染は、外部入力に含まれる特殊なキーが再帰的マージなどを通って、JavaScriptの組み込みプロトタイプを書き換えてしまう欠陥。結果は2種類——設定した覚えのないプロパティが至るところに現れる（認可やオプションの判定が狂う）か、組み込みメソッドが消えてアプリが落ちる。重要なのは責任の所在で、Node.js公式は『これはNode.jsコアの脆弱性とは見なさない。ただしアプリと依存の層で防げ』と明記している。つまり待っていても誰も直さない。
レート制限と濫用対策 — 「回数を絞る」だけでは、総当りもコスト暴走も止まらない
レート制限の失敗は『緩すぎ』より『問いを立て違えた』ことで起きる。設計に必要な問いは3つ——誰を数えるか（IPは偽装され得るので、何を識別子にするかが先）、何を数えるか（回数だけでなくコスト・サイズ・件数）、上限に達したらどうするか（拒否は正規利用者へのDoSにもなる）。NISTは連続失敗100回までを上限としつつ、遅延やCAPTCHAで正規利用者を締め出すなと明記。OWASPはAPIの上限に『支出上限』を含めており、これが金銭被害の最後の砦になる。
セキュリティヘッダは「並べる」ものではない — 今も効くもの、もう要らないもの、入れると害になるもの
セキュリティヘッダは多く並べるほど良いものではない。3つに分けて考える——今も効くもの（CSP・HSTS・X-Frame-Options・nosniff・Referrer-Policy・Permissions-Policy）、もう役目を終えたもの（Expect-CTは2021年6月時点でほぼ不要）、そして入れると害になり得るもの（X-XSS-ProtectionはMDNが非推奨かつ非標準とし、安全なサイトにXSSを作り出しうると警告）。コピペ元の一覧が古いと、害のある設定まで一緒に持ち込むことになる。
サブドメイン乗っ取り（dangling DNS）— 自分のサーバーを一切触られずに、自社ドメインが敵の手に渡る
クラウド資源を消してDNSレコードを消し忘れると『dangling DNS』になり、第三者が同じFQDNの資源を作るだけでそのサブドメインを乗っ取れる。自社サーバーは無傷のまま、正規のサブドメインが敵のコンテンツを配る。怖いのは見た目だけではない——多くのWebアプリはセッションCookieをワイルドカードでサブドメインに晒しており、乗っ取られた側から読める。しかも公式ドキュメントは『証明書が守ってくれるという誤解』を名指しで否定している。対策は削除の順番を仕組みにすること。
2026年の情報漏えいは「脆弱性」より「正規の認証情報」で起きている — 国内事案の横断分析
2026年8月に公表された国内の主要事案を経路で分類すると、脆弱性型より認証情報型が多い。共通するのは『自分のサーバーは無傷なのに、外側の正規の入口から入られた』こと。当サイトの結論＝脆弱性管理を完璧にしても、この型は1件も止まらない。だから防御の重心を、パッチから『認証情報の寿命・範囲・置き場所』と『委託先とSaaSの棚卸し』へ移す必要がある。
CVE の直す順番はどう決めるか — CVSS・EPSS・KEV の使い分け
CVSSは深刻度、EPSSは悪用される確率、KEVは実際に悪用されている事実。測っているものが違うので、どれか1つで優先順位は決まらない。当サイトの実データ＝KEV掲載1,695件のうち64%はCVSS9未満、24%はEPSS0.1未満。だから『高スコアだけ直す』も『EPSSが低いから放置』も破綻する。順序は KEV→高EPSS→高CVSS、そして期限は自分の環境の到達可能性で決める。
osv-scanner の実務Q&A — pnpm対応・CVEの除外・オフライン実行・つまずくエラー
導入の次に出てくる実務の疑問だけを集めた。要点＝pnpm-lock.yamlは対応済み、除外は osv-scanner.toml の IgnoredVulns（期限付きで書ける）、オフラインは3つのフラグの関係を理解すれば迷わない。当サイトの視点＝スキャナは『既知の脆弱性』しか教えず、自分で固定したバージョンが古くなったことは教えてくれない。そこは別の仕組みで見る必要がある。
Next.jsとReactは脆弱性が多いのか — CVEの実データで見る「危ないのはどこか」
実データではReactコアの脆弱性はほぼ出ておらず、Next.jsは多く、しかも増えている。ただし中身を見ると、出ているのはMiddleware・キャッシュ・画像最適化・Server Actionsといったサーバー機能で、CWEもSSRF・デシリアライズ・認可迂回。当サイトの結論＝『フロントエンドが危ない』という理解は誤りで、Next.jsは実質サーバーである。だから守り方も、コンポーネントの書き方ではなくサーバー機能の使い方と更新運用に置く。
npm install 一発で認証情報が抜かれる — サプライチェーンワームからの守り方
依存を1つ入れる行為は、他人のコードを自分の権限で実行させる行為。だから防御は『インストールの瞬間』に置く。当サイトの視点＝署名やprovenanceは今回すり抜けられた以上、信頼の根拠にはできない。効くのは、インストール時スクリプトを既定で止める・依存を数日寝かせる・トークンを短命かつ最小範囲にする、の3点。そして感染が疑われるときは、失効させる順序を間違えないこと。
レンタルサーバーが不正アクセスされたとき、利用者は何をすべきか
事業者側の管理環境が侵害される類型は、利用者の設定では防げない。第二報で対象は契約者の会員情報へ広がり、レンタルサーバー利用者に限らない話になった。だから守り方は『防ぐ』から『被害範囲を縮める』に切り替える。当サイトの視点＝共用サーバーに置いた情報は読まれた前提で設計し、認証・バックアップ・秘密の置き場所を事業者の外へ分散させる。2026年8月のさくらインターネットの公表内容は、確定情報と調査中の項目を分けて読むことが最も重要。
ファイルアップロードの脆弱性とは — Webシェル/RCEを防ぐ設計と設定
アップロードの穴の本質は『受け取ること』ではなく『どこに置き、実行させてしまうか』。認証なしの投稿口＋型検証なし＋Web公開領域に保存＋そこでスクリプトが実行できる、が揃うとWebシェル→RCEで乗っ取られる。守りは多層：①エンドポイントに認証/権限＋CSRF②サーバー側で許可リスト＋中身検査③保存先はWeb公開領域の外（or実行無効化）④ファイル名を乱数化しパスは信用しない。1枚の壁でなく、各段の止め所を複数持つ。
ログインを付けただけで安心していないか — 認証と認可の違い
認証＝『誰か』を確かめること、認可＝『その人が何をしてよいか』を決めること。両者は別物で、ログインを付けただけでは認可にならない。データに所有者（user_id）でのスコープが無いと『ログイン＝全データ閲覧』になる（OWASP最上位の Broken Access Control）。さらに認証スキャフォールドの登録開放が重なると、第三者が登録して中に入れる。守りは、全クエリを所有者で絞る／不要な登録を閉じる／多層防御／監査・アクセスログを事故る前に／新規登録を検知。
パスワードの保管、みんなどうしてる？データで見る実態と安全な方法
代表的な調査では、約54%が記憶頼み・約33%が紙にメモ・パスワードマネージャー利用は約36%にとどまる。使い回しも約25%。一方 Verizon DBIR では漏洩の約38%に認証情報の侵害が関与し、漏洩DB内パスワードの約74%が使い回しだった。つまり“定番の保管法”ほど攻撃者に効く。安全な土台は、マネージャーで全部を別パスワードにし、重要アカウントはパスキー/MFAで守ること。
パスワードの安全な保存方法 — ハッシュ化とソルトの正しいやり方
サービス側でパスワードを安全に保存する実践ガイド。平文・暗号化・素のハッシュがなぜダメかを理解し、『ユーザーごとのソルト＋わざと遅い専用ハッシュ（Argon2id推奨、次点bcrypt/scrypt）』に集約する。自前実装せず標準関数を使い、コストは定期的に見直し、既存の弱いハッシュはログイン時に再ハッシュして移行する。
AI時代のセキュリティ対策｜個人開発者がいま固めるべき基本（優先順チェックリスト）
AIは“新しい弱点”より“既存の弱点を自動で・大量に突く”側を強くする。だから特別な新対策より、基本を正しい順で固めるのが最善の備え。CVE即パッチ＋依存監視、使い回し撲滅＋MFA、露出した秘密の除去、最小権限、公開面の縮小、ログ/IOCの備え、バックアップ——優先順チェックリストで。
AI時代に効くセキュリティ対策と“効かない”もの｜小規模でも狙われる理由
AI時代の4つの神話を正す。①小さいから狙われない→自動化が『人間が選ぶ』を消す②特別な新対策が要る→基本が最強③製品を入れれば安心→検知より起こさない設計が先④AI生成コードは速くて安全→脆弱性ごと出荷・公開前レビュー必須。効くのは地味な基本を正しい順で。
自分のドメインからの“なりすましメール”が届いた——乗っ取りとの違いと止め方
自分のドメインを名乗る不審メールが届いても、多くは“サーバー侵害”ではなく“差出人(From)の詐称”。SMTPはFromを自由に書けるため。ヘッダのAuthentication-Results・Received・Reply-Toを読めば侵害か詐称か見分けられる。受信箱まで届く主因はDMARC未設定。SPF→DKIM→DMARC(p=none→reject)の段階導入で止める。
バックアップの基本：3-2-1ルールとランサムウェアに耐える復元計画
バックアップは『取ってある』では不十分で、『復元できると確認済み』だけが本物。基本＝3-2-1ルール(3コピー・2種類のメディア・1つはオフサイト)。さらにランサム対策には、常時接続でない『オフライン/不変(immutable)』のコピーが少なくとも1つ要る——常時繋がったバックアップは本体ごと暗号化される。クラウド同期はバックアップではない(誤削除や暗号化も同期する)。世代管理と定期的な復元テストまでが運用。
gitleaksでコミット前に秘密を止める：APIキー漏洩をpushの前で食い止める
秘密は『漏れてから消す』では遅い。一度コミットされた秘密はGit履歴に残り、pushされたら漏れた前提で鍵の失効・ローテートが要る。gitleaksはリポジトリ全体とコミット履歴を正規表現/エントロピーでスキャンし、APIキー・秘密鍵・トークンを検出する無料ツール。守りの要は二段の止め所＝①pre-commitフックでローカルのpush前に止める②CI/cronですり抜けを定期的に捕まえる。.gitignoreは新規追跡を防ぐだけで検出はできない＝検出器が別途要る。
二要素認証(MFA)の正しい選び方：SMSより強い「フィッシング耐性」とは
MFAは『パスワードが漏れても入られない』ための二重ロックだが、何を付けたかで強さが3段違う。SMS/メールはフィッシング中継・SIMスワップで破られる弱い方式、認証アプリ(TOTP)は中、パスキー/物理キー(FIDO2)は偽サイトに出せない『フィッシング耐性』で別格。最優先は王国の鍵（メール・ドメイン・決済）にフィッシング耐性MFAをかけること。リカバリーコードの保管とバックアップ手段の用意までが正しい運用。
Windows 10をまだ使っている人へ：サポート終了後のセキュリティリスク
Windows 10は2025年10月14日でサポート終了済み。使い続ける最大のリスクは『見つかっても二度と直らない穴（forever-day）』が積み上がり、攻撃者に狙われやすくなること。個人向けESU延長は2026年10月13日までの1年だけ・セキュリティ修正のみの時間稼ぎ（無料の登録ルートあり、ただしEEA初年度無料は日本対象外）。本筋はWindows 11への移行か機器更新で、ESUはその移行を終わらせるまでの橋として使う。
BitLockerと『デバイスの暗号化』の違い — 同じ技術の、フル版と自動・簡易版
BitLockerとデバイスの暗号化は同じ暗号エンジン。デバイスの暗号化＝Homeでも使える自動・簡易版（MSアカウントで自動ON・回復キーも自動退避・設定最小）。BitLocker＝Pro以上のフル版（起動PIN・外付け暗号化(To Go)・細かい管理）。個人なら自動暗号化＋回復キーの所在把握で十分なことが多い。製品名より“暗号化されている状態”が本質。
脆弱性(CVE)対応の実務：直しきって、再発を監視し続ける手順
脆弱性対応は『直した』で終わらない。完了＝①スキャン②修正③隔離/引き継ぎ④監視の4点が揃って初めて。特に監視（日次の変化検知）を載せるまでは未完——依存は明日また脆弱になるから。修正の中身が100点でも、次のデプロイで消える運用なら0点。小さな現場こそ、自動の変化検知と『local→push→deploy』の規律で驚くほど守れる。
ノートパソコンを持ち歩くときのセキュリティ対策 — 盗難・紛失・覗き見への備え
ノートPC持ち歩きの前提は『いつか失くす・盗まれる』。本命は“失くしても中身が漏れない”設計＝①ディスク暗号化(BitLocker/FileVault) ②強いログイン+短い自動ロック ③遠隔ワイプ/位置追跡。公共Wi-FiはHTTPS普及で盗聴リスクが下がり、本当の脅威は偽AP・覗き見・離席。VPNを過信せず、暗号化とロックを最優先に。
osv-scannerの導入と使い方：依存パッケージのCVEを機械で見つける
osv-scannerはロックファイルやコンテナを走査して依存のCVEを洗い出す無料ツール。導入・実行・CI組込みを手順化し、npm/pnpm audit・Dependabotとの使い分けまで整理する。当サイトの視点＝ツール選びの正解は『あなたの構成』で決まる。複数言語混在やGitHub非依存ならosv-scanner、単一npmなら同梱のpnpm auditで十分。
パスワードマネージャーは安全？仕組みとクラウド・ローカルの違い、選び方
パスワードマネージャーは、使い回し・平文保存より確実に安全。鍵はゼロ知識暗号＝マスターパスワードで端末側だけが復号でき、提供元は暗号文しか持たないので、提供元が破られても中身は出ない。本当の単一障害点はマスターパスワードと金庫のMFA。クラウド型(Bitwarden/1Password)とローカル型(KeePass)を用途で選ぶ。
公共Wi-Fiの危険性 — 本当に怖いのは『盗聴』ではなく、偽APと証明書警告の無視
公共Wi-Fiの『盗聴』はHTTPS普及で大半が暗号化され、優先度は下がった。本当のリスクは①偽AP(evil twin)に自分から繋ぐ②証明書警告を無視する③同じネットワークに端末を晒す。最強の対策は意外とシンプル＝スマホのテザリングを使う・HTTPSと証明書警告を信じる・知らないSSIDに自動接続しない。VPNはその次の追加策。
公開ディレクトリに秘密ファイルを置き忘れていないか：webrootの棚卸し
webroot（公開ディレクトリ）に置いたファイルは、URLを叩けば誰でも取得できる。トークンや認証情報のJSON・.env・バックアップを置き忘れると即・実害。さらに共通テンプレート由来なら全サイトに同じ穴が横展開する。対策＝公開ディレクトリには公開してよい物だけ、秘密はwebroot外＋権限600、そして自分のサーバーを棚卸しして1か所見つけたら全台点検。
個人開発・小規模運営のセキュリティ最低限：業界標準の対策を全部セットで
最低限の対策は『全部同じ重さ』ではない。当サイトの優先順位＝①王国の鍵（多要素認証・ドメイン・メール）②秘密とコード③アプリ本体④パッチ・検知・復元。リソースが有限な個人は、この順で上から埋めるのが正解。多くの事故は新種の攻撃ではなく、この土台の抜けから起きる。
中規模〜大規模組織のセキュリティ最低限：チームで守る標準の土台
規模が上がると最低限は『チェックリスト』から『オーナーのいるプログラム』に変わる。優先順位は個人版と同じ＝①アイデンティティ②秘密とサプライチェーン③アプリと基盤④検知と対応＋横断の人とガバナンス。最大の変化は、事故の主因が『うっかり』から『人・プロセス・退職者の権限・第三者』へ移ること。
セキュリティの棚卸し — 複数サーバーを個人運用する人が見落とす点検7項目
複数サーバーを個人運用する人の事故は「足りない対策」より「把握していない状態」が原因になりがち。守る境界は鍵を置いたPC。2FAは信頼の連鎖でティア化、SSH鍵はマトリクス化して重複・未使用・孤児を消す、平文パスワードはクラウドから消す、是正は可逆に1つずつ、台帳に機密は書かない。派手な新ツールより棚卸しが先。
自前のGitサーバーとGitHub、セキュリティ的にどっちが安全か
自前Gitは『安全になる』のではなく『リスクを移し替える』。誤公開という事故クラスは消えるが、サーバのパッチ・バックアップ・コミット前の秘密検出という責任が自分に移る。条件を満たせば良い選択、放置すればGitHubより危険。当サイトの視点＝自前運用は代償とセットでなければ成立しない。
スマホを安全に使う基本 — 守るべきは『鍵束・金庫・身分証』が1台に詰まった端末
スマホは二要素・メール・銀行・身分証が1台に集中した単一障害点。守りの本命はセキュリティアプリでなく、①強いロック＋短い自動ロック（パスコードが暗号化の鍵）②OS/アプリ自動更新 ③公式ストア＋権限見直し ④紛失時の遠隔ロック/ワイプを事前設定 ⑤二要素の“予備”（紙のバックアップコード）。OSは標準で暗号化・サンドボックス済み。
侵害され得る環境にroot鍵を渡さない：SSH鍵の最小権限
一時的で侵害され得る環境（GPU pod・CIランナー・使い捨てVM）から本番へroot鍵を登録すると、その環境が侵害された瞬間に本番がroot権限で抜かれる。対策＝一時環境にroot鍵を置かない／使わなくなったら消す／再度必要なら非rootユーザー＋command制限鍵（command="..." restrict）で操作を1つに限定。使い回し鍵は最重要資産で、1つ漏れたら全部、という構成を作らない。
パスワードをGoogleドライブに保存するのは安全？正しい保管方法
平文のGoogleドキュメント/スプレッドシートにパスワードを一覧保存するのは危険。理由＝Googleアカウント1つが全パスワードの単一障害点になり、乗っ取り・不正連携アプリ・フィッシングで一気に全部漏れる。正解は専用パスワードマネージャ（端末間でも中身は暗号化）。どうしてもDriveを使うなら暗号化済みの管理ファイルだけ＋アカウントにフィッシング耐性MFA。
OpenAIアカウントBANの理由と対処——盗まれたAPIキーが『蒸留』違反に問われるとき
盗用されたAPIキーが『蒸留』に悪用されると、被害者のアカウントまで自動凍結されることがある。仕組み・予防・異議申し立ての筋道を、固有の事例情報を伏せて整理します。
X-Forwarded-For（XFF）偽装とは — 信頼するプロキシ設定の落とし穴と防御
XFFはクライアントが詐称できるヘッダ。偽XFFにインジェクション探索を仕込む無差別スキャンの典型と、『全プロキシ信頼（ワイルドカード）』の危うさ。対症療法＝IPヘッダのサニタイズ、根本＝信頼するプロキシの適正化。実害ゼロでも直すべき設定がある。
AIで書いたコードからAPIキーが漏れ、不正課金された——本当の原因は放置したCVSS 10.0だった
請求の暴騰は氷山の一角。真因は放置した公開済みCVSS 10.0のRCEだった。固有名詞を伏せた事例から、防御の教訓を抽出します。
セキュリティ超入門：.env と APIキーは何が危なくて、どう守るのか
最初の一歩。.env と APIキーが漏れると何が起きるか（合鍵→なりすまし→不正課金）を理解し、『公開しない・コミットしない・漏れたら全部替える・自己点検する』の4つを今日から始める。
Laravelアプリの .env が全世界に公開されていた——共用レンタルサーバーで一番ありがちな配置ミス
原因は『アプリ本体をpublic_html直下に置いた』こと。public/ だけを見せるべきだった。応急処置→鍵ローテ→構造改修の三段で直し、再発を仕組みで防ぐ。
Next.js を安全に運用する：公開済みCVEに後れを取らないしくみ
フレームワークの最大リスクは公開済みCVEの放置。実稼働版で判定し、Dependabot/osv-scannerで機械監視、迅速更新、最小権限の4本柱で守る。当サイトの視点＝個人開発者が負けるのは知識でなく『運用の継続性』。速さより見落とさない仕組みで勝つ。
レンタルサーバーで .env を公開しないための配置と設定
本命は『アプリ本体をdocrootの外、public/ だけ公開』。まず .htaccess で止血し、構造改修で恒久化、最後に自己点検。当サイトの視点＝これは個人のミスでなく業界的な“悪手の標準化”。だから注意力でなく仕組みで防ぐ。symlinkより bootstrap-redirect が堅い。