Cookie Flags Checklist for Client Websites: Secure, HttpOnly, and SameSite

A cookie flags checklist helps agencies review whether visible Set-Cookie headers include attributes such as Secure, HttpOnly, and SameSite where appropriate. The key phrase is "visible": a passive public check can only review cookies returned in the public response being checked, not cookies created later by JavaScript, consent tools, checkout flows, or logged-in pages.

This tool checks public trust signals only. It is not a security audit, vulnerability scan, malware scan, or compliance check.

Use the Client Website Trust Check to review visible cookie flags as part of a public trust-signal pass. Use the free 10-domain agency audit when the client conversation expands to SSL, DNS, domain expiry, CAA, and email-authentication signals across multiple domains.

Quick answer: cookie flags checklist

For agencies, a cookie flags checklist should:

• Check whether the public response sends Set-Cookie headers.
• Record visible cookie names.
• Review whether relevant cookies include the Secure attribute.
• Review whether relevant cookies include HttpOnly.
• Review whether relevant cookies include SameSite.
• Separate session cookies from preference or analytics cookies.
• Avoid overclaiming when cookies are set after JavaScript, consent, or login.

Cookie interpretation is context-dependent. A missing flag on a session cookie may need developer review. A missing flag on a simple preference cookie may require different handling.

What Set-Cookie headers show

Set-Cookie headers are sent by a server to ask the browser to store a cookie. MDN's Set-Cookie reference documents common attributes including Secure, HttpOnly, and SameSite.

For agency QA, Set-Cookie headers can reveal useful public website posture signals:

• Does the homepage set cookies before consent?
• Are session-style cookies visible?
• Do visible cookies include expected attributes?
• Are there third-party or platform cookies that need owner review?

This is a header review, not a full privacy or legal review.

Secure cookie flag

The Secure attribute tells browsers to send the cookie only over HTTPS. For cookies associated with sessions or sensitive app behavior, agencies should expect the developer to review whether the attribute is present.

In client reports, keep the wording technical:

• "Secure attribute detected."
• "Secure attribute not detected on visible cookie; developer should review."

Do not turn the attribute into a broad claim about the whole website.

HttpOnly cookie flag

HttpOnly tells browsers that client-side scripts should not access the cookie. It is commonly expected for session cookies and other cookies that should be handled by the server.

Not every cookie needs HttpOnly. A preference cookie that JavaScript must read may intentionally omit it. The agency should distinguish cookie purpose before recommending changes.

SameSite cookie flag

SameSite controls when cookies are sent with cross-site requests. Common values are Lax, Strict, and None. If SameSite=None is used, modern browsers generally expect the Secure attribute as well.

Agencies should flag missing or surprising SameSite values for developer review, especially on session-style cookies. The correct value depends on login flows, embeds, checkout, subdomains, and third-party integrations.

Cookie flag review table

| Cookie flag | What it indicates | When it matters | Agency review note | |---|---|---|---| | Secure | Cookie should travel only over HTTPS | Session, authentication, payment, app cookies | Ask developer to review if absent on important visible cookies | | HttpOnly | JavaScript should not read the cookie | Server-managed session cookies | May be intentionally absent for preference cookies | | SameSite=Lax | Cookie is limited in many cross-site contexts | Common baseline for many first-party cookies | Confirm login and payment flows still work | | SameSite=Strict | Cookie is more limited cross-site | Sensitive app flows, but can affect navigation | Needs product testing | | SameSite=None | Cookie can be sent cross-site | Embeds, third-party contexts, some SSO flows | Should be reviewed with Secure and integration context |

Why cookie flags are context-dependent

Cookie flags depend on what the cookie does. A session cookie, consent preference, A/B testing cookie, analytics cookie, ecommerce cookie, and embedded widget cookie can each need different attributes.

Agencies should avoid one-size-fits-all recommendations. The practical review is:

• Identify visible cookies.
• Guess purpose only when obvious.
• Ask the owner to confirm important cookies.
• Route missing attributes to a developer when the cookie appears session-like.

Common cookie review findings

Common findings include:

• No visible Set-Cookie headers on the checked response.
• Visible cookie missing Secure.
• Visible cookie missing HttpOnly.
• Visible cookie missing SameSite.
• SameSite=None present without expected context.
• Cookies set by a platform, CDN, consent tool, or analytics service.
• Cookies only appear after JavaScript or consent.

Each finding needs context before it becomes a client-facing action.

First-party vs third-party cookies

First-party cookies belong to the site being visited. Third-party cookies or embedded-service cookies may be set by another domain or through scripts and frames. A passive public response check may not see many third-party cookies because they are created after browser rendering or user interaction.

If a client has heavy embeds, ads, analytics, or checkout tools, browser-based QA may be needed separately.

Session cookies vs preference cookies

Session cookies usually deserve closer review because they may represent logged-in state or server-managed application behavior. Preference cookies may store UI choices, consent state, language, region, or dismissed banners.

This distinction affects HttpOnly. A server-managed session cookie may be expected to use it. A JavaScript-readable preference cookie may intentionally omit it. The agency should not label every missing HttpOnly attribute the same way.

Cookie flag review checklist

• Check the public production URL.
• Record visible Set-Cookie headers.
• Identify likely session cookies.
• Identify likely preference or consent cookies.
• Review Secure on relevant cookies.
• Review HttpOnly on server-managed cookies.
• Review SameSite values.
• Note cookies that may be set after JavaScript, consent, or login.
• Assign ambiguous findings to the developer or platform owner.
• Keep client-facing language factual and context-aware.

What Client Website Trust Check can report

The Client Website Trust Check can report visible cookie flag signals from the public response being checked. It can identify missing or present attributes on cookies it sees.

That makes it useful for a practical handover check, especially when paired with header hygiene, HTTPS/TLS, CAA, robots.txt, sitemap.xml, and security.txt.

What a passive public check cannot know

We make a small number of public requests to the domain you submit. We do not log in, scan plugins, or crawl the site.

Some signals are only visible if the site responds normally on the public URL being checked. Sites behind WAFs, geo-blocks, or aggressive bot protection may show unknown rather than missing.

A passive public check cannot see cookies set after JavaScript execution, consent interaction, login, checkout, embedded iframe behavior, or route-specific app flows. For CertPilot's public-check limitations, see the methodology page.

When to involve a developer

Involve a developer or platform owner when:

• A visible session-style cookie lacks expected attributes.
• SameSite=None appears without clear reason.
• Cookie behavior differs between apex and www.
• Cookies are set by a CDN, host, or application framework.
• A cookie appears before consent and the client needs a separate legal or privacy review.
• The result affects login, checkout, SSO, forms, or embeds.

Related Resources

• Website trust signals checker
• Website header checklist for agencies
• Client website trust checklist
• Client website health report template

Frequently Asked Questions

What is a cookie flags checklist?

A cookie flags checklist is a practical review of visible Set-Cookie headers and attributes such as Secure, HttpOnly, and SameSite. Agencies use it to document public cookie signals during client website QA, then route important or ambiguous findings to a developer or platform owner.

Should every cookie have HttpOnly?

No. HttpOnly is commonly expected for server-managed session cookies, but some preference, consent, or UI cookies may need to be read by JavaScript. Agencies should identify the likely cookie purpose before recommending changes.

Why does SameSite need context?

SameSite affects cross-site cookie behavior. A stricter value may be appropriate for some cookies but can affect SSO, checkout, embeds, or third-party integrations. The correct value depends on the site's user flows, so agencies should flag unclear settings for developer review.

Can a passive check see all cookies?

No. A passive public check can only see cookies returned in the checked public response. It cannot see cookies created after JavaScript runs, after consent, after login, during checkout, or inside browser-only interactions. Treat the result as a visible-response review.

What does it mean if no Set-Cookie headers are visible?

It means the checked response did not send visible Set-Cookie headers. That may be normal for a static page or for a site that sets cookies later in the browser. It is not a complete statement about the entire site.

Who should fix cookie flag findings?

Usually the application developer, platform owner, host, or vendor that sets the cookie. The agency should provide the cookie name, observed attributes, checked URL, and why the cookie needs review. Legal or privacy questions should go through the client's appropriate advisor.