プリフライトリクエスト(プリフライトリクエスト)とは | 意味や読み方など丁寧でわかりやすい用語解説
プリフライトリクエスト(プリフライトリクエスト)の意味や読み方など、初心者にもわかりやすいように丁寧に解説しています。
読み方
日本語表記
プリフライトリクエスト (プリフライトリクエスト)
英語表記
preflight request (プリフライトリクエスト)
用語解説
プリフライトリクエストは、Webブラウザがウェブサーバーに対して特定の種類のHTTPリクエストを送信する際に、そのリクエストがサーバーに受け入れられるかどうかを事前に確認するために自動的に送信する特別なHTTPリクエストのことである。これは、ウェブセキュリティの重要な要素であるCORS(Cross-Origin Resource Sharing、クロスオリジンリソース共有)メカニズムの一部として機能する。主に異なるオリジン、つまりドメイン、プロトコル、またはポートが異なるウェブアプリケーション間でリソースを安全に共有するために導入された仕組みである。
ウェブブラウザには「同一オリジンポリシー」という基本的なセキュリティ規則があり、これはあるオリジンで読み込まれたドキュメントやスクリプトが、別のオリジンのリソースとやり取りするのを制限するものである。これは悪意のあるウェブサイトがユーザーの認証情報やデータを盗むのを防ぐための重要な仕組みだが、正当な理由で異なるオリジン間でリソースを共有したい場合(例えば、APIサービスを提供するサーバーと、それを呼び出すフロントエンドアプリケーションが別々のドメインにある場合など)には不便である。この問題を解決するためにCORSが導入された。CORSは、サーバー側で明示的に許可されたクロスオリジンリクエストのみをブラウザが許可する仕組みであり、プリフライトリクエストはその安全性と堅牢性を保証するための重要なステップとなる。
プリフライトリクエストは、すべてのクロスオリジンリクエストで発生するわけではない。ブラウザが「シンプルリクエスト」と判断する一部のリクエスト(例:GETメソッドや一部のPOSTメソッド、特定のHTTPヘッダのみを使用するリクエストなど)は、プリフライトリクエストなしで直接サーバーに送信される。しかし、以下のような条件に該当する「複雑なリクエスト」の場合、ブラウザは必ずプリフライトリクエストを送信する。
一つ目は、GET、HEAD、POST以外のHTTPメソッドを使用するリクエストである。例えば、PUTやDELETEといったメソッドは、サーバー上のリソースを更新したり削除したりする可能性があるため、事前に安全性を確認する必要がある。
二つ目は、Accept、Accept-Language、Content-Language、Content-Type(application/x-www-form-urlencoded、multipart/form-data、text/plain以外の値の場合)以外のカスタムHTTPヘッダを含むリクエストである。カスタムヘッダは、アプリケーション固有の情報を含むことが多く、予期せぬ動作を防ぐために確認が必要とされる。
三つ目は、Content-Typeヘッダがapplication/x-www-form-urlencoded、multipart/form-data、text/plain以外の値である場合である。例えば、application/jsonといった形式でデータを送信するリクエストは、プリフライトリクエストの対象となる。
プリフライトリクエストが送信される際、ブラウザは実際のリクエストの前に、HTTPのOPTIONSメソッドを使ってサーバーにリクエストを送信する。このOPTIONSリクエストには、実際のリクエストで使用する予定のHTTPメソッドやカスタムヘッダに関する情報が含まれる。具体的には、Access-Control-Request-Methodヘッダには実際のリクエストで使用するHTTPメソッドが、Access-Control-Request-Headersヘッダには実際のリクエストで使用するカスタムヘッダのリストが含まれる。
サーバーはこのプリフライトリクエストを受け取ると、自身のCORSポリシーに基づいて、そのリクエストが許可されるべきかどうかを判断する。もし許可される場合、サーバーはレスポンスにAccess-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-HeadersといったCORS関連のヘッダを含めて応答する。これらのヘッダは、どのオリジンからのリクエストを許可するか、どのHTTPメソッドを許可するか、どのHTTPヘッダを許可するかをブラウザに伝える役割を果たす。サーバーが許可を明示した場合にのみ、ブラウザは続けて実際のリクエストを送信する。もしサーバーがプリフライトリクエストを拒否したり、必要なCORSヘッダを返さなかったりした場合、ブラウザは実際のリクエストを送信することなく、CORSエラーを発生させる。
このプリフライトリクエストの主な目的は、ウェブアプリケーションのセキュリティを強化することにある。悪意のあるウェブサイトがユーザーの知らないうちに、重要なウェブサービスに対してデータを変更したり削除したりするリクエストを送信するのを防ぐことができる。ブラウザが事前にサーバーの許可を確認することで、サーバーは意図しないクロスオリジンリクエストから保護され、またクライアントも無駄なリクエスト送信を避けることができる。
しかし、プリフライトリクエストには考慮すべき点もある。まず、実際のリクエストの前に必ずもう一つのリクエスト(OPTIONSリクエスト)が追加で発生するため、ネットワーク通信の回数が増え、わずかながらレイテンシ(遅延)が増加する可能性がある。特に多数のクロスオリジンリクエストが発生するアプリケーションでは、このオーバーヘッドが無視できない場合もある。このオーバーヘッドを軽減するために、サーバーはプリフライトリクエストのレスポンスにAccess-Control-Max-Ageヘッダを含めることができる。このヘッダは、プリフライトリクエストの結果をブラウザがどれくらいの期間キャッシュしてよいかを指定する。指定された期間内であれば、ブラウザは同じクロスオリジンリクエストに対して再度プリフライトリクエストを送信せず、キャッシュされた許可情報を使って直接実際のリクエストを送信することができる。これにより、頻繁に発生するリクエストに対するパフォーマンスへの影響を最小限に抑えることが可能となる。
システムエンジニアを目指す初心者にとっては、CORSエラーとして目にすることが多い現象の一つである。ウェブアプリケーション開発において、フロントエンドとバックエンドが異なるオリジンに配置されることは非常に一般的であるため、プリフライトリクエストの仕組みと、サーバー側で適切なCORSヘッダを設定することの重要性を理解することは不可欠である。開発中にCORSエラーが発生した場合、ブラウザの開発者ツールでネットワークタブを確認し、OPTIONSリクエストが正しくサーバーに到達し、期待されるCORS関連のヘッダ(Access-Control-Allow-Originなど)がレスポンスに含まれているかをチェックすることが、問題解決の第一歩となる。正しく設定されていない場合、サーバーはブラウザからのプリフライトリクエストに対して許可応答を返せず、結果として実際のリクエストがブロックされることになる。プリフライトリクエストは、今日のウェブの安全性と相互運用性を支える重要な基盤技術の一つであると言える。