[1] Web開発の現場では本番サーバーとは別に開発用Webサーバーを設けることがよくあります。
[21] 複数の関係者で利用するなどの理由で本番サーバーとは異なるドメインやサーバーなどを用意し動作させる恒久的な開発サーバーと、 開発者の手元などで一時的に動作させるサーバーがあります。
[22] 前者は恒久的とはいっても継続的な開発のため文字通り恒久的に運用する場合もあれば、 特定の短期開発目標の専用で短期間のみ運用する場合もあります。
[23] 後者はローカルサーバーなどと呼ばれることもありますが、 広く通用する共通の呼称はないと思われます。 Webアプリケーションフレームワークの類などにはローカル開発用の特殊な Webサーバー機能が含まれている場合があります。 開発中のWebアプリケーションを手軽に起動できるもので、 デバッグのための便宜機能を利用できることが多いです。
[24] Web API を外部開発者に提供している場合などに、 本番サーバーとは異なるものの本番同様に運用される開発サーバーが外部に公開される場合もあります。
[25] 例えば決済機能を提供する Webアプリケーションは、 外部の Webアプリケーションの開発者が実際の決済は行わずに決済機能の自アプリケーションへの組み込みを実装・動作確認できるよう、 外部開発者向け開発サーバーを提供していることがあります。
[20] 開発用サーバーを用いて関係者だけで事前に開発・デバッグ・確認に供する場合、 次のように設定するべきです。
[2] 適切なTLSクライアント認証やHTTP認証を設定するのが好ましいです。
[3] アクセス元IPアドレスによる制限が行われることもよくありますが、 開発者や外部協力者のネットワーク環境の違いなどで悩まされがちです。
[16] これは、第三者に開発中の状態が漏洩することを防ぐために必要な措置です。 オープンソースの Webアプリケーションなど、 特に秘匿するべきものが無い場合には、省略して構いません。
robots.txt[4]
/robots.txt にアクセスがあった時、次のようなテキストファイルを返すべきです。
robots.txtUser-agent: * Disallow: /
[15] これは、検索エンジンその他のロボットにクロールされることを防ぐため必要な措置です。 認証により検索エンジンからアクセスされないはずの場合でも、 念のため設定しておくことをおすすめします。
<meta name=robots>[6] HTML文書を返す場合、
head 要素内に次のように記述するべきです。
<meta name=robots><meta name=robots content=noindex,nofollow,noarchive>
[14] これは、検索エンジンその他のロボットにクロールされることを防ぐため必要な措置です。 認証により検索エンジンからアクセスされないはずの場合でも、 念のため設定しておくことをおすすめします。
[18]
なお、
認証など適切な措置を他に講じない場合、
<meta name=robots>
のみを指定しても当該 URL
が検索エンジンに掲載されたり、
アーカイブ系サービスに保存されたりすることを拒むことはできませんから、
注意が必要であります。
[9] リンク等から referrer が送信されないようにするべきです。
[12] これは、リンクの参照元 (referrer) として開発サーバーの URL がリンク先のサーバーに送信されてしまうことを防ぐため必要な措置です。
[13] なお、 referrer は CSRF 防止など、 当該開発サーバー自身も必要としている場合があります。 その場合は完全に無効化するのではなく、自サーバーへの送信は認めるような指定が必要となります。
[10]
SNS の共有のボタン類が Webページ中に含まれる場合、
その対象として指定する URL を https://www.example.com/ に置き換えるなどするべきです。
[11] これは、誤操作により開発サーバーから共有してしまうことや、 ボタン表示のために URL を SNS のサーバーに送信してしまうことを防ぐため必要な措置です。
[17] インターネットメールその他電子メールや IM の送信機能、 Web Hooks、 プッシュ通知、 その他これらに類する機能が備わっている場合、 関係者以外に送信されることがないように必要に応じて設定するべきです。
[19] 本番サーバーでこれらの措置を解除すること、 初の本番サーバー公開後に開発サーバーからこれらの措置が抜け落ちてしまわないことに注意。