Cookie security attributes
Cookie security attributes are the flags a server sets alongside a cookie to constrain how the browser stores and sends it. In application security the ones that matter are Secure, HttpOnly and SameSite, plus the Domain and Path scope and the __Host- and __Secure- name prefixes that make the scope enforceable.
Each attribute answers a different question. Secure decides whether the cookie may travel over plain HTTP. HttpOnly decides whether script can read it, which is what limits session hijacking after a cross-site scripting flaw. SameSite decides whether the cookie is attached to requests initiated by other sites, which is the browser level part of the answer to cross-site request forgery. Domain and Path decide which hosts and routes see the cookie at all.
The failures we see are rarely a missing flag on the session cookie, because frameworks set those now. They are in scope. A cookie issued for the parent domain is readable and writable by every subdomain, including the marketing site on a shared platform and the one nobody has patched, so a weakness anywhere in the estate becomes a weakness in the application. The __Host- prefix exists precisely to make that impossible, and it is almost never used.
What we record in a report is the full Set-Cookie header for every cookie that carries state, not just the session one, along with the host that issued it. Anti forgery tokens, remember me tokens and impersonation cookies are the ones that turn up misconfigured. This is a standing item in the web application testing where every Set-Cookie header is reviewed.