从历史上看，Cookie 一直是众多安全和隐私问题的根源。

例如，跟踪器 cookie 可用于识别您访问过哪些网站以及您在这些网站上进行了哪些活动：

1. 站点 A 包括指向跟踪器服务的隐藏iframe点。
2. Tracker 服务会发出一个 cookie 来识别您的身份，并记录您的访问。
3. 站点 B 包括相同的隐藏iframe.
4. 跟踪服务会识别您的 cookie，并记录您的访问。
5. 站点 A 和站点 B 向跟踪器付费以获取有关其用户访问的其他站点的信息。

这只是一个应用程序。还有其他使用跟踪器 cookie 的方法，其中一些允许各种讨厌的攻击，例如身份盗用。

另一个问题是cookie-stealing，它可以用来劫持不安全（即非HTTPS）的会话。使用漏洞利用（例如 XSS），页面可能会设法将另一个站点的 cookie 发回给自己，从而允许攻击者窃取您的会话 ID。关闭 cookie 可以防止这种情况。

由于这些问题，用户经常在某些网站上禁用 cookie 或阻止它们，以提高隐私和安全性。

借助跟踪 cookie，广告商可以跨不同网站甚至跨 IP 地址（例如笔记本电脑用户）跟踪用户。这种情况一直存在（从字面上看是从广告网络开始，如谷歌 Adwords 开始），但最近媒体一直在煽动公众反对这些 cookie，将它们归咎于侵犯隐私的根本原因。到目前为止，欧盟通过了一些本应禁止不必要的 cookie 而不选择加入的东西。具有讽刺意味的是，荷兰政府的网站（这里的法律几个月前生效）也不遵守法律。

这些 cookie 实际上，部分是隐私信任的原因。它使您易于跟踪，但是还有很多其他方法可以区分一个用户和另一个用户。此外，几乎没有任何理由阻止这种定向广告，它是双向的，但这是另一个主题和热议。

如果没有 cookie，您几乎无法让用户保持登录状态。当 cookie 被禁用时给出适当的错误（“您可能无法登录，cookie 在您的浏览器中被禁用，单击此处获取更多信息。”），我认为它已经结束了。无论如何，如果没有 cookie，大多数其他网站（如 Facebook 和 Twitter）也将无法运行。

最常见的原因是他们不小心做了，不知道自己做了（见下文第 4 段）。

第二个最常见的原因是隐私（偏执狂？）。有些人不惜一切代价反追踪。我倾向于发现他们并不真正了解这种情况下的 cookie 是什么。他们更有可能只是认为“跟踪不好”并关闭它们 - 例如，不知道会话 cookie、第一/第三方 cookie 等之间的区别是什么。

然而更重要的是，我不认为考虑用户在除了非常基本的网站之外的任何东西上禁用 cookie 的情况是不现实的。除了跟随指向静态内容的链接之外，在用户交互非常少的基本网站之外的任何地方都无法避免使用 cookie（或基于 URL 的等效项）。您可以忘记登录和购物篮，因为要创建它们，您至少需要一个会话或 cookie（会话跟踪需要 cookie 或 URL 等效项）。

在 12 年的网站开发者生涯中，我遇到的唯一一个禁用 cookie 的人是不小心这样做的。没有例外，这是因为他们一直在 Internet Explorer 的设置屏幕中，并认为将安全/隐私滑块推到“高”必须比“中”更好。在所有情况下，一旦我指出它有什么影响以及它破坏了多少网站，他们就会把它放回中等。通常用户安装了第二个浏览器，认为他们原来的浏览器“坏了”，因为没有网站可以使用它。因此，我认为如果您的网站流量很大，告诉用户他们禁用了 cookie（使用合适的检测方法）很重要。

您可以通过在 URL 中存储唯一 ID 来避免使用 cookie（.NET 和其他框架本机支持这一点），但我相信这只会将问题转移到 URL - 偏执的用户可能会被一个明显跟踪他们的 URL 推迟. 一定要确保，如果你想出一个自制的方法来做同样的事情，任何 URL ID 都与用户的 IP 地址相关联。如果没有，您将创建一个非常简单的会话劫持方法 - 因为用户只需发送链接，就会获取发送用户的会话状态。

绝大多数需要登录或具有购物车功能的主要网站都需要 cookie 才能工作，我认为尝试解决这个问题并不明智。您说的可能是 1% 的禁用 cookie 的用户中的一小部分。忽略从 WebTrends 等自动系统生成的统计数据，因为这些数据将包括不（也不需要）支持 cookie 的网络爬虫和机器人，因为这会使您错误地读取已禁用的用户数量饼干。您肯定说的更像是 5000 分之一，而不是 10 分之一的用户禁用了 cookie 并且实际上仍然希望网站能够正常工作:)

文档中写道，我必须为用户禁用 cookie 的情况做好准备。

“准备”与制作一个没有 HTTP cookie 的功能齐全的登录系统不同。

用户可以关闭 HTTP cookie 以避免“被跟踪”；在这种情况下，您可以考虑使用另一种会话管理方法，例如使用秘密 URL。在 URL 中保留会话 ID 有一定的安全性和可用性优点，但也存在非常严重的安全性和可用性问题，此消息不推荐这种方法。因为问题不是关于在 URL 中保留会话 ID 的安全性，所以我不想在这里讨论这个（有趣的）问题。

这个问题不仅仅是技术问题，它是一个可接受性问题：如果用户自愿关闭 cookie，你可以打赌他不想被跟踪。试图绕过cookie 的阻塞（甚至“为了他自己的利益”）很可能会让他心烦意乱。

相反，您可以向用户解释您的 Web 应用程序中的会话管理只需要会话 cookie，并且可以在关闭浏览器时自动清除所有 cookie。