MENU

ApacheでBasic認証時にCORSエラーが発生する原因と解決法を徹底解説

Apache

ApacheでBasic認証を導入する際、CORS (Cross-Origin Resource Sharing) エラーに直面することがあります。特に、外部からのAPIリクエストやフロントエンドとバックエンドが異なるドメインで動作している環境では、Basic認証の導入後に「No ‘Access-Control-Allow-Origin’ header is present」というエラーが表示されることが少なくありません。

この問題を放置すると、ユーザーは正しくリソースにアクセスできず、サービスの利用に支障をきたします。本記事では、CORSの基本概念から、ApacheでのBasic認証設定時に発生するCORSエラーの原因、そして具体的な解決方法について詳しく解説します。

最終的には、ApacheでBasic認証を適用しつつ、CORSエラーを防ぐための実践的な設定方法を学ぶことができます。Webサーバー管理者やWebエンジニアの方にとって、役立つ知識となるでしょう。

日程Fit。無料・登録不要。「いつ空いてる？」を、ひとつのリンクで。リンクを送って、○△×でかんたん日程調整。無料で日程を作る。
目次

CORSエラーとは何か


CORS（Cross-Origin Resource Sharing）とは、Webブラウザが異なるオリジン（プロトコル、ドメイン、またはポートが異なるリソース）間でリクエストをやり取りする際のセキュリティ機構です。標準では、異なるオリジンへのリクエストはセキュリティ上の理由からブロックされますが、CORSヘッダーを適切に設定することで例外的に許可することができます。

なぜCORSが必要なのか


セキュリティの観点から、ブラウザはクロスオリジンリクエストを制限しています。これにより、悪意のあるサイトがユーザーのセッションを利用して、不正なリクエストを送信する「クロスサイトリクエストフォージェリ（CSRF）」などの攻撃を防止します。しかし、APIを提供するサイトでは、外部サイトや別のフロントエンドからのリクエストを許可する必要があります。そのためにCORS設定が求められます。

CORSエラーが発生する仕組み


CORSエラーは、次のような状況で発生します：

  • クライアントが他のオリジンにリクエストを送信する。
  • サーバーが適切なCORSヘッダー（例：Access-Control-Allow-Origin）をレスポンスに含めていない。
  • ブラウザがCORSポリシー違反としてリクエストをブロックする。

具体的には、以下のようなエラーメッセージがブラウザのコンソールに表示されます：

Access to fetch at 'https://api.example.com/data' from origin 'https://frontend.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

このエラーは、ApacheでBasic認証を設定する際に頻発するため、次の章でその詳細を掘り下げます。

ApacheでBasic認証を設定する方法


ApacheでBasic認証を設定することで、特定のリソースへのアクセスを制限できます。ユーザー名とパスワードを求めるシンプルな仕組みですが、CORSエラーの原因となることがあります。ここでは、基本的なBasic認証の設定方法を説明します。

Basic認証の流れ

  1. クライアントがリソースにアクセスする。
  2. Apacheが「401 Unauthorized」を返し、認証情報の入力を要求する。
  3. クライアントがユーザー名とパスワードを送信。
  4. 認証成功後、Apacheはリソースを提供する。

Basic認証の設定手順


以下の手順でApacheにBasic認証を設定します。

1. 認証ファイルの作成


認証に必要なユーザー名とパスワードを保存するファイルを作成します。

sudo htpasswd -c /etc/apache2/.htpasswd username

username の部分は任意のユーザー名です。コマンド実行後、パスワードの入力を求められます。

2. Apache設定ファイルの編集


対象のディレクトリに対して認証を有効にします。Apacheの設定ファイル（例：/etc/apache2/sites-available/000-default.conf）を編集します。

<Directory "/var/www/html/protected">
    AuthType Basic
    AuthName "Restricted Access"
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user
</Directory>

この設定により、/var/www/html/protectedディレクトリへのアクセスには認証が必要になります。

3. Apacheの再起動


設定を反映させるため、Apacheを再起動します。

sudo systemctl restart apache2

動作確認


ブラウザから該当ディレクトリにアクセスし、認証ダイアログが表示されることを確認します。正しいユーザー名とパスワードを入力すれば、リソースにアクセスできます。

このように簡単にBasic認証を設定できますが、ここでCORSエラーが発生する可能性があります。次の項で、なぜCORSエラーが起こるのかを解説します。

Basic認証時にCORSエラーが起こる原因


ApacheでBasic認証を設定した際にCORSエラーが発生する主な原因は、CORSリクエストと認証の仕組みが干渉するためです。ここでは、技術的な背景と具体的なエラー発生の流れを解説します。

プリフライトリクエストとBasic認証の衝突


CORSリクエストの多くは「プリフライトリクエスト」という事前確認リクエストを行います。これは、実際のリクエストを送る前に、ブラウザがサーバーに対して「このリクエストは許可されますか？」と確認するリクエストです。

プリフライトリクエストはOPTIONSメソッドで送信されますが、ApacheがこのリクエストにもBasic認証を求めるため、リクエストは401 Unauthorizedでブロックされます。結果として、CORSエラーが発生します。

エラー発生の流れ

  1. クライアントがクロスオリジンでGETやPOSTリクエストを送信。
  2. ブラウザがプリフライトとしてOPTIONSリクエストを自動送信。
  3. ApacheがOPTIONSリクエストに対してBasic認証を要求し、401 Unauthorizedを返す。
  4. ブラウザはリソースへのアクセスを拒否し、CORSエラーが発生。

具体的なエラーメッセージ例


以下のようなエラーメッセージがブラウザのコンソールに表示されます：

Access to XMLHttpRequest at 'https://api.example.com/data' from origin 'https://frontend.example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

原因の要点

  • プリフライトリクエストがOPTIONSメソッドで送信される
  • ApacheがOPTIONSリクエストにも認証を要求する
  • CORSヘッダーが認証前に返されない

次の章では、これらの問題を回避し、CORSエラーを解消するための具体的なApacheの設定方法について説明します。

ApacheでCORSエラーを解消する設定例


Basic認証を適用しつつCORSエラーを防ぐためには、プリフライトリクエスト（OPTIONSメソッド）に対して認証を不要とし、適切なCORSヘッダーを付与する必要があります。ここでは、具体的なApacheの設定例を紹介します。

設定の概要

  • プリフライトリクエスト（OPTIONS）は認証不要とする。
  • 実際のリクエスト（GET, POSTなど）は認証を求める。
  • CORSヘッダーを適切に設定することで、クロスオリジンリクエストを許可する。

Apacheの設定ファイル例


Apacheのサイト設定ファイル（例：/etc/apache2/sites-available/000-default.conf）に以下を追加します。

<Directory "/var/www/html/protected">
    AuthType Basic
    AuthName "Restricted Access"
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user

    # CORS設定
    Header always set Access-Control-Allow-Origin "*"
    Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS"
    Header always set Access-Control-Allow-Headers "Authorization, Content-Type"

    # プリフライトリクエストには認証を求めない
    <If "%{REQUEST_METHOD} == 'OPTIONS'">
        Require all granted
        Satisfy any
    </If>
</Directory>

設定内容の解説

  1. AuthType Basic と Require valid-user
  • 通常のリクエストにはBasic認証を適用します。
  1. Header always set Access-Control-Allow-Origin "*"
  • すべてのオリジンからのリクエストを許可します。必要に応じて特定のオリジンを指定してください（例：https://example.com）。
  1. Access-Control-Allow-Methods
  • 許可するHTTPメソッドを指定します。GET, POST, OPTIONSなどが一般的です。
  1. Access-Control-Allow-Headers
  • クライアント側から送信されるAuthorizationヘッダーを許可します。これがないと、認証情報がブラウザから送信されません。
  1. <If "%{REQUEST_METHOD} == 'OPTIONS'"> セクション
  • プリフライトリクエスト（OPTIONS）を無条件で許可し、認証を回避します。
  • Require all granted は、すべてのリクエストを許可する設定です。

設定の反映


設定を反映するためにApacheを再起動します。

sudo systemctl restart apache2

動作確認

  • ブラウザで該当リソースにアクセスし、CORSエラーが解消されていることを確認します。
  • OPTIONSリクエストが200 OKで返されるか、ブラウザの開発者ツールで確認できます。

この設定により、プリフライトリクエストが正しく処理され、Basic認証を使用した環境でもCORSエラーが発生しないようになります。次はAccess-Control-Allow-Headersなど、CORSに関連する具体的なヘッダー設定について詳しく解説します。

Access-Control-Allow-Headersの設定方法


CORSリクエストが適切に処理されるためには、Access-Control-Allow-Headersヘッダーの設定が不可欠です。特にBasic認証を行う場合、Authorizationヘッダーを許可しなければ、クライアントは認証情報を送信できません。この章では、Access-Control-Allow-Headersの設定方法とその役割について解説します。

Access-Control-Allow-Headersの役割


Access-Control-Allow-Headersヘッダーは、クライアントがサーバーに送信できるカスタムヘッダーや標準ヘッダーを指定します。Basic認証で必要なAuthorizationヘッダーが許可されていない場合、プリフライトリクエストでエラーが発生し、実際のリクエストが拒否されます。

設定の方法


Apacheの設定ファイルで、対象のディレクトリやロケーションに対してAccess-Control-Allow-Headersを設定します。

設定例（サイト設定ファイルへの追加）

<Directory "/var/www/html/protected">
    AuthType Basic
    AuthName "Restricted Access"
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user

    # CORS設定
    Header always set Access-Control-Allow-Origin "*"
    Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS"
    Header always set Access-Control-Allow-Headers "Authorization, Content-Type, X-Requested-With"

    # プリフライトリクエストには認証を求めない
    <If "%{REQUEST_METHOD} == 'OPTIONS'">
        Require all granted
        Satisfy any
    </If>
</Directory>

設定内容の解説

  • Authorization：Basic認証を行う際に必要なヘッダー。これがないと認証情報が送信されません。
  • Content-Type：JSONデータやフォームデータを送信する際に必要です。
  • X-Requested-With：Ajaxリクエストでよく使用されるカスタムヘッダーで、クロスオリジンのリクエストで必要になることがあります。

必要に応じてヘッダーを追加


外部APIを利用する場合や独自のヘッダーが必要な場合は、Access-Control-Allow-Headersにそのヘッダーを追加してください。
例：

Header always set Access-Control-Allow-Headers "Authorization, Content-Type, X-Requested-With, Custom-Header"

設定の反映と確認


設定を反映するためにApacheを再起動します。

sudo systemctl restart apache2

ブラウザの開発者ツールで、プリフライトリクエストのレスポンスヘッダーを確認し、Access-Control-Allow-Headersが正しく設定されているかチェックしましょう。これにより、Basic認証を含むクロスオリジンリクエストが正常に処理されるようになります。

実際の運用での注意点とベストプラクティス


ApacheでBasic認証とCORSを併用する際は、セキュリティやパフォーマンスに注意が必要です。CORS設定のミスや過度な緩和は、セキュリティリスクを引き起こす可能性があります。この章では、安全かつ効率的に運用するためのベストプラクティスを解説します。

1. `Access-Control-Allow-Origin`の制限


CORS設定でAccess-Control-Allow-Origin "*"とするのは簡単ですが、セキュリティリスクが高まります。すべてのオリジンからのリクエストを許可することになるため、不正なサイトからのアクセスが可能になります。

対策：特定のオリジンのみを許可

Header always set Access-Control-Allow-Origin "https://trusted-frontend.com"


これにより、特定の信頼できるオリジンのみリクエストを許可できます。複数のオリジンを許可する場合は、動的にオリジンを判別する方法を使います。

2. 認証が必要なエンドポイントの分離


すべてのエンドポイントでBasic認証を求めるのではなく、必要なエンドポイントだけに限定するのが望ましいです。例えば、管理用APIには認証を必須にし、公開APIでは認証を不要とします。

<Location "/api/admin">
    AuthType Basic
    Require valid-user
</Location>

<Location "/api/public">
    Require all granted
</Location>

3. プリフライトリクエストのキャッシュ


プリフライトリクエストはサーバーの負荷を増加させます。頻繁にOPTIONSリクエストが送られる場合は、Access-Control-Max-Ageを設定してキャッシュを有効にしましょう。

Header always set Access-Control-Max-Age "3600"


これにより、ブラウザはプリフライトリクエストを1時間（3600秒）キャッシュし、頻繁なリクエストを防ぎます。

4. HTTPSの使用


Basic認証では、Authorizationヘッダーにユーザー名とパスワードが平文で送信されます。HTTPで通信すると、この情報が盗聴される可能性があります。必ずHTTPSを使用してください。

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
</VirtualHost>

5. 詳細なログの有効化


クロスオリジンの問題や認証エラーを特定するために、Apacheのログを有効化し、詳細に記録します。

LogLevel info
CustomLog /var/log/apache2/cors_access.log combined


ログを分析することで、CORSエラーの原因を素早く特定できます。

6. 設定変更後のテスト


CORSやBasic認証の設定を変更した場合は、ブラウザの開発者ツールやcurlを使って必ず動作確認を行います。

curl -I -X OPTIONS https://api.example.com/data -H "Origin: https://frontend.example.com"


適切なCORSヘッダーが返されることを確認してください。

これらのベストプラクティスを実施することで、セキュリティとパフォーマンスのバランスを取りながら、ApacheでのBasic認証とCORSエラーの解消を実現できます。

まとめ


本記事では、ApacheでBasic認証を設定した際に発生するCORSエラーの原因と解決方法について詳しく解説しました。

CORSエラーはプリフライトリクエストとBasic認証の干渉によって発生することが多く、OPTIONSリクエストに対して認証を求めない設定が必要です。加えて、Access-Control-Allow-HeadersなどのCORSヘッダーを適切に設定することで、クロスオリジン環境でも安全かつスムーズにリソースへのアクセスが可能になります。

運用においては、特定のオリジンのみを許可する、プリフライトリクエストをキャッシュする、HTTPSを導入するなどのベストプラクティスを取り入れることが重要です。これにより、セキュリティを保ちながらユーザー体験の向上を図ることができます。

今回の設定を通じて、ApacheでのBasic認証とCORSエラーの問題を効果的に解消し、安心してWebサービスを運用できる環境を構築できるでしょう。

Apache
Apache Webサーバー Basic認証 CORSエラー

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次