HTTP 401 vs 403

401 には認証チャレンジが必須

HTTP 401 は、リクエストに対象リソースに対して有効な認証情報が欠けていることを示します。 HTTP 認証とステータスのセマンティクス では、401 レスポンスを生成するサーバーは、適切なチャレンジを含む WWW-Authenticate ヘッダーを付加しなければならないと定められています。歴史的な理由句 Unauthorized は、その認証上の意味を変えるものではありません。

認証情報の欠如、有効期限切れ、無効な認証スキームなどが、サービスによっては 401 につながります。値を変える前に、文書化されたスキームを診断してください。正しい API キーであっても、誤ったヘッダーに送信されれば、キー自体は正しくても使用不能になります。

自分が運用するサービスであれば、レスポンスに実際にチャレンジと有用かつ安全なエラー記述が含まれているか確認してください。期待されるヘッダーのない素のステータスだけの場合、非準拠なアプリケーションレスポンスか、メッセージを改変した中間者が存在する可能性があります。その区別をインシデント記録の中で明確に保ってください。

403 はログインを証明せずに拒否を表す

HTTP 403 は、サーバーがリクエストを理解しており、その実行を拒否していることを意味します。権限の失敗はよくあるケースですが、このステータスは認証が成功したことを保証しません。匿名リクエストが、ユーザーのアイデンティティが確立される前にポリシーによって禁止されることもあります。

例としては、呼び出し元が特定のプロジェクトへのアクセス権を持たない場合、アプリケーションルールによってリクエストが許可されない場合、またはゲートウェイがリクエストを拒否する場合などがあります。ステータスコードだけではそれらを区別できません。対処策を選ぶ前に、レスポンスボディ、関連ヘッダー、および拒否を生成したシステムを特定してください。

別の認証情報を自動的に付与すべきだと決めつけないでください。拒否の中には認証情報とは無関係のものもあり、不要な認証情報の転送はシークレットを誤った宛先にさらすことになりかねません。自分がサービスを所有している場合、内部ログを使って評価されたルールを特定しつつ、外部向けのエラーレスポンスは呼び出し元が受け取ることを許されている情報に限定してください。

ベアラートークンエラーはより具体的な意味を付加する

ベアラートークン API は、ステータスコードだけよりも具体的なエラーを提供できます。 ベアラートークンのエラー定義 では invalid_token と insufficient_scope を区別し、それぞれを異なるレスポンス動作に関連付けています。これらのフィールドにより、使用不能なトークンと必要なスコープを欠くトークンを切り分けることができます。

この語彙は API がベアラートークンスキームを用いる場合に適用されます。別のヘッダーで生の API キーを期待するサービスに対して当然のものとして仮定すべきではありません。HTTP チャレンジか JSON アプリケーションのエンベロープかといった点も含め、文書化された認証インターフェースにエラーの解釈を合わせてください。

仮想的なプロジェクトエクスポートでは、トークンはアプリケーションを正しく識別していても、エクスポートへのアクセス権を欠いているかもしれません。この場合、適切な調査対象は付与されたスコープとリソースポリシーです。同じ権限を持つ別のトークンに差し替えても、アクセス判断は変わりません。期待されるアクションとスコープを診断情報とともに記録してください。

各API境界をまたいでレスポンスを追跡する

多層のデータワークフローでは、クライアントからプロバイダーへのリクエストと、プロバイダーからターゲットへのリクエストが存在し得ます。プロバイダーのHTTPレスポンスと、ターゲット側で記録されたステータスは、異なる情報である場合があります。一方はプロバイダーがジョブを受け付けたかどうかを示し、もう一方は宛先で何が起きたかを示すことがあります。

ボディ内の数値をトランスポートステータスとして解釈する前に、プロバイダーが文書化しているレスポンスエンベロープを確認してください。外側のステータス、エラーコード、メッセージ、ターゲットの詳細といったフィールドが利用可能な場合は、それらを取得しましょう。記録を共有する前に、認証情報や個人情報はマスキングしてください。

また、自分で管理しているシステム内のゲートウェイやリバースプロキシも特定してください。ゲートウェイは、アプリケーションが受信する前にリクエストを拒否することがあります。この場合、アプリケーションのログには対応するリクエストが残らず、それはクライアントが何も送らなかったという証拠ではなく、境界での事象を示す証拠になります。対応するコンポーネント全体で相関識別子を使い、原因の特定範囲を絞り込みましょう。

サービスオーナー向け：リソースに対する判断をテストする

サービスオーナーは、要求されたリソースとアクションに対してアクセスチェックが適用されているかをテストする必要があります。 OWASP の認可に関する推奨事項 は、最小権限と、すべてのリクエストに対する検証を重視しています。有効なアイデンティティがあっても、オブジェクトレベルのアクセス評価が不要になるわけではありません。

1つのプロジェクトにアクセスできるユーザーを使い、別のプロジェクトの識別子に対してテストしてください。読み取りと編集は別々にテストしましょう。インタラクティブなエンドポイントだけでなく、バックグラウンドのエクスポートルートもテストします。あるルートで成功したリクエストが、同じデータを公開する別のルートを通じて、意図せずより広い権限を得てしまわないようにします。

レスポンスの詳細は意図的に選択してください。システムによっては、アクセス権のない呼び出し元に対してリソースの存在を明かさないために、not-found レスポンスを使用することがあります。その挙動をクライアント向けに文書化し、内部的な理由は権限を持つオペレーターが確認できる状態に保ってください。診断を便利にするためであっても、リソース名やポリシーの詳細を権限のない呼び出し元に公開しないでください。

Scrapeless とターゲットのレスポンスを分けて診断する

次の宛先へのリクエスト Scrapeless Web Unlocker には、いかなるターゲット結果を解釈する前に、独自の認証境界があります。現在の Scrapeless API キーの手順 では、該当するAPIサーフェスに対する認証情報の方法が指定されています。その境界について、文書化された挙動とマスク済みの診断情報を用いて、まず確認してください。

プラットフォームがリクエストを受け付けたら、結果として得られたターゲット情報は別に検証してください。マネージドな取得は、プライベートな宛先リソースへの認可を与えるものではありません。アクセス拒否は、意図された収集境界の外側のデータに到達する許可ではなく、スコープや要件を確認すべきシグナルとして扱うべきです。

この 403 レスポンス診断ワークフロー は、拒否箇所を特定するための関連コンテキストを提供します。エラー分類において、課金、製品の提供状況、リクエスト検証、ターゲット側の認可を区別しつつ、最新の Scrapeless 料金 をプロダクト計画に利用してください。

具体的なアクションにつながる診断記録を構築する

有用な診断記録には、リクエストの宛先、メソッド、マスク済みの認証スキーム、外側のステータス、存在する場合のチャレンジヘッダー、および関連するエラーフィールドが含まれます。安全に共有できる識別子を使って、調査対象のリソースとアクションを追加します。サービスが相関IDを提供している場合は、それも保持してください。

401 の場合は、想定されるスキーム、シークレットの読み込み、有効性、および該当する場合はオーディエンスや宛先を確認します。403 の場合は、レスポンスを生成したコンポーネントを特定し、リソースポリシーや文書化された制限を確認してください。サービスが標準的な慣習に従っていない場合は、そのレスポンスを教科書どおりの説明に当てはめようとするのではなく、観測された挙動と独自のドキュメントを記録してください。

証拠から意図的な拒否が特定できた時点で作業を止めます。正しい結果は、スコープを絞った権限リクエスト、設定の修正、あるいはスコープ外タスクの削除である場合があります。成功した診断とは、必ずしもリクエスト成功ではなく、説明可能なアクセス判断です。その違いを運用レポートの中で明確に保ってください。

結論

HTTP 401 と 403 の違いは、そのレスポンスを生成したコンポーネントまでたどることで、実務的な意味を持ちます。401 のチャレンジは認証を調査するために利用し、403 は原因にさらなるコンテキストが必要な拒否の証拠として扱ってください。プロバイダーとターゲットの結果を分けて扱い、認証情報をマスキングし、次のアクションをその特定のアクセス判断に合致させましょう。

参考文献

• Web Unlocker 取得モデル
• Scrapeless Web Unlocker
• 禁止されたレスポンスの診断