Two cookie-name prefixes carry built-in browser-enforced semantics (RFC 6265bis):
__Secure- -- the cookie must have the Secure flag. Browsers reject any Set-Cookie for a __Secure--prefixed name without it. Use when you want the cookie to be HTTPS-only and you want a syntactic guarantee that the security attribute hasn't been forgotten.
__Host- -- stricter. The cookie must have:
- The Secure flag
Path=/- NO Domain attribute (so it's bound to the exact origin, not a parent domain)
__Host- is the right choice for session cookies, CSRF tokens, and anything else you don't want to leak across subdomains. The browser-enforced binding makes subdomain takeovers (one of the highest-impact common attacks) ineffective against the cookie.
Common bug: setting a __Host- cookie with Path=/app or Domain=.example.com -- the Set-Cookie is silently rejected (no error, no log, just no cookie). Login flows then mysteriously fail to remember the session. The fix is to either drop the prefix or fix the attributes; there's no "force the browser to accept it" option.
Both prefixes are widely supported (Chrome 49+, Firefox 50+, Safari 12+); modern apps should default to __Host- for the most sensitive cookies.