secure-input-handling
Skill0 starsChanged 4 months agoMITView on GitHub
OWASP-based secure coding checklist applied while writing code: whitelist input validation, parameterized queries, auth/session handling, file upload safety. Use when writing code that handles user input, SQL, authentication, sessions, file uploads, or external data — apply proactively during implementation, before the code is committed. For explicit security audits/reports use security-best-practices instead.
- Reads credentials
In this repository14 other files it gives its agents.
- ai-code-verificationSkill
- ci-cd-hardeningSkill
- error-handling-robustnessSkill
- legacy-code-navigationSkill
- logging-observabilitySkill
- naming-readabilitySkill
- performance-optimizationSkill
- plan-then-codeSkill
- project-conventionsSkill
- refactoring-disciplineSkill
- safe-release-practicesSkill
- scalability-designSkill
- test-suite-designSkill
- web-api-designSkill
The file
Files
Secure Input Handling
ユーザー入力・外部データを扱うコードを書いている最中に適用するチェックリスト。監査・レポート作成が目的ではなく、実装中に自動的に安全な形にすることが目的(明示的なセキュリティ監査・レポートを求められた場合はsecurity-best-practicesを使う)。
適用手順
1. 入力検証(すべての入力受付点で最初に行う)
- 「許可される値」をホワイトリストとして明確に定義する。デニリスト(禁止パターンの列挙)は補助防御に留め、主防御にしない。
- 固定選択肢(enum、ドロップダウン由来の値)は提示された値との完全一致で検証する。
- 正規表現を使う場合は文字列全体を
^...$でカバーし、無制限の.*や入れ子の量指定子を避ける(ReDoS対策)。 - 長さ制限・数値範囲・型変換を必ず行い、変換失敗時は例外を握りつぶさず明示的に拒否する。
- クライアント側検証はUX目的のみとし、サーバー側で必ず同じ検証をやり直す(クライアント側は迂回可能)。
2. SQL・クエリ実行(DBアクセスコードを書くたびに確認)
優先順位に従って選ぶ:
- 第一選択:パラメータ化クエリ(プレースホルダ)でSQL文とデータを分離する。文字列結合・テンプレートリテラルでSQLを組み立てない。
- 第二選択:ストアドプロシージャ(ただし内部で動的SQL文字列結合をしていないことを確認する)。
- 第三選択(テーブル名・カラム名など動的に変える必要がありバインド変数が使えない場合のみ):許可された識別子のホワイトリストにマッピングしてから組み込む(switch文等で明示的に対応)。
- ソート順(ASC/DESC)等の構文要素はenum/真偽値に変換してから組み込み、ユーザー入力文字列を直接埋め込まない。
- 追加の多層防御:アプリ用DBアカウントは機能ごとに分離し最小権限のみ付与する。DBA権限を絶対に付与しない。
3. 認証・セッション管理(ログイン・認可機能を書くとき)
- パスワードは専用のハッシュ関数(bcrypt/argon2/scrypt)で保存する。平文保存・自前の暗号化・弱いハッシュ(MD5/SHA1単体)は使わない。
- ログイン成功時にセッションIDを再生成する(セッション固定攻撃対策)。
- ステート変更を伴うリクエスト(POST/PUT/DELETE)にはCSRF対策トークンを付与し検証する。
- 多要素認証(MFA)を後付けしやすい設計にしておく(認証ロジックを1箇所に集約する)。
- 認可チェックはUI層だけでなく必ずサーバー側(API層)でも行う。
4. 出力エンコーディング(XSS対策)
- テンプレートエンジンの自動エスケープを無効化しない。無効化が必要な場合は理由をコメントで明記し、その箇所だけサニタイズ処理を追加する。
- ユーザー入力をHTML/JS/URL/CSSのいずれのコンテキストに出力するかで、適切なエンコーディング関数を使い分ける。
innerHTML等のDOM直接操作でユーザー入力を扱わない(テキストノードとして挿入する、またはサニタイズライブラリを通す)。
5. ファイルアップロード
- 拡張子・MIMEタイプをホワイトリストで検証する(クライアントが送るMIMEタイプは偽装可能なので、内容ベースの検証も検討する)。
- 最大サイズ制限を設定する。
- 保存時はユーザー入力のファイル名をそのまま使わず、ランダムなファイル名を生成する(パストラバーサル対策)。
- 可能であればマルウェアスキャン等の内容検査を行い、アップロード先を実行権限のないディレクトリ・別ドメインにする。
6. 秘密情報の取り扱い
- APIキー・パスワード・トークンをコード・ログ・エラーメッセージに直接書かない。環境変数または秘密管理サービス経由で読み込む。
.envは.gitignoreに登録し、.env.exampleにはキー名のみを記載する。
チェックリスト(実装完了前に確認)
- すべての入力受付点でホワイトリスト方式の検証を行っている
- クライアント側検証だけに頼っている箇所がない
- SQL/クエリはすべてパラメータ化されている(文字列結合によるSQL組み立てがない)
- パスワードは専用ハッシュ関数で保存している
- ログイン成功時にセッションIDを再生成している
- 状態変更リクエストにCSRF対策がある
- テンプレートエンジンの自動エスケープを無効化していない
- ファイルアップロードは拡張子・サイズ・保存名(ランダム化)を検証している
- 秘密情報がコード・ログ・エラーメッセージに直書きされていない
アンチパターン集
| アンチパターン | なぜ問題か | 代わりにすること |
| 文字列結合でSQL文を組み立てる | SQLインジェクションの直接原因になる | パラメータ化クエリ/プレースホルダを使う |
| デニリスト(禁止文字の除去)だけで入力検証を済ませる | 想定していないパターンで迂回される | ホワイトリスト(許可される値の定義)を主防御にする |
| クライアント側バリデーションのみで満足する | devtoolsやAPI直叩きで容易に迂回される | サーバー側でも同じ検証をやり直す |
| パスワードを自前ロジックで暗号化・可逆化して保存 | 漏洩時に即座に平文復元されるリスク | bcrypt/argon2等の専用ハッシュ関数を使う |
| アップロードファイル名をそのままサーバーに保存 | パストラバーサルや上書き攻撃を許す | ランダムなファイル名を生成して保存する |
| テンプレートの自動エスケープを「表示が崩れるから」無効化する | XSSの直接原因になる | 無効化せず、必要な箇所だけ個別にサニタイズする |
| エラーメッセージにSQL文やスタックトレースをそのまま含める | 攻撃者に内部構造のヒントを与える | ユーザー向けメッセージと内部ログを分離する |
| APIキーをコードやログに直接出力する | リポジトリ・ログ経由での漏洩リスク | 環境変数・秘密管理サービスを使い、ログにマスクする |
出典
- OWASP Cheat Sheet Series(CC BY-SA 4.0)— Input Validation, SQL Injection Prevention, Authentication, Session Management各Cheat Sheetの要約
- 上記は要約・手順化したものであり、原文の丸写しはしていない。ライセンス表示義務(CC BY-SA 4.0)に留意すること。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

