認証・認可でログインまわりを守れても、Webアプリには開発中に気をつける穴がいくつもあります。その入口をまとめます。
初級の解説は準備中のため、初級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
根っこの考え方
すべての土台は「外から来たものは信用しない」。ブラウザから届く値も、URLのパラメータも、疑ってかかる。これを忘れると、次のような穴になります。
守りの主なポイント
- 入力の検証 — 外から来た値を、そのまま使わず確かめる（型・範囲・形式）
- XSS対策 — 出力を安全にして、他人のブラウザで悪いスクリプトを動かされないように
- CSRF対策 — ログイン中を悪用した「勝手な操作」を防ぐ
- SQLインジェクション対策 — 入力を通じてDBに不正な命令を送らせない
- 秘密情報の管理 — 鍵・パスワードをコードに直書きせず、隔離する
攻撃は、アプリと外の世界が触れ合う「境界」で起きます。だから守りも、境界ごとに置きます。
アニメーション『攻撃は境界で起きる』を開く
それぞれの詳しい手口と防ぎ方は、この下の各テーマで扱います。
大事な姿勢
- 多層で守る — 1つの対策に頼らず、入力検証・出力エスケープ・権限確認を重ねる
- サーバで最終確認 — フロントのチェックは親切機能。本当の守りはサーバ側
- 既定は安全側 — 迷ったら「拒否・非公開」から始める
⚠️ 定番の事故
- 入力をそのまま画面に出す → XSS
- 入力をそのままDB命令に混ぜる → SQLインジェクション
- 鍵をリポジトリに置く → 秘密情報の漏洩
- 公開設定のミス → 見えてはいけないデータの露出
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. Web開発の守りで、いちばん根っこにある考え方は？
問2. 秘密の鍵やパスワードの扱いとして正しいのは？
問3. 入力をそのまま画面（HTML）に出してしまうと起きる定番の事故はどれ？
問4. 鍵やパスワードをソースコードのリポジトリに置いてしまうと、何が起きる？
問5. フロント（ブラウザ側）のチェックの位置づけとして正しいのは？
問6. 作りかたに迷ったときの「既定（デフォルト）」として安全なのは？
問7. 入力をそのままDBの命令に混ぜて不正な操作をさせる攻撃を、何インジェクションと呼ぶ？
問8. 1つの対策に頼らず、入力検証・出力エスケープ・権限確認などを重ねて守る考え方を「◯◯防御」と呼ぶ。◯◯は？