📚

セキュリティ基礎まとめ:HTTPS / OWASP / CORS / CSP / SSL/TLS / Server / API

に公開

はじめに

ここは“用語だけ知ってる”と落とし穴にハマりやすい領域。この記事では、それぞれの意味と「最低限ここだけは実装する」指針を短く整理します。必要なところから深掘りできるように、公式ドキュメントへのリンクも添えています。

HTTPS / SSL/TLS

なぜ必要か:通信の盗聴・改ざん・なりすまし(MITM)を防ぐため。HSTSで「常にHTTPS」を強制するのが定番。
どうやるか

  • TLSは1.2以上(可能なら1.3)。弱い暗号スイートは無効化。
  • 本番でHSTS有効化。まず短いmax-age→問題なければ長期化。includeSubDomainsは段階的に。

OWASP Top 10(リスク地図)

なぜ必要か:実運用で“本当にやらかす”代表例集。まずは自分のAPIがどれに当たりやすいか棚卸しする。
どうやるか(まず優先すべき3つ)

  • アクセス制御の不備:サーバ側で必ず認可チェック(ルート/メソッド/リソース単位)。
  • 暗号の失敗:パスワードはpassword_hash()/Hash::make()(bcrypt/Argon2)。通信はTLS必須。
  • インジェクション:プレースホルダ/ORM・入力検証・エスケープの徹底。

CORS(Cross-Origin Resource Sharing)

なぜ必要か:ブラウザが“どのオリジンからのリクエストを許すか”を判断する仕組み。雑に*だと漏えい。
どうやるか

  • Access-Control-Allow-Originに許可ドメインを明示(認証ありは*不可)。
  • Cookie送信が必要ならAccess-Control-Allow-Credentials: true+Originは厳密指定。
  • Preflight(OPTIONS)を正しく実装(Access-Control-Allow-Methods/Headersなど)。

CSP(Content Security Policy)

なぜ必要か:XSS対策の切り札。実行可能なスクリプト/リソースの出所をホワイトリストで縛る。
どうやるか

  1. Content-Security-Policy-Report-Onlyでまず計測運用(違反レポートを集める)。

  2. 問題を潰したらContent-Security-Policyを本番適用。
    例(初手の最小構成)

    default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'
    

    可能なら'unsafe-inline'は避け、nonce-...sha256-...で許可。

サーバセキュリティ(基盤の堅牢化)

なぜ必要か:アプリが安全でも、OS/ミドルの穴で破られる。
どうやるか

  • 最小権限:不要サービス停止、ファイアウォール、実行ユーザー分離、IAMの最小化。
  • パッチ管理:自動更新/イメージ更新、構成のコード化(IaC)でドリフト防止。
  • 監査/検知:失敗ログイン・権限エラー・レート超過にアラート。
  • コンテナ/オーケストレーション利用時はイメージ署名・secret管理・ランタイム制御も。

APIセキュリティ(ベストプラクティス)

なぜ必要か:APIは認証・認可・可用性の三点で狙われやすい。
どうやるか(チェックリスト)

  • 認証:HTTPS必須。Bearer(JWT/OAuth2)or APIキー。機密操作はスコープ/ロールで最小権限。
  • 入力検証:サーバ側スキーマ、型/長さ/列挙制限、ファイルサイズ制限。
  • レート制限:429 Too Many Requests運用。キー/トークン単位でスロットリング。
  • エラー:内部情報(スタック/SQL/ファイルパス)を出さない。エラーIDで問い合わせ可能に。
  • 監査:リクエストID付与、重要操作の監査ログ、異常検知のしきい値。
  • 暗号:保存時も暗号化(KMS/鍵ローテーション)。機密レスポンスはキャッシュ制御。
  • CORS/CSP/HSTS:上記ガイドどおり適用。

まず何からやる?

  1. TLS健全化(TLS1.2/1.3・強いスイート・HSTS)。
  2. CORSの最小許可へ見直し(認証ありはOrigin厳密指定)。
  3. CSPをReport-Onlyで導入→誤検知潰して本番適用。
  4. OWASP Top 10で自己点検(アクセス制御/インジェクション優先)。

参考リンク(公式)

Discussion