HTTPヘッダー入門：Authorization・Accept・Originを読み解く - 金融情報システム開発なら20年以上の実績があるテンファイブ株式会社

HTTPヘッダーは、リクエストやレスポンスの本文とは別に、通信に必要な追加情報を伝えるための仕組みです。認証情報を送るAuthorization、受け取りたい形式を伝えるAccept、送信元を示すOrigin、Cookieやキャッシュ方針など、API開発では多くの判断材料がヘッダーに含まれます。ヘッダーの役割を理解すると、認証エラー、CORSエラー、JSONの形式不一致、ログイン状態が維持されない問題を切り分けやすくなります。

1. HTTPヘッダーとは何か

1-1. 本文とは別に追加情報を伝える仕組み

HTTPヘッダーは、リクエストやレスポンスの本文とは別に、通信に必要な追加情報を伝える仕組みです。本文そのものではなく、本文の扱い方や通信の条件を説明する情報だと考えると分かりやすいです。

HTTP通信では、URL、メソッド、ステータスコード、本文だけでなく、ヘッダーも重要な役割を持ちます。たとえば、認証情報、送るデータ形式、受け取りたいデータ形式、Cookie、キャッシュ方針、送信元の情報などがヘッダーでやり取りされます。APIが同じURLでも、ヘッダーの有無によって結果が変わることがあります。

たとえば、同じ/api/usersへアクセスしても、Authorizationがなければ401 Unauthorizedになり、AcceptによってJSONを返すか別形式を返すかが変わる場合があります。API通信で詰まったときは、URLや本文だけでなくヘッダーも確認しましょう。

1-2. リクエストヘッダーとレスポンスヘッダー

HTTPヘッダーには、クライアントからサーバーへ送るリクエストヘッダーと、サーバーからクライアントへ返すレスポンスヘッダーがあります。どちら側の情報なのかを分けて見ることが重要です。

リクエストヘッダーには、Authorization、Accept、Content-Type、Origin、Cookieなどが含まれます。レスポンスヘッダーには、Content-Type、Set-Cookie、Cache-Control、CORS関連のAccess-Control-Allow-Originなどが含まれます。同じContent-Typeでも、リクエストでは「送る本文」、レスポンスでは「返す本文」の形式を表します。

GET /api/me HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer xxxxx

この例では、クライアントがJSONレスポンスを希望し、Bearerトークンで認証情報を送っています。注意点は、実際のトークンをブログ、チャット、ログ、スクリーンショットに出さないことです。AuthorizationやCookieは機密情報として扱う必要があります。

1-3. DevToolsでヘッダーを見る意味

ブラウザのDevToolsでヘッダーを見る意味は、API通信で実際に何が送られ、何が返ってきたかを確認できることです。コード上で設定したつもりでも、実際の通信では違うことがあります。

DevToolsのNetworkタブでは、リクエストURL、メソッド、ステータスコード、リクエストヘッダー、レスポンスヘッダー、本文を確認できます。認証トークンが付いているか、Content-Typeが想定どおりか、Originがどう送られているか、Cookieが付いているかなどを見れば、原因を切り分けやすくなります。

たとえば、APIが401を返すならAuthorizationが付いているかを確認します。CORSエラーならOriginとレスポンス側のCORSヘッダーを確認します。JSON解析で失敗するならレスポンスのContent-Typeと実際の本文を確認しましょう。

2. 認証で見るヘッダー

2-1. Authorizationヘッダーの役割

Authorizationヘッダーは、APIへ認証情報を送るためのリクエストヘッダーです。ログイン済みユーザーか、正しい権限を持つクライアントかをサーバーが判断する材料になります。

APIでは、ログイン後に発行されたアクセストークンやAPIキーなどをAuthorizationヘッダーで送ることがあります。サーバーはこの値を検証し、正しければ処理を続け、無効または不足していれば401 Unauthorizedや403 Forbiddenを返します。つまり、Authorizationは「誰としてアクセスしているか」に関係する重要なヘッダーです。

Authorization: Bearer eyJhbGciOi...

この例は、Bearer形式でトークンを送るヘッダーです。注意点は、ここに入る値はパスワードに近い機密情報として扱うことです。実際のトークンをソースコード、GitHub、ログ、問い合わせ文面にそのまま貼らないようにしましょう。

2-2. Bearerトークンの基本

Bearerトークンは、そのトークンを持っている人にアクセス権を認める方式でよく使われる認証情報です。API認証では、Authorization: Bearer トークンという形をよく見ます。

Bearerは「持参人」という意味に近く、サーバーは送られてきたトークンを検証してユーザーや権限を判断します。トークンが有効ならAPIを実行し、期限切れや改ざん、不正な値なら拒否します。便利な一方で、盗まれたトークンを第三者が使える可能性があるため、HTTPS通信や安全な保存が前提になります。

fetch('/api/me', {
  headers: {
    'Authorization': `Bearer ${accessToken}`,
    'Accept': 'application/json'
  }
});

このコードでは、APIへBearerトークンを付けてリクエストしています。注意点は、accessTokenをブラウザのどこに保存するか、ログに出していないか、期限切れ時にどう更新するかを設計することです。ヘッダーを付けるだけで認証設計が安全になるわけではありません。

2-3. Authorizationをログに出してはいけない理由

Authorizationをログに出してはいけない理由は、トークンが漏れると本人になりすましてAPIを呼び出される危険があるからです。デバッグ時でも扱いに注意が必要です。

サーバーログ、フロントエンドのconsole、エラー監視ツール、チャットへの貼り付け、スクリーンショットには、意図せずヘッダー情報が含まれることがあります。特にAuthorizationやCookieには、認証やセッションに関わる値が入るため、ログに残ると後から第三者に見られるリスクがあります。調査に必要な場合でも、値の一部をマスクするのが基本です。

// 避けたい例
console.log(request.headers.authorization);

// よい例
console.log({
  hasAuthorization: Boolean(request.headers.authorization)
});

このコードでは、トークンそのものではなく、Authorizationヘッダーの有無だけをログに出しています。注意点は、デバッグ目的でも機密値をそのまま出さないことです。ログは開発者だけでなく、運用担当、外部サービス、長期保存の対象になる場合があります。

3. データ形式で見るヘッダー

3-1. Content-Typeは送る中身の形式

Content-Typeは、リクエストやレスポンスの本文がどの形式かを示すヘッダーです。APIへJSONを送るときは、リクエスト側でapplication/jsonを指定することがよくあります。

サーバーはContent-Typeを見て、本文をJSONとして読むのか、フォームとして読むのか、ファイルアップロードとして読むのかを判断します。本文がJSONなのにContent-Typeがない、または別形式になっていると、サーバー側で値を正しく解析できないことがあります。レスポンスでも、サーバーが返した本文の形式を示すためにContent-Typeが使われます。

Content-Type: application/json

この例は、本文がJSON形式であることを示しています。注意点は、Content-Typeを付けただけで本文が自動的にJSONになるわけではないことです。fetchでJavaScriptオブジェクトを送る場合は、通常JSON.stringifyでJSON文字列に変換します。

3-2. Acceptは受け取りたい形式

Acceptは、クライアントが受け取りたいレスポンス形式をサーバーへ伝えるリクエストヘッダーです。Content-Typeとは意味が違います。

Content-Typeは「送る本文、または返す本文の実際の形式」を示します。一方、Acceptは「できればこの形式で返してほしい」という希望を示します。たとえばAPIクライアントがAccept: application/jsonを送ると、JSONで返してほしいという意図を伝えられます。ただし、サーバーが必ずその形式で返すとは限りません。

Accept: application/json

この例では、クライアントがJSONレスポンスを希望しています。注意点は、Acceptを付けたからといって、実際のレスポンスがJSONである保証にはならないことです。実際に何が返ったかは、レスポンスのContent-Typeと本文で確認します。

3-3. JSON APIで確認するポイント

JSON APIで詰まったときは、リクエストのContent-Type、Accept、レスポンスのContent-Typeを分けて確認することが大切です。どれか1つだけ見ても原因が分からないことがあります。

JSONを送るPOSTでは、リクエスト本文がJSON文字列になっているか、Content-Type: application/jsonが付いているかを確認します。JSONを受け取りたい場合はAccept: application/jsonを確認します。さらに、実際にサーバーが返したレスポンスのContent-Typeがapplication/jsonかどうかも見ます。

fetch('/api/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Accept': 'application/json'
  },
  body: JSON.stringify({
    name: '山田太郎'
  })
});

このコードでは、JSONを送る形式と、JSONを受け取りたい希望を分けて指定しています。注意点は、エラー時にHTMLのエラーページが返る場合があることです。その状態でresponse.json()を呼ぶと、JSON解析エラーになります。

4. ブラウザ通信で見るヘッダー

4-1. Originヘッダーの役割

Originヘッダーは、リクエストがどのオリジンから送られたかを示すヘッダーです。特にCORSの判定で重要になります。

オリジンは、スキーム、ホスト、ポートの組み合わせで決まります。たとえばhttps://example.comとhttps://api.example.comはホストが違うため別オリジンです。ブラウザは別オリジンへリクエストする場面でOriginを送り、サーバーはそれを見て許可するかどうかを判断できます。

Origin: https://app.example.com

この例では、https://app.example.comからリクエストされたことを示しています。注意点は、Originは主にブラウザのセキュリティ制御に関わるヘッダーであり、Authorizationの代わりにはならないことです。Originが正しいから認証済み、とは判断できません。

4-2. Refererとの違い

OriginとRefererの違いは、Originは送信元のオリジンを示し、Refererは遷移元や参照元のURLを示す点です。似ていますが用途が違います。

Originは、スキーム、ホスト、ポートまでの情報を持ち、パスやクエリまでは含まないのが基本です。一方、Refererは、どのページから来たかを示すため、パスを含むURLになることがあります。ただし、ブラウザやReferrer-Policyの設定によって送られない、または一部だけ送られることがあります。

Origin: https://app.example.com
Referer: https://app.example.com/products/123

この例では、Originはオリジンだけを示し、Refererは具体的なページURLを示しています。注意点は、RefererにはURLパスや条件によっては情報が含まれるため、機密情報をURLに入れない設計が重要なことです。Refererが常に送られる前提で実装しないようにしましょう。

4-3. CORSやCSRF対策で見る場面

Originは、CORSやCSRF対策の切り分けで確認する場面が多いヘッダーです。ブラウザからAPIを呼ぶ実装では特に重要です。

CORSでは、ブラウザが送ったOriginに対して、サーバーがAccess-Control-Allow-Originなどのレスポンスヘッダーで許可を返します。CSRF対策でも、リクエスト元が想定したオリジンかを確認する材料としてOriginやRefererを見ることがあります。ただし、CSRF対策はOrigin確認だけでなく、SameSite CookieやCSRFトークンなどと組み合わせて考えることが多いです。

たとえば、フロントエンドがhttp://localhost:3000、APIがhttp://localhost:8080の場合、ポートが違うため別オリジンです。CORSエラーが出たら、DevToolsでリクエストのOriginとレスポンスのCORS関連ヘッダーを確認しましょう。

5. Cookieとキャッシュで見るヘッダー

5-1. Cookie / Set-Cookieの役割

CookieとSet-Cookieは、ブラウザとサーバーの間で状態を保持するために使われるヘッダーです。ログイン状態やセッション管理でよく使われます。

Set-Cookieは、サーバーがブラウザにCookieを保存させるためのレスポンスヘッダーです。Cookieは、ブラウザが保存済みのCookieをサーバーへ送るためのリクエストヘッダーです。HTTP自体は基本的に状態を持たないため、Cookieを使って「同じユーザーの続きの通信」と判断することがあります。

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax

この例では、セッションIDをCookieとして保存させ、JavaScriptから読み取れないHttpOnly、HTTPSでのみ送るSecure、クロスサイト送信を制御するSameSiteを指定しています。注意点は、セッションIDや認証用Cookieをログや画面に出さないことです。CookieもAuthorizationと同じく機密情報として扱います。

5-2. Cache-Controlの基本

Cache-Controlは、ブラウザや中間キャッシュに対して、レスポンスをどのようにキャッシュしてよいかを伝えるヘッダーです。表示が更新されない問題や、機密情報の扱いに関係します。

静的ファイルでは、キャッシュを使うことで表示速度や通信量を改善できます。一方、ログイン後の個人情報ページや決済結果のようなレスポンスでは、キャッシュさせたくない場合があります。Cache-Controlを適切に設定しないと、古いデータが表示されたり、共有端末で情報が残ったりする可能性があります。

Cache-Control: no-store

この例は、レスポンスを保存しないように指示する設定です。注意点は、すべてのレスポンスに一律でno-storeを付ければよいわけではないことです。静的アセット、公開API、認証が必要な個人データでは、キャッシュ方針を分けて考えましょう。

5-3. 機密情報を含む通信での注意点

機密情報を含む通信では、Authorization、Cookie、Set-Cookie、Cache-Controlをまとめて確認することが重要です。認証情報の送信と保存、レスポンスのキャッシュは安全性に直結します。

アクセストークンやセッションIDは、漏れると不正アクセスにつながる可能性があります。そのため、HTTPSを使う、ログに出さない、CookieにはHttpOnlyやSecureを検討する、機密レスポンスには適切なキャッシュ制御を行う、といった対策が必要です。ヘッダーは便利な設定場所ですが、値の扱いを誤るとリスクになります。

たとえば、ログイン後のユーザー情報APIでAuthorizationを使っているなら、DevToolsでヘッダーの有無を確認しつつ、スクリーンショット共有時には値を隠します。レスポンスに個人情報が含まれるなら、キャッシュ方針も合わせて確認しましょう。

6. まとめ

6-1. よく見るHTTPヘッダーの役割整理

HTTPヘッダーは、API通信の認証、データ形式、ブラウザ制御、Cookie、キャッシュを読み解くための重要な情報です。暗記リストではなく、通信の原因調査に使う視点で理解しましょう。

Authorizationは認証情報、Content-Typeは本文の形式、Acceptは受け取りたい形式、Originは送信元オリジン、Refererは参照元URL、CookieとSet-Cookieは状態管理、Cache-Controlはキャッシュ方針に関係します。それぞれ役割が違うため、混同しないことが大切です。

API通信でエラーが出たときは、ステータスコードやレスポンス本文だけでなく、リクエストヘッダーとレスポンスヘッダーを確認しましょう。DevToolsやAPIクライアントを使えば、認証エラー、CORSエラー、JSON形式の不一致を切り分けやすくなります。

6-2. API通信で詰まったときの確認チェックリスト

API通信で詰まったときは、認証、形式、送信元、Cookie、キャッシュの順にヘッダーを確認すると原因を整理しやすくなります。

Authorizationヘッダーが必要なAPIに正しく付いているか
AuthorizationやCookieの値をログに出していないか
JSON送信時にContent-Type: application/jsonが付いているか
受け取りたい形式としてAccept: application/jsonを指定しているか
レスポンスのContent-Typeが想定どおりか
CORSエラー時にOriginとCORSレスポンスヘッダーを確認しているか
Cookieが送信されているか、Set-Cookieが返っているか
個人情報を含むレスポンスのCache-Controlが適切か

このチェックリストを使うと、APIが動かない原因を「なんとなく」ではなく、ヘッダーごとに切り分けられます。HTTPヘッダーを読めるようになると、フロントエンド、バックエンド、インフラの境界で起きる問題にも気づきやすくなります。

7. 参考リンク

MDN: HTTP headers
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers
MDN: Authorization
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization
MDN: Accept
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept
MDN: Origin
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Origin
MDN: Set-Cookie
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie