Using javascript or in a native iOS App it is possible to read and modify cookies.

The server generally sets these, but if both the server and the client modifies the values then it becomes a global shared mutable state across systems.

This feels bad.

In the RFC it does not mention user agents modifying cookies other than by predefined rules (e.g. Honoring cookie expiry). It also says in the summary about cookies:

… These header fields can be used by HTTP servers to store state at HTTP user agents

However it does not actually prohibit or explicitly advise against clients modifying cookies.

  • Is it acceptable to modify cookies on a user agent?
  • Are there any references or guidelines on this matter?
  • Once a piece of information leaves your servers and gets to your users, it's completely out of your control. So when you do get back a cookie from the user, treat it with a grain of salt.... or maybe 100 grains ;) Commented Feb 15, 2016 at 21:20
  • ...but why would you modify a cookie? In the end it's just a snippet of data sent by the server. You can do whatever you like with it, send it back, ignore it, scramble it. Whatever. It's just pointless.
    – dagnelies
    Commented Feb 15, 2016 at 21:55
  • @arnaud - (a while ago) I supported a website that allowed the user to modify the font-size for viewing through a javascript widget that set/modified a cookie value to maintain consistency during the session.
    – HorusKol
    Commented Feb 16, 2016 at 4:19
  • @HorusKol well, you "can" do that. But ideally, if it's just a local setting, you're better off using localstorage since it doesn't need to be sent to the server. And if it's user settings that should be saved server-side, better make a real request out of it. ...IMHO, using cookies for such things is just weird.
    – dagnelies
    Commented Feb 16, 2016 at 10:51
  • 1
    @arnaud well, this was before local storage... there are probably still use cases out there, even if you think its "weird".
    – HorusKol
    Commented Feb 16, 2016 at 14:33

1 Answer 1


Here's one way to think of it:

It is impossible for the server to directly set a cookie. The server sends an HTTP header, which tells the client to set a cookie. It's the same way with JavaScript or hand-editing, because it is assumed that if the client can change the cookie, the server can't complain (unless the request is malicious).

EU law also explicitly gives the client the right to refuse cookies.

HTTP is stateless, and the cookie isn't part of the protocol itself. This isn't like whether the server should return a proper status code.

Maybe I'm not fully understanding your question, but why does it matter? It's common, accepted practice anyway. Googling "client modify cookie" returns nothing against it.

From Wikipedia:

Although cookies are usually set by the web server, they can also be set by the client using a scripting language such as JavaScript (provided the cookie's HttpOnly flag is not set).

Then skip down a bit:

HttpOnly cookie

HttpOnly cookies can only be used when transmitted via HTTP (or HTTPS). They are not accessible through non-HTTP APIs such as JavaScript. This restriction eliminates the threat of cookie theft via cross-site scripting (XSS), while leaving the threats of cross-site tracing (XCT) and cross-site request forgery (CSRF) intact.

Therefore, we can deduce that the appropriate question isn't whether it's acceptable, but whether we can.

  • Ok I guess a better question might be why you would want to do it? If it is to store state it's better doing it separately since it makes the requests larger. If it's to send data to the server, it is better using other headers that the server can't modify itself?
    – Robert
    Commented Feb 16, 2016 at 11:01
  • @Robert This might be suited to a new thread, but I'll continue anyway. Once a cookie is set it is persistent until it expires. One example: the server stores associated data (e.g. login user) with a session cookie, which is a unique identifier. I can't think of a simpler way to keep someone logged in. Here's Google's cookie policy. What do you mean by doing it separately?
    – user176267
    Commented Feb 17, 2016 at 4:48
  • Yes, this may be better in another thread. I was looking for examples where the client would want to set the state not the server. If the client was using the cookies just as storage it would be better off storing it in local storage. Your answer is useful so I am just going to accept.
    – Robert
    Commented Feb 17, 2016 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.