バックエンド
サーバ側の処理。要求を受け、データを扱い、応答を返す。
責務#
| 責務 | 内容 |
|---|---|
| ルーティング | URL とハンドラの対応 |
| 認証・認可 | 誰か、何をしてよいか |
| 業務ロジック | アプリ固有の規則 |
| データ永続化 | 読み書き |
| 検証 | 入力を信用しない |
| 監視・ログ | 何が起きたか |
入力を信用しない#
クライアント側の検証は利便性のためであって、 セキュリティのためではない。 リクエストは自由に改変できる。
| 攻撃 | 対処 |
|---|---|
| SQL インジェクション | プレースホルダ(文字列連結をしない) |
| XSS | 出力時のエスケープ、CSP |
| CSRF | トークン、SameSite Cookie |
| 権限昇格 | すべての操作で認可を検査する |
| 大量リクエスト | レート制限 |
「ID を指定して取得する」API で その ID が本人のものか検査していないという誤りは非常に多い (OWASP でも最上位に挙げられている)。
スケール#
| 方向 | 内容 |
|---|---|
| 垂直 | 1 台を強くする。単純だが上限がある |
| 水平 | 台数を増やす。ステートレスである必要がある |
セッションをメモリに持つと水平にスケールできない。 外部(Redis など)に出すか、 トークンに含める設計にする。
観測可能性#
| 種類 | 内容 |
|---|---|
| ログ | 何が起きたか。構造化する |
| メトリクス | 数値の時系列。レイテンシ、エラー率 |
| トレース | 1 リクエストが辿った経路 |
分散したシステムでは、 ログだけでは何が起きたか分からない。 リクエスト ID を全体で引き回す設計が要る。
参考文献#
- Roy T. Fielding, Mark Nottingham, Julian Reschke (eds.). HTTP Semantics. RFC 9110, 2022. https://doi.org/10.17487/RFC9110
- OWASP Top 10. https://owasp.org/www-project-top-ten/
- Martin Kleppmann. Designing Data-Intensive Applications. O’Reilly, 2017.