Originとは

詳細な図解

Originを読むときの前提

Origin（Web origin）は、scheme、host、portの組み合わせで決まるWebの出所です。CORS、Cookie、SameSite、CSRF、postMessageでは、この3要素の一致・不一致をブラウザが厳密に扱います。

実務では、https/httpの違い、サブドメイン、ポート違い、許可Origin、ワイルドカード、Credentials、Vary: Origin、リダイレクト後のOriginを確認します。

証跡には、フロントエンドURL、API URL、Originヘッダー、許可リスト、ACAO値、Cookie送信有無、ポート、scheme、ブラウザエラーを残します。

パスではなくscheme、host、portで見る

OriginにはURLのパスは含まれません。https://example.com/app と https://example.com/admin は同じOriginですが、httpsとhttp、サブドメイン、ポート違いは別Originです。

許可リストを作るときは、見た目のドメイン名だけでなくschemeとポートを含めて確認します。開発環境のlocalhostポート違いも別Originです。

• scheme、host、portを分けて記録する。
• サブドメインを別Originとして扱う。
• パス単位の許可と混同しない。

CORS許可の単位にする

CORSでは、ブラウザがOriginヘッダーを送り、APIがACAOで許可Originを返します。認証付き通信では、Originの明示許可とCredentialsの扱いが重要です。

ワイルドカードや動的反射を使う場合は、許可が広すぎないか、Vary: Originがあるか、CDNキャッシュで混ざらないかを確認します。

• OriginとACAOを突合する。
• Credentials有無を確認する。
• Vary: Originを確認する。

CookieやCSRFにも影響する

OriginはCookieのDomainとは別概念です。Cookieが送られる範囲と、CORSで応答を読める範囲は一致しません。SameSiteやCSRF tokenの確認でもOrigin/Refererが使われます。

同じサイトに見えても、サブドメイン分離やポート違いでブラウザ制御が変わります。認証不具合ではCookie送信、CORS許可、SameSiteを同時に見ます。

• Cookie送信範囲とOriginを分ける。
• Origin/Referer検証を確認する。
• SameSiteの文脈を確認する。

変更証跡と引き継ぎ

Origin対応では、許可Origin、対象API、認証情報有無、CDNキャッシュ、開発/本番差分、失敗時のブラウザエラーを残します。CORSや認証障害は環境差分で再現が変わりやすいです。

引き継ぎでは、フロントエンド担当、API担当、認証基盤担当、関連語としてCORS、ACAO、Cookie、Varyを残すと確認しやすくなります。

• 環境ごとのOrigin一覧を残す。
• 許可リストの所有者を記録する。
• ブラウザNetworkの証跡を保存する。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能