要約

  • draft-ietf-httpapi-privacy-06 が扱うのは 3xx の後ではなく前である。認証付き API クライアントは、サーバーから何らかの指示を受ける前に秘密を HTTP へ書き出し得る。
  • HSTS、DNS の HTTPS レコード、平文ポートの閉鎖、資格情報側の制約、HTTPS 専用のクライアント既定値は、時間軸上の別々の防壁である。最終 URL はそれらの実行証明ではない。
  • 平文で資格情報を受け取ったサーバーは、妥当性を漏らさず拒否し、露出の種類を判定し、必要なら失効させる。草案は IESG 承認後 RFC Editor Queue に入ったが、2026 年 10 月 1 日時点では RFC ではない。

優れたエラー処理が、悪い設定を長生きさせることがある。

ベース URL が http:// になっていても、ライブラリは認証ヘッダーを付け、リクエストを送り、リダイレクトを追い、HTTPS で再送する。利用者は期待したデータを受け取る。障害が起きないため、最初の送信だけが平文だった事実は監視画面から消える。

第 06 版の重要点は、通信順序を入れ替えないことにある。リダイレクトはリクエストへの応答である。応答が返る時点で、最初のリクエストはすでにネットワーク上へ出た。二本目の接続の暗号化は、一本目の秘密性を証明しない。

正常終了が事故を見えなくする

人が使うウェブでは、HTTP から HTTPS への案内に実用性がある。認証済み API では事情が違う。プログラムは完全な URI を設定として持ち、さらに再利用可能な権限も持つ。誤記を親切に吸収すると、修正されるべき設定が運用標準になる。

草案の起点となった2024 年 5 月の調査記事は、まさに s の欠落から始まり、当時の複数サービスを試した。個別事業者の結果は現在の採用率ではなく、その後変更した例もある。残る価値は、成功した呼び出しが秘密の露出と両立するという再現可能な構造にある。

意図した URI、DNS 発見、HSTS 状態、最初に開いた接続、最初のリクエスト、応答、HTTPS 再試行、失効、認可、業務コミットを一つの状態に畳んではならない。とくに最終 URL と 200 は、最初のパケットについて何も保証しない。

防御の締切は最初の送信前

RFC 6797の HSTS は、ホストが安全な接続を通じて将来の安全接続を要求する仕組みである。初回接触の境界があり、クライアントが状態を永続化して初めて効く。ブラウザー向けヘッダーを返すことと、API SDK が HSTS を保存することは別の事実だ。

RFC 9460の HTTPS リソースレコードは、接続前へ情報を移す。しかし、クライアントが問い合わせて解釈する必要があり、新規クライアントの経路や DNS を支配する相手は応答を隠し得る。草案が HSTS と HTTPS レコードを併用させるのは、どちらも単独では完全でないからである。

真正サーバーが 80 番ポートを閉じれば、そのサーバーへの平文配送は防げる。だが能動的な攻撃者は、存在しない HTTP サーバーになりすまして接続を受けられる。したがって最後の防線はクライアントであり、安全な接続を選ぶ前に秘密を付けてはならない。

資格情報自身にも規則を持たせられる。RFC 6265の Secure 属性は Cookie の平文送信を禁止する。RFC 8959の secret-token URI は安全利用の期待を運べる。しかし独自の API キーヘッダーには、名前だけで同じ強制力は生まれない。

403 の役割は復元ではなく境界表示

共有ホストなどで HTTP を完全に止められない場合、06 版は資格情報を含む平文リクエストへ一律 403 を返すよう求める。有効な値と無効な値で応答を変えると、攻撃者が資格情報の存在を照合できる。RFC 9110の 403 は、資格情報の十分性と別の理由による拒否も表現できる。

ただし 403 は事件票であって消しゴムではない。直接送られた API key や bearer token はコピー可能な権限として扱うべきである。一方、署名や MAC は秘密そのものではなく派生値だけを見せる場合がある。再送可能性、nonce、対象リクエストとの結合を調べず、同じ失効処理へ流してはいけない。

即時失効にも悪用余地がある。攻撃者が候補値を HTTP へ大量投入し、偶然一致した正規キーを止めようとするからだ。接続・レート制限、通知、隔離、猶予の設計が必要になる。それでも、平文に出た bearer token を安全と呼び直す理由にはならない。

標準化の進捗と実装証拠を分ける

Datatrackerは HTTPAPI ワーキンググループの Best Current Practice 案として記録する。履歴では 2026 年 6 月 5 日に IESG 承認、RFC Editor Queue への移行が確認できる。10 月 1 日現在、公開物は 5 月 11 日付の第 06 版で、RFC 番号はない。

これは十分なレビューの証拠だが、製品挙動の証拠ではない。shepherd 記録にも特定の実装報告はない。作業リポジトリは文書の変更を追えるが、ある SDK がコールドスタート時に何を送るかは実際の試験でしか分からない。

RFC 7258が広範な監視を攻撃と位置付けることも忘れてはならない。資格情報がなくても、パスや識別子、操作意図は露出する。再利用可能なトークンは、その観測に実行権限まで加える。

証拠台帳は最初のバイトから作る

ベース URI、ライブラリと版、リダイレクト方針、資格情報を付ける時点、明示的な非安全モード、DNS と HTTPS RR、HSTS の出所・年齢・永続化、最初の scheme/peer/port、秘密値を除いた資格情報分類、最初の status と Location、次の TLS peer、露出判定、隔離・ローテーション・失効、認可、コミット ID、外部結果を保存する。

未評価を成功へ変換しない。hsts=none、https_rr=unavailable、exposure=possible、revocation=pending は必要な状態である。最後の HTTPS span は最初の HTTP span を上書きしてはならない。

Lu Heng の最小初期仕様から導ける共通規則は薄い。再利用可能な秘密を非安全な輸送へ出さないことだ。Running-Code Primacyは最終表示ではなく実際の最初のバイトを問う。Policy Mirrorは SDK の既定値が実権を持つことを示す。Reality Layersは設定、発見、露出、応答、認可、効果を分離する。

情報源