Is there a Cloudflare setting that corresponds to the creation of the __cfduid session cookie?

I'm currently trying out CF; mostly for the neat DNS management and the implicit CDN. But the basic WAF is possibly just as nice an addition atop Apaches mod_security/CRS. However I'm not sure what said cookies purpose is, and would prefer to get rid of that.

The most obvious setting

Security profile: Essentially off

Seems to also have essentially no effect on the creation of __cfduid with every HTTP response. The cookies purpose is presumably for opting out single users from firewall rules, repeated cloudflare captchas, etc.

Their support documentation alludes to that. Where the first revision from 09/2012 (https://support.cloudflare.com/hc/en-us/articles/200169536-What-does-the-cfduid-cookie-do-) says this behaviour can't ever be turned off. An entry two months later 11/2012 (https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-CloudFlare-cfduid-cookie-do-) however omits that note.

While Cloudflares TOS itself check out as plausible, this cookie has all the properties of a tracking session, dc41f5a78bc3e27d44b70fca4606e4262283407700773. The excessive cookie lifetime of 6 years is very odd for the exemplary internet cafe visitor use case. And since I'm personally avoiding needless sessions, and don't want to plaster a privacy note (in light of the infamous EU cookie law) like everyone else, I'd prefer to have it gone per default.

A workaround like:

  Header add Set-Cookie "__cfduid= ; path=/; domain=.example.org; HttpOnly"

Does eschew its storage, but retains two needless headers, and doesn't seem overly reliable.

So, is there another CF setting for this?

  • 1
    Aside from amusing things like this, the only available workaround is to proxy the connection and strip the cookie before it hits the client.
    – Synchro
    Commented Jul 6, 2018 at 16:42

3 Answers 3


No, there is no way to turn the cookie off if we are proxying the record (if you had a subdomain not running through our proxy in your DNS settings, then we wouldn't add the cookie because it is going direct to your server). The cookie is basically what makes security (like a challenge page) work.

  • 10
    "Makes security work" is still vastly indescriptive. How does it aid security against e.g. bots which aren't typically sending session cookies along? If it's just for CAPTCHAS then what's the excessive cookie expiry time for?
    – mario
    Commented Mar 18, 2014 at 18:27
  • 2
    I suspect it's for establishing who is trusted, not who isn't trusted. If you don't have the session cookie, you are in the state of least trust. If you have the session cookie, you can be untrusted or trusted or anywhere in between. Thus, not sending the session cookie means you'll be treated in a more hostile manner by the WAF, not less. It would then follow that it has an 'excessive' cookie expiry time to stop you being needlessly pestered or throttled in future.
    – Rushyo
    Commented Apr 9, 2015 at 15:34
  • 1
    Turns out cloudflare hosts a lot stuff i often browse (api documentation, open source projects), which are all useless to me right now. No. I'm not going to enable random session cookie injection on domains that have nothing with cloudflare to do (like jqueryui.com, expressjs.com). __cfduid breaks internet standards. It's wrong. Commented Apr 28, 2015 at 13:58

What is the problem with this cookie? You are using their service and want to benefit from their service and their security – according to Cloudflare, this cookie helps especially for security reasons. Regardless of that, this type of cookie is exempt from the cookie law message:

However, some cookies are exempt from this requirement. Consent is not required if the cookie is:

· used for the sole purpose of carrying out the transmission of a communication, and

· strictly necessary in order for the provider of an information society service explicitly required by the user to provide that service.

Read more: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm

This Cloudflare cookie is definitely exempt from the cookie law.

  • 3
    "for security reasons" is precisely the wishy-washy explanation which triggered this question. What is it used for now? Why is it still there when "security" features are disabled? Why does it have 6 years lifetime? The legal opinion on this is mostly orthogonal.
    – mario
    Commented Oct 28, 2016 at 18:40
  • I'm afraid that anyone can answer this question regarding the security when even Cloudflare Employees (I assume that damoncloudfare is one) can't tell you, regardless of which reasons.
    – Luca Steeb
    Commented Oct 28, 2016 at 22:15
  • 3
    Here is one problem with this cookie: It triggers various false positives in vuln/PCI scanners. Example, Saintbot/Controlscan sees the response with a cookie bases session var and flags it as phprpc vuln, even though the phprpc is not present (404). Its annoying that we constantly fail scheduled PCI scans because of this simple cookie. Sure its the vendors fault, but after 20 or so attestations + tickets, and calling them out on it, they still haven't fixed the scan filter. Because of that failure to repair, this CF cookie causes PCI fail under the premise of false positive (still a fail).
    – dhaupin
    Commented Jan 4, 2017 at 15:17
  • I would say you should blame the scanners, not Cloudflare..
    – Luca Steeb
    Commented Jan 4, 2017 at 16:00
  • The other problem aside from vulnerability scanners giving false positives is the performance impact, while it is negligible, it exists and it shouldn't.
    – Ray Foss
    Commented Jan 10, 2018 at 19:19

Steps for disabling a cookie -- php. I cant take credit for this its not my fix but im happy to spread the wealth.

function deleteSpecificCookies() {

    var cookies = document.cookie.split(";");
    var all_cookies = '';

    for (var i = 0; i < cookies.length; i++) {

        var cookie_name  = cookies[i].split("=")[0];
        var cookie_value = cookies[i].split("=")[1];

        if( cookie_name.trim() != '__utmb' ) {

            all_cookies = all_cookies + cookies[i] + ";";



    if(!document.__defineGetter__) {

        Object.defineProperty(document, 'cookie', {
            get: function(){return all_cookies; },
            set: function(){return true},

    } else {

        document.__defineGetter__("cookie", function() { return all_cookies; } );
        document.__defineSetter__("cookie", function() { return true; } );

  • This is JavaScript code, not PHP, and it's a pretty bad idea. This code is redefining a built-in web browser property (document.cookie), and the way it is done will break any other cookies set by client-side script. Commented Oct 30, 2021 at 18:34

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.