security-and-hardening
外から入る値を扱う Web アプリのコードを書く・見るときに、先に脅威を洗い出させ、「必ずやる」「先に聞く」「やらない」の 3 段の線に沿って守りを固めさせる。依存の監査、個人データ、LLM の出力の扱いまで点検させる
npx skills add addyosmani/agent-skills/security-and-hardening入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 75,233
- 実用度
- 23
- GitHub star
- 113,697
- 最終更新
- 2026/11/2
頼み方の例
そのままコピーして使えますsecurity-and-hardeningスキルを使って、このリポジトリのログインとパスワード再設定の処理を点検してください。信頼の境界と STRIDE の表を先に出し、見つかった問題を重い順に並べてください。コードの書き換えと依存の更新はまだしないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 認証情報の置き場所に触れる記述があります
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
この解説は再確認中です。 2026年11月6日に原本（SKILL.md）が更新されており、以下の解説が現在の内容と合っていない可能性があります。最新の内容は GitHub の SKILL.md を確認してください。
いつ使うか
利用者の入力・認証・機密のデータ・外部のサービスに触れるコードを書くとき、見るときの手引きです。本文の「使うとき」は、利用者の入力を受け取るもの、認証や認可、機密のデータの保存や送信、外部の API との連携、ファイルのアップロードや Webhook、決済や個人情報の扱い、の 6 つです。
説明文はさらに、入力の処理の監査、ログインの流れを OWASP Top 10 に照らす点検、依存の既知の脆弱性の監査、新しいパッケージの供給網の評価、GDPR や CCPA が関わる場面を挙げています。
- 必ずやる・先に聞く・やらない の線
- 3 段
- STRIDE で見る脅威
- 6 つ
- 同梱ファイル（2026-10-23 時点）
- 1 件
- SKILL.md（2026-10-23 時点）
- 17,559 バイト
守りを足す前に、脅威を洗い出す
本文の最初の決まりは、脅威の洗い出し無しに足した守りは当て推量だ、というものです。攻撃する側に立って 5 分考えよ、として 4 つの手順を置いています。
- 信頼の境界を描く信頼できない値がどこから入るか。HTTP、フォーム、Webhook、外部の API、LLM の出力、ほかのプロセスのコマンドライン
- 守るものを挙げる資格情報、個人情報、決済のデータ、管理の操作、お金の動き
- 境界ごとに STRIDE を当てるなりすまし・改ざん・否認・漏えい・サービス妨害・権限の昇格
- 悪用の場面を書く機能ごとに「どう悪用するか」を考え、それを最初の試験にする
値を信じてよいかは、どの経路で届いたかではなく、誰が書いたかで決まる、という考え方が全体を通っています。境界を挙げられないなら守る準備ができていない、と本文は書いています。
3 段の線
| 段 | 主な中身 |
|---|---|
| 必ずやる（例外なし） | 境界での入力の検証、問い合わせのパラメータ化、出力のエスケープ、HTTPS、パスワードのハッシュ、セキュリティのヘッダー、Cookie の属性、出荷前の依存の監査 |
| 先に聞く（人の承認） | 認証の流れの追加や変更、新しい種類の機密データの保存、外部連携の追加、CORS の変更、アップロードの処理、流量制限の変更、権限の付与 |
| やらない | 秘密情報のコミット、機密のログ、クライアントの検証を境界と見なす、ヘッダーを外す、利用者の値で eval() や innerHTML、認証のトークンを localStorage に、スタックトレースを見せる |
「必ずやる」は 8 項目、「先に聞く」と「やらない」は 7 項目ずつです。
守りの項目は 11 の節に分かれる
それぞれの節が決まりを述べ、具体的なコードは同梱の references/hardening-patterns.md の該当の節を、そのコードに着いたときに開け、という作りです。
- 注入・XSS・アクセス制御問い合わせのパラメータ化、自動エスケープ、資源ごとの認可（IDOR）
- 認証とセッションbcrypt は 12 ラウンド以上か scrypt・argon2。Cookie は httpOnly・secure・sameSite
- ヘッダー・CORS・応答CSP は default-src 'self' から締める。資格情報付きで * にしない
- 入力の検証とアップロード境界で型を決めて検証し 422 で返す。拡張子は何も証明しない
- サーバーからの取得（SSRF）送り先を許可の一覧に絞り、私的なアドレスを拒み、転送を禁じる
- 派生した経路への破壊的な操作許可した根の下、根より 1 段下、操作の前に読んだ持ち主の証拠
- 流量制限認証は 15 分に 10 回ほど。複数の処理なら共有の保存先で数える
- 秘密情報環境変数から。リモートに届いたら漏れたと見なし、先に鍵を替える
- 依存と供給網管理の道具を特定し、依存の実行スクリプトを止め、監査を到達性で仕分ける
- 個人データとプライバシー分類、目的、保存の期限、消せる作り、同意
- AI と LLM の機能モデルの出力は信頼できない入力。システムプロンプトは境界ではない
消す・動かす・上書きする前の 3 つの条件
特徴的なのは、削除や移動の対象の経路が外から来るときの節です。形が正しい（絶対経路で 1 段以上深い）という確認は整っていることの証明で、許可の証明ではない、と書いています。
求める条件は 3 つで、シンボリックリンクを解いたあとの対象が許可した根の下にあること、根そのものではなく 1 段以上下であること、操作の前に読んだ「自分のものだ」という証拠があることです。断ったら記録して止まり、広い既定の経路に逃げるな、とも書いています。
参考の資料はこの確認の限界も書いています。木の中の目印は自己申告で、書ける者なら誰でも置けること、経路を解いてから名前で操作するあいだに入れ替えられる隙があることです。
依存の監査は「到達するか」で仕分ける
依存の節は 4 つの手順です。管理の道具とロックファイルを突き合わせて食い違えば止まる、依存の実行スクリプトを最初の実行の前に止める、出荷の前ごとに監査を流して重いものを到達性と修正の有無で仕分ける、監査は既知の勧告しか照らさないので新しい依存は持ち主・保守・公開からの日数・出自もあわせて見る、です。
npm audit fix --force のような強制の修正は自動で当てるな、と明記されています。先送りにするなら理由と見直しの日付を書け、という指示もあります。
LLM を呼ぶ機能も攻撃面
LLM を使う機能は OWASP の LLM 向けの Top 10（2025 年版）に照らせ、としています。モデルの出力を eval・SQL・シェル・innerHTML・ファイルの経路に渡さない、取り込んだページや PDF の中の指示で乗っ取られうる、権限はコードで強制する、が要点です。
使わないほうがいいとき
- Firebase のセキュリティルールを見たいルールの書き方と点検に絞った側
- Better Auth の設定を固めたい認証の道具の作法に絞った側
- 変更全体のレビューをしたい5 つの軸で差分を見る側
道具や基盤が決まっているなら
このスキルは Web アプリ全般の決まりで、特定の基盤の設定までは踏み込みません。Firebase のルールなら firebase-security-rules-auditor、認証に Better Auth を使っているなら better-auth-best-practices のほうが具体的です。
差分のレビューが目的なら
取り込む前の変更を正しさ・設計・性能も含めて見たいなら、同じ公開元の code-review-and-quality が入口です。そちらはセキュリティの軸について、詳しくはこのスキルを見よ、と案内しています。
自動の検査の道具ではない
このスキルは手引きと点検表で、コードを走査する検査の道具は同梱していません。静的解析や侵入試験の代わりにはならないので、それらが要る場面では専用の道具と組み合わせてください。
注意点
SKILL.md には、外部のサービスへ送る記述はありません。シェルで動かすのは、パッケージマネージャーの監査、npm audit signatures のような署名の確認、コミット前に差分から秘密情報を探す grep です。
「先に聞く」の項目で止まる
認証の流れ、CORS、アップロード、流量制限、権限の付与などを変えるときは、人の承認を求めて止まります。まとめて任せたいときも、どこまで承認するかを先に伝えておくと進みが読みやすくなります。
CSP を入れるとほかのものが動かなくなることがある
「必ずやる」に CSP があり、default-src 'self' から締めよ、と書かれています。広告や解析のタグのような外部のスクリプトを読むサイトでは、そのまま当てると読み込みが止まることがあるので、何を許すかを先に洗い出してください。
名指しされる先と点検表は、このフォルダの外にある
出荷前に通る点検表 ../../references/security-checklist.md は、リポジトリの直下にあり、スキルのフォルダの外です。本文が名指しする observability-and-instrumentation と debugging-and-error-recovery も、同じリポジトリの別のスキルです。
このスキルのフォルダには SKILL.md と参考の 1 件しかありません。1 件だけ入れると、点検表と名指しの先は手元に無いことがあります。
例のコードは TypeScript と Express が中心
参考の資料のコードは、express-rate-limit や @upstash/ratelimit などを使った TypeScript の例です。ほかの言語やフレームワークでは、同じ決まりを自分の道具に置き換えて当てることになります。
ライセンス
リポジトリのライセンスは MIT です。
インストール数の推移
日次で記録10月14日 〜 11月7日（24日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
code-review-and-quality
取り込む前の変更を、正しさ・読みやすさ・設計・セキュリティ・性能の 5 つの軸で見させる。指摘には重さの札を付けて大事なものから並べさせ、試験が回帰を捕まえるかは条件を 1 つ反転させて実際に確かめさせる
better-auth-best-practices
Better Auth の設定を、入っている版のドキュメントに合わせて書かせる。移行の混線を防ぐ
firebase-security-rules-auditor
Firestore のセキュリティルールを、攻撃側の視点で読み直させる。5 段階で採点まで
よくある質問
見つけた脆弱性を直すところまでしますか
本文は守りの書き方と点検の手引きなので、頼めば直すところまで進みます。ただ、認証の変更や CORS の変更などは「先に聞く」の段にあり、人の承認を求めます。点検だけでよいなら、書き換えないよう頼むときに伝えてください。
`npm audit fix` を勝手に流しますか
強制の修正（npm audit fix --force など）は自動で当てるな、と本文に書かれています。更新は内容を先に見て、変更履歴を読み、1 つずつ試験で確かめる扱いです。重いものは、実行・ビルド・試験・配備の経路で到達するかと、修正があるかで仕分けます。
システムプロンプトで禁止すれば守れますか
本文は、システムプロンプトはセキュリティの境界ではない、と書いています。利用者の発言や取り込んだページに指示が紛れ込みうるので、権限はコードで強制し、道具の引数をすべて検証し、破壊的な操作は確認を取れ、という扱いです。
対応しているエージェントはどれですか
公開元の README が、Claude Code（推奨と明記）と Codex のそれぞれに入れ方を案内しています（2026-10-23 確認）。README はほかに Cursor・Gemini CLI・GitHub Copilot などへの入れ方も載せていますが、当サイトが表示しているのは Claude Code と Codex の 2 つです。