Insecure Cookie Attributes
detect, understand, remediate

Secure

Restricts the cookie to HTTPS transport. Without Secure, the cookie can be sent on the first plaintext HTTP request and stolen by a network attacker before HSTS upgrades the connection.

HttpOnly

Hides the cookie from document.cookie and any client-side script. Without HttpOnly, an XSS payload anywhere on the origin can read the session cookie directly.

SameSite

Controls whether the browser sends the cookie on cross-site requests. Strict blocks all cross-site sends, Lax allows top-level GET navigations, None requires Secure and is the only attribute that permits cross-site cookies.

Domain and Path

Decide which hosts and URL paths receive the cookie. A Domain set to the registrable domain rather than the exact host lets every subdomain read and write the cookie, including hosts you do not control.

__Host- and __Secure- prefixes

__Host- forces Secure, Path=/, no Domain attribute, and same-origin write. __Secure- forces Secure. Prefixes are the browser-enforced way to make attribute requirements non-overridable.

Expires and Max-Age

Decide how long the cookie persists on disk. A session cookie that becomes a multi-year persistent cookie outlives the user, the device handover, and the credential rotation it was supposed to track.

Partitioned (CHIPS)

Binds a third-party cookie to the top-level site. Without Partitioned, third-party cookies are increasingly blocked by browsers, breaking embedded flows; with Partitioned they survive without becoming a tracking signal.

Priority and SameParty (Chrome-only)

Browser-specific hints. Do not depend on them for security; they affect eviction order and first-party-set scoping rather than confidentiality or integrity.

Framework defaults

Many web frameworks ship Set-Cookie defaults that omit HttpOnly and SameSite, or set Secure only in production. A misconfigured environment flag in staging leaks the same code path into production cookies.

Reverse proxy or load balancer rewriting

A proxy that terminates TLS may strip the Secure flag if the upstream service believes it is on HTTP. The cookie becomes visible to plaintext clients without any application code change.

Domain set wider than intended

Teams set Domain to the registrable domain to support SSO across subdomains, then never narrow it after consolidation. The wider scope outlives the original requirement.

Library upgrades that flip defaults

A framework or middleware upgrade can flip a default attribute (SameSite, Path, Domain) without surfacing in the release notes. Cookie attribute regression is one of the easiest defaults to miss.

Mixed authentication strategies

Teams that move from session cookies to bearer tokens often leave the legacy cookie in place with weak attributes; the unused cookie remains exploitable until it is removed.

Third-party SDK Set-Cookie

Analytics, A/B testing, and customer support widgets set cookies through their own JavaScript. The first-party application owns the origin but not the attributes the SDK chooses.

Automated detection

• SecPortal's external scanner records every Set-Cookie attribute from every scanned response and flags missing Secure, HttpOnly, SameSite, and prefix protections
• Authenticated scanning follows the login flow and inspects the post-authentication cookie set, including SSO and remember-me cookies that only appear after a real session begins
• Continuous monitoring re-scans on a defined cadence so a framework upgrade or proxy change that quietly weakens attributes is caught against the previous baseline
• Code scanning against connected repositories flags Set-Cookie call sites and framework cookie configuration that omits attributes

Manual testing

• Inspect Set-Cookie response headers in browser developer tools (Network tab) for every cookie set during login, password reset, MFA enrolment, and logout
• Run document.cookie in the console after logging in; if the session cookie appears, HttpOnly is missing
• Force an HTTP request to the origin and confirm the session cookie does not ship over plaintext; verify HSTS is present so the first request is protected even before the cookie is set
• Trigger a cross-site GET (via an attacker page) and confirm the session cookie is not sent because of SameSite=Lax or Strict
• Try to set or overwrite the session cookie from a sibling subdomain to validate that Domain is not scoped too broadly

External scan attribute capture

Every external scan records the Set-Cookie attributes returned by the scanned origin. Missing Secure, HttpOnly, SameSite, and prefix protections are surfaced as findings against the scanned host, with the full response header preserved as evidence on the finding record.

Authenticated scan post-login cookies

Authenticated scanning carries the configured login flow forward and inspects cookies that only appear after authentication (session, SSO, remember-me, MFA). The post-login cookie set is the highest-impact attribute surface and the one external scanning cannot reach.

Code scanning against the framework configuration

Code scanning across connected repositories flags Set-Cookie call sites and framework cookie configuration that omit attributes, so the fix lands at the source rather than at the perimeter.

Retest after the fix ships

Once the attribute change deploys, a targeted retest verifies the new Set-Cookie response and closes the finding with the post-fix evidence attached. Continuous monitoring then re-checks on the defined cadence to catch regressions.