Are HTTP cookies port specific?

Question

I have two HTTP services running on one machine. I just want to know if they share their cookies or whether the browser distinguishes between the two server sockets.

score 450 · Accepted Answer · edited Oct 07 '21 at 05:46

The current cookie specification is RFC 6265, which replaces RFC 2109 and RFC 2965 (both RFCs are now marked as "Historic") and formalizes the syntax for real-world usages of cookies. It clearly states:

Introduction

...

For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for "secure" connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.

And also:

8.5. Weak Confidentiality

Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security sensitive information.

`/etc/hosts` can be used to create more cookie domains for `127.0.0.1` than `localhost` — Michael Cole, Dec 05 '20 at 14:25
CORS changes the game rules: https://stackoverflow.com/questions/46288437/set-cookies-for-cross-origin-requests With it you have server side: `Access-Control-Allow-Credentials`, `Access-Control-Allow-Origin`, `Access-Control-Allow-Headers` + cookie setting `Secure`, `SameSite=None` and client side: `XMLHttpRequest.withCredentials` + ES6 fetch() `credentials: 'include'` — gavenkoa, Sep 25 '22 at 08:37

score 152 · Answer 2 · edited May 25 '15 at 15:22

152

According to RFC2965 3.3.1 (which might or might not be followed by browsers), unless the port is explicitly specified via the port parameter of the Set-Cookie header, cookies might or might not be sent to any port.

Google's Browser Security Handbook says: by default, cookie scope is limited to all URLs on the current host name - and not bound to port or protocol information. and some lines later There is no way to limit cookies to a single DNS name only [...] likewise, there is no way to limit them to a specific port. (Also, keep in mind, that IE does not factor port numbers into its same-origin policy at all.)

So it does not seem to be safe to rely on any well-defined behavior here.

edited May 25 '15 at 15:22

Ilan Frumer

32,059
8
70
84

answered Nov 18 '10 at 08:41

Tgr

27,442
12
81
118

97

[RFC 6265](http://tools.ietf.org/html/rfc6265), which replaces RFC 2965, eliminates the `Port` parameter in the `Set-Cookie` header (because almost nobody actually used it in practice), and makes it very explicit that cookies on the same host ARE NOT distinquishable by ports anymore. – Remy Lebeau May 02 '13 at 00:12
6

IE 9 won't even send the cookie back on subsequent requests if the domain has a port in it – axk Sep 04 '13 at 10:42
4

Is there any browser that is still considering port in its cookies' SOP? – Bertuz May 28 '16 at 10:32
8

Chrome won't even set the cookie if it has the domain has a port in it. – Pim van der Heijden Sep 25 '17 at 19:16

Pat · Answer 3 · 2014-01-11T03:07:51.133

113

This is a really old question but I thought I would add a workaround I used.

I have two services running on my laptop (one on port 3000 and the other on 4000). When I would jump between (http://localhost:3000 and http://localhost:4000), Chrome would pass in the same cookie, each service would not understand the cookie and generate a new one.

I found that if I accessed http://localhost:3000 and http://127.0.0.1:4000, the problem went away since Chrome kept a cookie for localhost and one for 127.0.0.1.

Again, noone may care at this point but it was easy and helpful to my situation.

edited Jan 11 '14 at 03:07

answered May 01 '13 at 23:57

Pat

2,411
2
16
11

4

Yes, because cookies are associated with host/domain names, so a cookie on `localhost` cannot by shared with `127.0.0.1` and vice versa. But cookies on the same host/domain, regardless of port, are sharable. – Remy Lebeau May 02 '13 at 00:20
This probably works only in Chrome, as most other browsers don't send cookies to "localhost" (=a string without two dots) – Max Mar 06 '14 at 11:35
5

Of course they do. I (and probably million other developers) use localhost for testing all the time. Unless the added port makes a difference: http://localhost:8080/ – David Balažic Jun 12 '14 at 10:08
86

Also, you can use 127.0.0.1, 127.0.0.2, 127.0.0.3 etc... they all mean localhost. – David Balažic Jun 12 '14 at 10:18
5

If you're willing to edit your hosts file (/etc/hosts on Unix) you can have as many meaningful names as you like for localhost. – Silas S. Brown Jun 05 '17 at 15:08
4

@DavidBalažic No, "localhost" means 127.0.0.1. 127.0.0.2 usually doesn't have a name. These addresses are distinct unicast addresses and treated just as any different unicast addresses by the TCP protocol, but they are all local. – curiousguy Jun 16 '18 at 05:30
2

@SilasS.Brown Please don't say "for localhost". "localhost" is the name associated with a particular IP address. Say "the local host". – curiousguy Jun 16 '18 at 05:32
Also it can be handy to use subdomains like http://foo.localhost:3000 and http://bar.localhost:4000 – Yaroslav May 17 '22 at 11:35

score 23 · Answer 4 · answered Oct 23 '09 at 14:15

23

This is a big gray area in cookie SOP (Same Origin Policy).

Theoretically, you can specify port number in the domain and the cookie will not be shared. In practice, this doesn't work with several browsers and you will run into other issues. So this is only feasible if your sites are not for general public and you can control what browsers to use.

The better approach is to get 2 domain names for the same IP and not relying on port numbers for cookies.

answered Oct 23 '09 at 14:15

ZZ Coder

74,484
29
137
169

15

It is not a gray area anymore. [RFC 6265](http://tools.ietf.org/html/rfc6265), which is the current cookie standard, eliminates any confusion about it by simply eliminating the ability to separate cookies on the same host using different ports. – Remy Lebeau May 02 '13 at 00:16

score 20 · Answer 5 · edited Sep 20 '11 at 11:22

20

An alternative way to go around the problem, is to make the name of the session cookie be port related. For example:

mysession8080 for the server running on port 8080
mysession8000 for the server running on port 8000

Your code could access the webserver configuration to find out which port your server uses, and name the cookie accordingly.

Keep in mind that your application will receive both cookies, and you need to request the one that corresponds to your port.

There is no need to have the exact port number in the cookie name, but this is more convenient.

In general, the cookie name could encode any other parameter specific to the server instance you use, so it can be decoded by the right context.

edited Sep 20 '11 at 11:22

Manolis M. Tsangaris

138
1
7

answered Sep 20 '11 at 09:47

Manolis M. Tsangaris

201
2
2

This works for mutually trusting web services sharing the host name on different port numbers. But all host-related cookies will be sent to all web services of that host regardless of their names. If the host allows malicious unprivileged operators run web services on separate port numbers, the operators can abuse browsers of customers of the original web service into sending all host-related cookies, including the secret ones, to the malicious web service that shares the host. – eel ghEEz Jul 11 '20 at 15:59

score 10 · Answer 6 · answered Feb 16 '12 at 15:51

10

In IE 8, cookies (verified only against localhost) are shared between ports. In FF 10, they are not.

I've posted this answer so that readers will have at least one concrete option for testing each scenario.

answered Feb 16 '12 at 15:51

Jeb

15,939
6
34
37

score 6 · Answer 7 · answered Aug 21 '13 at 10:32

6

I was experiencing a similar problem running (and trying to debug) two different Django applications on the same machine.

I was running them with these commands:

./manage.py runserver 8000
./manage.py runserver 8001

When I did login in the first one and then in the second one I always got logged out the first one and viceversa.

I added this on my /etc/hosts

127.0.0.1    app1
127.0.0.1    app2

Then I started the two apps with these commands:

./manage.py runserver app1:8000
./manage.py runserver app2:8001

Problem solved :)

answered Aug 21 '13 at 10:32

Andrea Grandi

925
11
18

4

you can probably use `127.0.0.1:8000` for one, `localhost:8000` for a second, and possibly `::1:8000` (maybe `[::1]:8080`) for a third without ever having to touch the hosts file. – Travis Watson Sep 06 '13 at 22:06
2

you can put it into one line: ```::1 app1 app2 app3 app4 app5 appN``` – aeroson Oct 25 '16 at 15:54

score -1 · Answer 8 · edited Oct 23 '09 at 10:29

-1

It's optional.

The port may be specified so cookies can be port specific. It's not necessary, the web server / application must care of this.

Source: German Wikipedia article, RFC2109, Chapter 4.3.1

edited Oct 23 '09 at 10:29

Matthew Murdoch

30,874
30
96
127

answered Oct 23 '09 at 08:57

guerda

23,388
27
97
146

2

[Sounds like it's more complicated than this in real life.](http://stackoverflow.com/questions/1612177/are-http-cookies-port-specific/4212964#4212964) – bzlm Sep 12 '11 at 13:31

Are HTTP cookies port specific?

8 Answers8

Linked

Related