WEB API The Good Parts 6章の自分的まとめ

今回で本シリーズは最後となる。
以下の本の6章を自分的にまとめる。

Web API: The Good Parts

Web API: The Good Parts

もしAPI を開発している、もしくはAPI を日々触っているのであれば、 是非買って読んでみてほしい。

堅牢なWeb API を作る

今回は重要なポイントは多いが、疑問や問題点はなかったので、 各章を一言でまとめて終わろうと思う。

  • どんなセキュリティの問題があるか
    以下の3つのパターンに分けて考える。
    • サーバとクライアントの間での情報の不正入手
    • サーバの脆弱性による情報の不正入手や改ざん
    • ブラウザからのアクセスを想定しているAPI における問題

サーバとクライアントの間での情報の不正入手

  • HTTPS にする。ただし100%安全であるとは言えないが、有効な手段である。

サーバの脆弱性による情報の不正入手や改ざん

  • XSS対策
    JSON をブラウザが必ずJSON と認識するようにする

    • Content-Type: application/json を指定する
    • IE8以上対策 → X-Content-Type-Optioins: nosniff を指定する
    • IE7以下対策 → 追加のリクエストヘッダをつけてそれを検証する or JSON をエスケープする

  • XSRF対策

    • データの更新にはPOST,PUT,PATCH,DELETE を用いる
    • XSRF トークンを使う。(そのサイトが発行したワンタイムトークン、もしくはセッションごとにユニークなトークン)

  • JSON ハイジャック
    JSON ハイジャックを防止するには、現在のところ以下の対策が有効。

    • JSON をSCRIPT 要素では読み込めないようにする
      → 追加のリクエストヘッダをつけて検証する

    • JSON をブラウザが必ずJSON と認識するようにする
      XSS対策と一緒

    • JSONJavaScript として解釈不可能、あるいは実行時にデータを読み込めないようにする
      JSON の配列ではなくオブジェクトで返す。もしくはJSON ファイルの先頭に無限ループなどを仕込んで読み込み時に処理が進まないようにする。

セキュリティ関係のHTTPヘッダ

X-Content-Type-Options

X-Content-Type-Options: nosniff

上記のヘッダをつけるだけで、勝手にメディアタイプを解釈されることを防ぐ

X-XSS-Protection

ブラウザがXSS の検出、防御機能を備えている。 IE8 以上では以下のヘッダを送ることで、設定を有効化できる。 他ブラウザでは上書きできない(デフォルト有効)

X-XSS-Protection: 1; mode=block

X-Frame-Options

フレーム(FRAMEとIFRAME 要素)内で読み込まれることを防いでくれる。

X-Frame-Options: deny

Content-Security-Policy

読み込んだHTML内のIMG 要素、SCRIPT 要素、LINK 要素などの読み込み先としてどこを許可するのかを指定するためのヘッダ。
API の場合は要素を指定することがないため、直接は効果がないかも。

Contet-Security-Policy: default-src 'none'

Strict-Transport-Security

あらかじめこのサイトはHTTPS でのアクセスが必須、ということを記録させておくためのヘッダ。

Strict-Transport-Security: max-age=15678000

max-age で指定された期間中は、同じホストへのアクセスはHTTPが指定されていても、HTTPSを使うようにする。

Public-Key-Pins

SSL 証明書が偽造されたものでないかチェックする。
使い方は以下を参照。

Public Key Pinning - Web セキュリティ | MDN

Set-Cookieヘッダとセキュリティ

セッション管理にクッキーを使用する場合にセキュリティを向上させるために、 Secure、HttpOnly 属性を付与する。

Set-Cookie: session=XXXX; Path=/; Secure; HttpOnly
Secure HttpOnly
HTTPSの通信しかクッキーを送らない設定 クッキーがHTTP の通信のみで使われ、JavaScriptなどのスクリプトではアクセスできない設定

大量アクセスへの対策

そのサービス特性に基づき、ユーザ、IPごとなどの基準を設けて最大アクセス回数(レートリミット)を決める。

制限値を超えてしまった場合の対応

  • HTTPステータス 429 を返す。
  • エラーの詳細をレスポンスに含める。
  • Retry-After ヘッダを使って次のリクエストをするまでにどれくらい待てばよいかを指定する

レートリミットをユーザに伝える

以下のHTTP ヘッダを独自に作成して使う。

ヘッダ名 説明
X-RateLimit-Limit 単位時間あたりのアクセス上限
X-RateLimit-Remaining アクセスできる残り回数
X-RateLimit-Reset アクセス回数がリセットされるタイミング