クッキーやSame Origin Policyの問題です。
結構HTTPのセキュリティーってややこしいです。
理解が混乱しがちなポイントを問題にしてみました。
もしよろしければ、遊びで作った以下4つの問題にお付き合いください。
※基本的にブラウザの原則(Policy)の話をしているので例外はあります。
問題1
https://example.com のサイトから https://example2.com にXMLHttpRequestを送る事ができるか。
答え
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
回答 → 送る事ができる。
Same Origin Policyの問題です。
Same Origin Policyとは、同じOriginからのリーソースにしかscriptはアクセスできないという原則です。そして、同一Originかどうかは 「プロトコル、ドメイン、ポート」の3つの組み合わせで決定します。
...あれ、https://example.com から https://example2.com ってドメインが違うからリクエストは送信されないんじゃないの！？と思う人もいるかもしれません。
しかし、正しくはリクエストが送信されないのではなく「レスポンスをスクリプトが読み取らない」が正解です。
リクエストの送信自体はできてしまうので、スクリプトインジェクションなどで第三者サーバーに情報が送信されてしまわないように注意しましょう。
また、第三者サーバーがOriginのリクエストがきた場合にデータの更新などの処理をしてしまわないように注意しましょう。
問2
http://example.com:3000 から受け取ったクッキーは http://example.com:3001 へのリクエスト時に送信されるか
答え
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
回答 → 送られる。
これも注意！Same Origin の定義を理解していると引っかかりやすいです。
2はSame Origin Policyの問題ではなく、Cookieの問題です。
Cookieはプロトコル、ポートは関係なくDomainでCookieを送るかどうか判断します。
問3
http://example.com から受け取ったクッキーには"Domain=example.com"の指定がされていた。http://example.com から受け取ったクッキーは https://subdomain.example.com に送信されるか。
答え
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
回答 → 送られる。
これも送られます！
Same Origin Policyではサブドメインでoriginを区別しますが、Cookieのdomain設定をした場合、指定したドメインのサブドメインにもCookieを送信してしまいます。プロトコルも関係ありません。サブドメインで動かしているアプリケーションがある場合、アプリケーションが相互に干渉しあわないようにCookieの設定に注意を払いましょう。
問4
http://example.com から受け取ったクッキーのメタデータにはDomainの指定はなかった。http://example.com から受け取ったクッキーは https://subdomain.example.com に送信されるか。
答え
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
回答 → 送られない。(但し一部例外クライアントあり)
3と非常に似ているので紛らわしいのですが、明示的にDomain指定をしない限りサブドメインにはCookieは送信されません。但し、ドメインを指定しない場合はDomain=example.comと記述したと同じ扱いをしてしまうクライアントも存在するようです。
終わりに
セキュリティーの仕組みを理解していると何故クッキーやセッションなどを暗号化したりしているかの理解が深まりソースコードが分かるようになります。
セキュリティー関係は可視化されにくいですが非常に重要な知識で、ちゃんと正しくリスクを把握して説明できるととても重宝されると思います。
興味を持ったら学習してみると良いでしょう。