I was recently told that a cookie is "safer" than a regular old HTTP header, which is safer than a URL parameter, particularly when passing around access tokens. What is the reasoning behind a cookie being safer than an HTTP header?

Also, I'm pretty sure I understand why a URL param is unsafe: because it is visible all the time and can easily be grabbed. Is that correct?

  • "Safe" is a meaningless term, just as "secure". You have to define a context: who is your adversary? Do you consider the possibility of wiretapping? Do you consider a website with user supplied contain, like this very website?
    – curiousguy
    Aug 8, 2013 at 7:10
  • Yes, parameters in the URL are visible, will be stored in browser history, will be more likely to be stored in server logs, and can be passed in referer headers by the browser. Aug 8, 2013 at 9:23

6 Answers 6


Cookies are HTTP Headers. The header is called Cookie:, and it contains your cookie.

But cookies are in fact safer than URL parameters because cookies are never sent to other domains. URL parameters, on the other hand, will end up in the Referer: header of any site you visit directly from the one with the URL parameter.

  • Are you saying Referrer contains the full query string? Or just variables passed as part of the path?
    – lynks
    Aug 7, 2013 at 9:42
  • 2
    Referer: (correctly misspelled) is up to the browser to implement, but as a rule it contains the referring URL exactly; including query string.
    – tylerl
    Aug 7, 2013 at 17:37
  • 1
    @lynks The Referer contains the whole URL as sent to the HTTP server. It does not contain the local part after the #.
    – curiousguy
    Aug 8, 2013 at 7:07
  • 1
    +1 Cookies also come with useful features like "secure" and "httponly".
    – u2702
    Aug 8, 2013 at 16:42

There are three standard ways to pass data from the browser: GET, POST, and cookies (which are sent for both GET and POST requests). Here's an example request as it's sent to a server if you asked for www.example.org/spec.html?secret=foo:

GET /spec.html?secret=foo HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*

Putting session information in the URL makes it prone to being copied by the browser's user. From a visibility standpoint on the wire, though, it makes no difference. It's for this reason that sensitive data is often POSTed. Whichever way you make a request, keep in mind it probably should be protected against CSRF.

As for cookies, they provide a way to store data that lasts across the duration of a session or throughout browser tabs.

  • Is there any security advantage with the same origin policy?
    – mergesort
    Aug 7, 2013 at 4:21
  • 1
    The same origin policy prevents sites access to cookies which are not their own... but an advantage over what? Aug 7, 2013 at 4:34
  • 2
    Don’t forget PUT, PATCH and DELETE. They also respond with data.
    – idmean
    Jul 15, 2015 at 6:32

If you are passing authorisation token via http headers then you need to have a client side logic to pass this to server every time you make a request. A skimmer can look for this in your client side code and can hijack your user session with Java script.

But if the same info is passed via cookies then it is the browsers responsibility to pass the cookie whenever a request is made(you are freed of writing client side logic). So making it a bit difficult(but not impossible) to identify the mechanism in which the token is being passed.

If the cookie is set to be httponly then session hijacking becomes almost impossible via JavaScript(have read some browsers do give out this info to JavaScript but support is increasing). And cookies have a same origin policy. But still using tools like fiddler a determined hacker will be able to access this info.

But the hacker should be able to sniff the network to get to this info.

So in conclusion a cookie is definitely safer.

If you are so concerned about security then go for SSL certificates which almost removes the threat of network sniffing a futile activity.


Cookies are part of the HTTP header, so they can not be safer than themselves. Cookies have security flags built into their specification: HTTPOnly and Secure, the latter of which prevents transmission over non-SSL connections.

Parameters as part of the URL are prone to being logged by web services you're running as part of statistics or otherwise, leaving them open to read in plaintext for anyone who can get access.

  1. URL parameters get sent in the Referer header to other sites, so are the worst way to pass sensitive data.

  2. The (obsolete) Cookie2 header is encrypted using a nonce provided by the site in its Set-Cookie2 response header. This therefore is the least bad, but isn't supported well.

  3. Other request headers (including Cookie) are somewhere in between.

None of these options are "safe".

The only safe option is HTTPS (i.e. SSL) using a mutually trusted certificate authority.

  • I would like to point out that the RFC you reference (2965) was obsoleted by RFC 6265 and depreciates and obsoletes the Set-Cookie2 and Cookie2 headers as their use and implementation are no longer recommended.
    – Joshua
    Aug 8, 2013 at 4:56
  • 1: You (the webmaster) control the outbound links. If you can manage to have only links to sites under your control, 1. is not a problem. 2: Who implements Cookie2?
    – curiousguy
    Aug 8, 2013 at 7:05
  • @curiousguy, it's not just outbound links that have a referrer. If an attacker injects an image, javascript, or any other resource in the page, the browser will download the resource. When the browser fetches those resources, it'll include the referrer header too.
    – Joshua
    Aug 8, 2013 at 15:57
  • 2
    @Joshua "If an attacker injects an image, javascript" If the attacker can inject JS, then he just controls the webpage. He does not need the capture a Referer. He can read (even capturing form data) and modify any part of the page (displaying incorrect information to the user, or changing form data just before submission), and retrieve any cookie not marked HTTPOnly, and do anything on behalf of the user.
    – curiousguy
    Aug 8, 2013 at 22:17

I guess both cookies and headers have strong and weak points. Since some answers already point to the cookies strong points, I will mention the strong point of headers. Headers need to be transmitted programmatically by the js application; they are never automatically transmitted by the browser upon accessing an URL on the respective domain. This makes such that other js applications or snippets cannot send the header automatically, thus eliminating a whole range of attacks in the CSRF or cross site scripting areas. Of course using only HTTPS over TLS and disabling downgrading to HTTP are necessary in both cases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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