@cmbuckleyの回答が全体像を示しているかどうかはわかりません。私が読んだのは：
Cookie の属性が特に指定しない限り、Cookie は元のサーバーにのみ返され (たとえば、サブドメインには返されません)、現在のセッションの終了時に期限切れになります (ユーザー エージェントによって定義されます)。ユーザー エージェントは認識されない Cookie を無視します。
また
8.6. Weak Integrity
Cookies do not provide integrity guarantees for sibling domains (and
their subdomains). For example, consider foo.example.com and
bar.example.com. The foo.example.com server can set a cookie with a
Domain attribute of "example.com" (possibly overwriting an existing
"example.com" cookie set by bar.example.com), and the user agent will
include that cookie in HTTP requests to bar.example.com. In the
worst case, bar.example.com will be unable to distinguish this cookie
from a cookie it set itself. The foo.example.com server might be
able to leverage this ability to mount an attack against
bar.example.com.
つまり、サブドメイン/ドメインによる Cookie の読み取りを保護できますが、他のドメインへの Cookie の書き込みを防止することはできません。そのため、誰かが同じブラウザーでアクセスした別のサブドメインを制御して、サイトの Cookie を書き換える可能性があります。これは大きな問題ではないかもしれません。
@cmbuckley が提供する素晴らしい Cookie テスト サイト。上にスクロールして賛成する価値があります/:
どちらの場合も可能です。これは、IE と Edge の両方のデフォルトの動作です。
他の回答は貴重な洞察を追加しますが、主に Chrome での動作について説明しています。IE では動作がまったく異なることに注意してください。CMBuckley の非常に役立つテスト スクリプトは、(たとえば) Chrome で、ドメインが指定されていない場合、ルート ドメインとサブドメインの間で Cookie が共有されないことを示しています。ただし、IE での同じテストは、それらが共有されていることを示しています。この IE のケースは、CMBuckley の www-or-not-www リンクにあるお持ち帰りの説明に近いものです。ルートとサブドメインの両方で異なるサービススタック Cookie を使用するシステムがあるため、これが事実であることはわかっています。誰かが IE でアクセスし、キャッシュを爆破するまでどちらのセッション Cookie が勝つかをめぐって 2 つのシステムが争うまでは、すべて正常に機能していました。
シンプルなソリューション
setcookie("NAME", "VALUE", time()+3600, '/', EXAMPLE.COM);
Setcookie の 5 番目のパラメーターは、Cookie を使用できる (サブ) ドメインを決定します。(EXAMPLE.COM) に設定すると、任意のサブドメインで使用できるようになります (例: SUBDOMAIN.EXAMPLE.COM )