Cookie: what the browser sends back

Everything the server said about a cookie is stripped before it comes back. The request carries names and values and nothing else, so a server cannot tell whether an arriving cookie was marked Secure, which host set it, or when it will expire. Any of that you need has to be encoded in the value or held server side.

Two cookies with the same name can arrive together, set by different domains or paths, and the header gives no way to tell them apart beyond ordering. Cookie parsing libraries usually keep the first or the last, which means an attacker who can set a cookie on a sibling subdomain may be able to shadow the one your application reads.

Size matters more than it looks. Every cookie for a matching host is attached to every matching request, including images and scripts, so a few kilobytes of accumulated cookies is a few kilobytes added to hundreds of requests. Serving static assets from a cookieless host is an old technique that still works for exactly this reason.

Because the browser sends whatever matches the host and path, the presence of a cookie proves nothing about who is making the request. Cross-site request forgery works precisely because the browser attaches cookies to a request initiated by someone else's page, which is why session cookies need SameSite and why unsafe methods need an origin check as well.