LoginSignup
1064
601

More than 3 years have passed since last update.

思わぬ事故防止!開発時やテスト時に使用するメアドのドメインは example.com に統一しよう

Last updated at Posted at 2020-07-29

はじめに

Webアプリケーションの開発時やテスト時にはテスト用のユーザーを作成するために適当なメールアドレスとパスワードを登録することが多いと思います。

このとき、みなさんはこんなふうにデタラメなドメインをメアドに使ってないでしょうか?

hoge@hoge.com
test@testmail.com
aaaa@bbb.com
etc...

「こんなデタラメなドメイン、あるわけないやろ!」と思うかもしれませんが、自分はデタラメに付けたつもりでも意外とかなりの高確率でそのドメインは実在します。

実際、上の例で挙げたドメインをブラウザに入力すると、いずれも何かしらページが表示されます。
つまり、そのドメインは現在誰かが使っているということがわかります。

https://hoge.com/
Screen Shot 2020-07-29 at 15.15.59.png

http://testmail.com/
Screen Shot 2020-07-29 at 15.16.59.png

https://www.bbb.org (bbb.com から転送される)
Screen Shot 2020-07-29 at 15.16.39.png

実在するドメインだと何が困るの?

何らかの間違いでその実在するドメインに向けてメールが送信される可能性があります。
特に、ステージング環境などではSMTPの設定がバッチリ整っていて、実際にメールが送信されるリスクが高いかもしれません。

もちろん、メールが送信されても一致するユーザーがいないとそのまま破棄されるかもしれません。
ですが、送信先でどんな処理が行われているのかはこちらではわかりません。

最悪の場合、

  • パスワード変更用のURLが含まれるメールが意図しないドメインに送信される
  • そのメールを受け取った悪意ある第三者がパスワード変更画面経由でステージング環境に侵入する
  • ステージング環境に本番環境とほぼ同等のデータが入っていたため、間接的に情報漏えいインシデントに発展する

・・・みたいなことが起きるかもしれません。

開発環境やテストコード上だったらいいんじゃない?

ローカルマシン上の開発環境やテストコード上では実際にメール送信が行われる可能性は低いかもしれませんが、どんな状況下でも絶対にないとは言い切れません。
ですので、やはり「デタラメなドメインのメアド」を登録するのはなるべく避けた方が良いと思います。

というか、開発環境やテストコード上では事故を防ぐというよりもむしろ、「無意識にデタラメなドメインを付けてしまう」という悪いクセを無くす目的で、僕はコードレビュー時によく指摘しています。

そんなあなたのための example.com

では、どんなドメインを使えばいいのでしょうか?
こういうときにピッタリなのが example.com です。
example.com であれば万一誤送信してしまっても問題が起きません。

example.com, example.net, example.org, example.eduは、ソフトウェアドキュメンテーションやドメイン名の例示のために予約されているセカンドレベルドメインである。
(中略)
これらのドメイン名が予約されていることによって、マニュアルやソフトウェア構成のサンプルでこれらのドメインを使用することが可能である。すなわち、エンドユーザーがサンプルの設定や例示をそのまま使用してしまったとしても、第三者に悪影響が及ばないことが保障されている。

引用元 https://ja.wikipedia.org/wiki/Example.com

上の説明にあるように、example.com に加えて example.net や example.org 、example.edu 使うのもOKです。

というわけで、これからは「開発時に使うデタラメなメールアドレス」は次のように example.com (または example.net や example.org 、example.edu )を使いましょう。

hoge@example.com
test@example.com
aaaa@example.com

自社のドメインもOKかも

example.com 以外で誤送信しても大きな問題に発展しにくそうなのは自社のドメインでしょう。

ですので、「開発時のテストユーザーには example.com か自社のドメインを使う」というルールにしても良いかもしれません。

ただし、「自社のドメインが変わって、旧ドメインが別の第三者に取得された」とか「誤送信が多すぎて、自社ドメインのreputationが低下し、迷惑メールと判定されやすくなってしまった」みたいな問題は発生するかもしれないので、その点はくれぐれもご注意ください。

テストコードの修正例

以下はrspec-railsで書いたテストコードを修正する例です。
心当たりがある人はテストコードを修正しましょう!

 require 'rails_helper'

 RSpec.feature 'ログインとログアウト' do
   background do
     # ユーザを作成する
-    User.create!(email: 'foo@hoge.com', password: '123456')
+    User.create!(email: 'foo@example.com', password: '123456')
   end
   scenario 'ログインする' do
     # トップページを開く
     visit root_path
     # ログインフォームにEmailとパスワードを入力する
-    fill_in 'Email', with: 'foo@hoge.com'
+    fill_in 'Email', with: 'foo@example.com'
     fill_in 'Password', with: '123456'
     # ログインボタンをクリックする
     click_on 'ログイン'
     # ログインに成功したことを検証する
     expect(page).to have_content 'ログインしました'
   end
 end

他にもある例示/実験用ドメイン

(2020.7.30追記)

この記事では僕がふだんよく使っている example.com を取り上げましたが、.test など、予約済みの例示/実験用ドメインは他にもあります。

詳しくは以下のページを参考にしてみてください。

まとめ

@example.com で安全安心なシステム開発を!

1064
601
10

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1064
601