Login/Register
What is the difference between server side cookie and client side cookie?
Asked Answered
httpcookiessession-cookies
S

5

201

What is the difference between creating cookies on the server and on the client? Are these called server side cookies and client side cookies? Is there a way to create cookies that can only be read on the server or on the client?

Summarize answered 3/8, 2011 at 5:41 Comment(4)
There is no such thing as 'server side cookie' vs 'client side cookie'. There are only cookies, name/value pairs sent in HTTP headers with both requests and responses. – Gaitan
Possibly referencing Session variables, which hold data on the server. Usually there is still a session identifier that is held as a client side cookie. – Venusian
In all likelihood, the question refers to the different ways cookies are encoded on the server side (i.e. the way they're encoded in the 'Cookie' and 'Set-Cookie' response header) and on the client side (i.e. the way they're encoded in the 'Cookie' request header - $Path variable and all that jazz). See RFC 2109 – Cloyd
The main difference might be amplified by slightly renaming the things: client-set and server-set cookies. Cookies are being sent in requests and responses, but the main difference is at which side the cookie (or another id referring to a session) is created. – Notarize
C
178

HTTP COOKIES

Cookies are key/value pairs used by websites to store state information on the browser. Say you have a website (example.com), when the browser requests a webpage the website can send cookies to store information on the browser.

Browser request example:

GET /index.html HTTP/1.1
Host: www.example.com

Example answer from the server:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: foo=10
Set-Cookie: bar=20; Expires=Fri, 30 Sep 2011 11:48:00 GMT
... rest  of the response

Here two cookies foo=10 and bar=20 are stored on the browser. The second one will expire on 30 September. In each subsequent request the browser will send the cookies back to the server.

GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*

SESSIONS: Server side cookies

Server side cookies are known as "sessions". The website in this case stores a single cookie on the browser containing a unique Session Identifier. Status information (foo=10 and bar=20 above) are stored on the server and the Session Identifier is used to match the request with the data stored on the server.

Examples of usage

You can use both sessions and cookies to store: authentication data, user preferences, the content of a chart in an e-commerce website, etc...

Pros and Cons

Below pros and cons of the solutions. These are the first that comes to my mind, there are surely others.

Cookie Pros:

  • scalability: all the data is stored in the browser so each request can go through a load balancer to different webservers and you have all the information needed to fullfill the request;
  • they can be accessed via javascript on the browser;
  • not being on the server they will survive server restarts;
  • RESTful: requests don't depend on server state

Cookie Cons:

Session Pros:

  • generally easier to use, in PHP there's probably not much difference.
  • unlimited storage

Session Cons:

  • more difficult to scale
  • on web server restarts you can lose all sessions or not depending on the implementation
  • not RESTful
Corporate answered 3/8, 2011 at 10:17 Comment(14)
session pros: secure? – Jocund
why sessions more secure? If you send the session cookie over http it can be hijacked. If the site uses https security should be the same as long as you use secure cookies (encrypted, signed, etc...) – Corporate
Cookies cons: makes each request bigger, potentially affecting performance. I don't know the numbers but since people do use cookieless domains for things I assume it's nontrivial. – Ledger
Largely misleading answer - sessions are not cookies. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session You can have session variables, depending on the way session management is implemented on the server. You usually have one or more cookies which are related to the session management, by holding the session identifier. Also REST and RESTful have nothing to do with cookies or session management - REST and RESTful implementations can have sessions and cookies. – Wornout
@ZlatinZlatev it depends... If the backend (for example article-service) needs to make a request to let's say user-service, which stores all the current session-ids, then this will cause performance and scalability problems. But if the cookies/sessions are not stored anywhere on the backend, but instead only the secret for the signing algorithm, then article-service can say "yes dear client, the cookie given to you by the user-service is legit" and respond immediately without making a request to the user-service – Mandalay
@Mandalay thanks for the necromancy. However what you are referring to are first and third party cookies. And representing a third party cookie (one from what you call an user-service) as a first party cookie (as a cookie originating from what you call article service). In any case my statement was related to the fact that session variables have little to do with cookies, you can have session variables as long as you are able to identify the session. Also what you suggest has potential session hijacking vulnerability. – Wornout
@ZlatinZlatev in my experience session variables are implemented using some form of a SessionID cookie most of the time (PHP, Java, .NET), another option I've seen is adding the SessionID in the URLs, but this approach also has session hijacking risks. URLs can be copied and pasted, read from a malicious js script, etc... To make cookies secure you have to always use https and set httpOnly and secure flags to make them unreadable from js. BTW are there other ways to implement sessions? – Corporate
@ZlatinZlatev what I was referring to is basically JWT. You can have it inside an Authorization header or inside a Cookie one. The User-Service might as well be an external resource/provider like the Authorization Server in OAuth2. The cookie is used by the website only to save the state on a refresh. You might as well use localstorage for that (remember, even if the JWT does not get deleted, the token will expire and be useless after some time) – Mandalay
See #35055340 I was not saying that sessions are not typically implemented with cookies, but that there are other options for session management, hence it is wrong to talk about session variables as server-side cookies. I was also referring to JWT when I said in year 2017 in the comment above that "REST and RESTful implementations can have sessions and cookies". Although some purists may argue that this is not the proper way for implementing a REST API. – Wornout
there something I don't get, bugs me... if someone could debug : cookies are stored as files on the client 1. why are they sent to the server in http headers ?? (they can be read on the client !) 2. if the server sends "Set-Cookie: foo=10" BACK to the client, it suggests that cookies are also stored on the server. I guess $_COOKIE (php) gets the value from the local file. Is it correct that the value is also stored on server side ? in that case, how can I get the server side value ? – Paulsen
I try to debug :-) 1. tools.ietf.org/html/rfc6265 the abstract should answer. HTTP is a stateless protocol. The Set-Cookie header stores state info in the client. The client needs to send it back otherwise the server has no access to this state information. 2. No in general the server does not store information sent using Set-Cookie (unless it's a session identifier - See the response above). $_COOKIE reads from HTTP Header, $_SESSION instead reads from local files and sends a 'PHPSESSIONID' cookie to the client in order to match the client with the info stored on the server. – Corporate
@Corporate thanks for the try but I still miss something..;-}... let me ask differently : the text files that are stored on the client, the one you can see in your browser settings, how are they used ? is it for something totally diffrent than what happens on a setcookie() instruction ? – Paulsen
You mean a usage example of cookie? Or how to access cookie in the browser? For the second you can use document.cookie developer.mozilla.org/en-US/docs/Web/API/Document/cookie in javascript (it's the only way) but not all cookie are readable via javascript. It's the server that decides using the HTTP-Only flag – Corporate
what I'm trying to figure out is how the informaiton is moving around between the cookie files on the server, variables in the code and any other storage that might be on the server. I tried the exemple of document.cookie on the page you pointed out and I do not see why I can not see the cookie in the browser list now. where is the cookie document.cookie created ?? – Paulsen
W
89

You probably mean the difference between Http Only cookies and their counter part?

Http Only cookies cannot be accessed (read from or written to) in client side JavaScript, only server side. If the Http Only flag is not set, or the cookie is created in (client side) JavaScript, the cookie can be read from and written to in (client side) JavaScript as well as server side.

Walton answered 3/8, 2011 at 6:0 Comment(1)
This is the correct answer IMO, as it gets to the heart of the question without getting distracted by sessions (which is described unhelpfully in the most popular answer, and is irrelevant as you can have session cookies which are readable on the client and session cookies which are httponly.) – Idolatry
V
62

All cookies are client and server

There is no difference. A regular cookie can be set server side or client side. The 'classic' cookie will be sent back with each request. A cookie that is set by the server, will be sent to the client in a response. The server only sends the cookie when it is explicitly set or changed, while the client sends the cookie on each request.

But essentially it's the same cookie.

But, behavior can change

A cookie is basically a name=value pair, but after the value can be a bunch of semi-colon separated attributes that affect the behavior of the cookie if it is so implemented by the client (or server). Those attributes can be about lifetime, context and various security settings.

HTTP-only (is not server-only)

One of those attributes can be set by a server to indicate that it's an HTTP-only cookie. This means that the cookie is still sent back and forth, but it won't be available in JavaScript. Do note, though, that the cookie is still there! It's only a built in protection in the browser, but if somebody would use a ridiculously old browser like IE5, or some custom client, they can actually read the cookie!

So it seems like there are 'server cookies', but there are actually not. Those cookies are still sent to the client. On the client there is no way to prevent a cookie from being sent to the server.

Alternatives to achieve 'only-ness'

If you want to store a value only on the server, or only on the client, then you'd need some other kind of storage, like a file or database on the server, or Local Storage on the client.

Veto answered 3/8, 2011 at 6:28 Comment(6)
hi, I am very new to these concepts and have some doubts. I am sorry, my questions may sound silly but I will still ask. Any help, is much appreciated - Can a cookie, that has been set on the client side, be sent to any domain ? I mean, is that not a security threat? Also, how does it work with non-browser clients, like APIs etc? – Trochee
Hi @KaranChadha , if you have a question, please ask it as a formal question using the 'Ask Question' button at the top of the page. A comment thread on a 7 years old question probably won't draw the right amount of attention to it. Adding a link to this Q&A, or even to this answer specifically, is fine of course. You can use the 'share' button at the bottom of each post for that. – Veto
Is this true? Client generated cookies don't seem to be transferred. If doing document.cookie="foo=bar" followed byfetch("/foobar", {credentials: 'include'} ) there is no cookie being sent containing foo=bar. Just tried that code directly on this site using DevTools and the console. – Ashlynashman
Yes it's true, says also the docs, but there are some specifics that may cause this, like the missing expires attribute. – Veto
"There is no difference" : Can client overwrite a server-set cookie? – Lunde
@MarinosAn Yes it can. But my answer was a bit brief when it came to the attributes that modify the behavior of the cookie, so I expanded it a little now. – Veto
T
19

What is the difference between creating cookies on the server and on the client?

What you are referring to are the 2 ways in which cookies can be directed to be set on the client, which are:

  • By server
  • By client ( browser in most cases )

By server: The Set-cookie response header from the server directs the client to set a cookie on that particular domain. The implementation to actually create and store the cookie lies in the browser. For subsequent requests to the same domain, the browser automatically sets the Cookie request header for each request, thereby letting the server have some state to an otherwise stateless HTTP protocol. The Domain and Path cookie attributes are used by the browser to determine which cookies are to be sent to a server. The server only receives name=value pairs, and nothing more.

By Client: One can create a cookie on the browser using document.cookie = cookiename=cookievalue. However, if the server does not intend to respond to any random cookie a user creates, then such a cookie serves no purpose.

Are these called server side cookies and client side cookies?

Cookies always belong to the client. There is no such thing as server side cookie.

Is there a way to create cookies that can only be read on the server or on the client?

Since reading cookie values are upto the server and client, it depends if either one needs to read the cookie at all. On the client side, by setting the HttpOnly attribute of the cookie, it is possible to prevent scripts ( mostly Javscript ) from reading your cookies , thereby acting as a defence mechanism against Cookie theft through XSS, but sends the cookie to the intended server only.

Therefore, in most of the cases since cookies are used to bring 'state' ( memory of past user events ), creating cookies on client side does not add much value, unless one is aware of the cookies the server uses / responds to.

Reference: Wikipedia

Triable answered 28/10, 2020 at 11:26 Comment(0)
G
3

  1. Yes you can create cookies that can only be read on the server-side. These are called "HTTP Only" -cookies, as explained in other answers already

  2. No, there is no way (I know of) to create "cookies" that can be read only on the client-side. Cookies are meant to facilitate client-server communication.

  3. BUT, if you want something LIKE "client-only-cookies" there is a simple answer: Use "Local Storage".

Local Storage is actually syntactically simpler to use than cookies. A good simple summary of cookies vs. local storage can be found at:

https://courses.cs.washington.edu/courses/cse154/12au/lectures/slides/lecture21-client-storage.shtml#slide8

A point: You might use cookies created in JavaScript to store GUI-related things you only need on the client-side. BUT the cookie is sent to the server for EVERY request made, it becomes part of the http-request headers thus making the request contain more data and thus slower to send.

If your page has 50 resources like images and css-files and scripts then the cookie is (typically) sent with each request. More on this in Does every web request send the browser cookies?

Local storage does not have those data-transfer related disadvantages, it sends no data. It is great.

Gogetter answered 7/11, 2018 at 15:39 Comment(1)
2. No, there is no way (I know of) to create "cookies" that can be read only on the client-side. Cookies are meant to facilitate client-server communication. What about document.cookie? JavaScript can set the client side cookie right? – Pyrography

© 2022 - 2024 — McMap. All rights reserved.