Interview answer drill

Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow JavaScript mastery study plan Practice more JavaScript interview questions

What are the options (attributes) in a cookie?Frontend interview answer

HighIntermediateJavascript

By FrontendAtlas Team · Updated Apr 10, 2026

Interview focus

This JavaScript interview question tests whether you can explain Cookie options for auth and embeds: SameSite, Secure, HttpOnly, and host-only scope, connect it to production trade-offs, and handle common follow-up questions.

Cookie options for auth and embeds: SameSite, Secure, HttpOnly, and host-only scope explanation without falling back to memorized docs wording
Cookies and HTTP reasoning, edge cases, and production failure modes
How you would answer the most likely JavaScript interview follow-up

Practice more JavaScript interview questions

Interview quick answer

Cookie options are production decisions about auth-cookie hardening, host-only scope, SameSite defaults, cross-site embeds, and which attributes must be set server-side in Set-Cookie.

Full interview answer

The core idea

A cookie is not just name=value. Real behavior is controlled by attributes in the Set-Cookie header: lifetime, which paths/domains can receive it, and how strongly it is protected against client-side attacks and cross-site request abuse.

In interviews, high-quality answers group cookie options into three buckets: lifetime, scope, and security. The production decision is usually whether the cookie is an auth cookie, a low-risk preference cookie, or a cross-site cookie for an embedded widget, affiliate redirect, or third-party sign-in flow. Modern browsers also treat omitted SameSite as a Lax-style default in many cases, so a cookie can appear fine on your own site but still fail in cross-site contexts.

HTTP

Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Attribute	What it controls	Common values	Key note
`Expires`	Absolute expiry date/time	HTTP-date string	Creates persistent cookie until that date.
`Max-Age`	Relative lifetime in seconds	`3600`, `86400`	Often preferred; when both are present, Max-Age takes precedence.
`Domain`	Which hosts receive the cookie	`example.com`	If omitted, cookie is host-only (more restrictive).
`Path`	URL path scope	`/`, `/admin`	Limits sending by path, but is not a security boundary by itself.
`Secure`	Transport requirement	flag	Cookie sent only over HTTPS.
`HttpOnly`	JavaScript access	flag	Blocks `document.cookie` reads/writes for that cookie.
`SameSite`	Cross-site sending policy	`Strict`, `Lax`, `None`	Reduces CSRF risk; `None` requires `Secure`.
`Partitioned`	Storage partitioning for cross-site contexts	flag	Used for CHIPS-style isolation; requires `Secure`.

Cookie attributes define behavior far more than the raw value does.

Lifetime options: Expires vs Max-Age

No Expires/Max-Age means a session cookie (typically removed when browser session ends).

Expires uses an absolute timestamp.

Max-Age uses relative seconds and is less timezone-sensitive.

HTTP

Set-Cookie: theme=dark; Max-Age=2592000; Path=/; SameSite=Lax
Set-Cookie: promo=on; Expires=Wed, 31 Dec 2026 23:59:59 GMT; Path=/

Scope options: Domain and Path

Use the narrowest scope possible. Over-broad cookies increase accidental leakage across subdomains or app sections. If Domain is omitted, the cookie is host-only, which is usually the safer default for session cookies. If Path is omitted, the browser does not default to /; it defaults to the current request path directory, which surprises teams when a cookie is set during /auth/callback or /account/settings and later does not appear on unrelated routes.

HTTP

Set-Cookie: hostOnly=1; Path=/
# No Domain attribute -> only current host receives it

Set-Cookie: shared=1; Domain=example.com; Path=/
# Sent to example.com and subdomains (broader scope)

HTTP

# Response URL: https://app.example.com/account/settings/profile
Set-Cookie: draft=1
# Default Path becomes /account/settings/

Set-Cookie: draft=1; Path=/
# Explicit site-wide scope

Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
# Hardened host-only session cookie

SameSite is where many production bugs show up

Most auth cookies can stay Lax or even Strict, but embedded widgets, third-party sign-in callbacks, payment return flows, and cross-site iframes often need SameSite=None; Secure. A common migration/debug bug is an older cookie config that omitted SameSite; after browsers moved to a Lax-style default, the OAuth callback, payment return, or embedded flow stops carrying the cookie until the attribute is set explicitly.

HTTP

Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Strict
Set-Cookie: app_session=xyz789; Path=/; HttpOnly; Secure; SameSite=Lax
Set-Cookie: support_widget=embed123; Path=/; SameSite=None; Secure; Partitioned

HTTP

# Older config that breaks in some cross-site flows
Set-Cookie: oauth_state=abc123; Path=/auth/callback; Secure

# Explicit fix for third-party sign-in, payment return, or iframe flows
Set-Cookie: oauth_state=abc123; Path=/auth/callback; SameSite=None; Secure

Compatibility note

Older browsers and embedded webviews historically had rough SameSite=None handling, so auth and payment teams should test real clients instead of assuming a desktop Chrome result covers every callback flow.

Security options that matter most

For auth/session cookies, baseline hardening is usually:

HttpOnly to reduce token exposure via XSS.

Secure to avoid plaintext transport.

SameSite policy aligned with your cross-site needs (often Lax or Strict).

For highly sensitive host-only session cookies, prefixes like __Host- and __Secure- add extra deployment constraints that reduce misconfiguration risk. A __Host- cookie must be Secure, must use Path=/, and cannot set Domain, which makes it a strong fit for host-only session cookies.

HTTP

Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Important frontend limitation

document.cookie can set basic attributes like Path, Expires, and SameSite (browser support dependent), but it cannot set HttpOnly.

If you need secure auth cookies, set them server-side via Set-Cookie response headers. Frontend JavaScript also cannot read the Set-Cookie response header directly, so cookie debugging usually happens in DevTools network/storage panels rather than application code.

JAVASCRIPT

// Client-side cookie write (limited control)
document.cookie = 'theme=dark; Path=/; Max-Age=2592000; SameSite=Lax';

// HttpOnly cannot be set from JavaScript.

Use case	Suggested attributes	Why
Session authentication	`HttpOnly; Secure; SameSite=Lax/Strict; Path=/`	Balances usability with strong baseline CSRF/XSS protection.
Cross-site embedded app/session	`SameSite=None; Secure` (+ optional `Partitioned`)	Allows cross-site sending with explicit secure transport.
UI preference cookie	`Max-Age` or `Expires`, narrow `Path`	Persistent behavior without over-scoping sensitive state.

Choose attributes by risk profile, not by habit.

Scenario	SameSite choice	Why
Main-site session cookie	`Lax` (or `Strict` if UX allows)	Keeps normal first-party flows working while reducing cross-site request risk.
Embedded iframe, third-party widget, or cross-site SSO callback	`None; Secure` (+ optional `Partitioned`)	Cross-site delivery requires `None`, and modern browsers require `Secure` with it.
Low-risk preference cookie	Usually `Lax`	Avoid choosing `None` unless the cookie truly needs cross-site sending.

SameSite should follow the actual cross-site behavior your product needs.

Interview one-liner

Cookie options are Set-Cookie attributes that define lifetime, scope, and security; strong answers specifically mention Max-Age/Expires, Domain/Path, and Secure/HttpOnly/SameSite.

Practical scenario
An app stores a login session, a theme preference, and an embedded support widget cookie. The session cookie should stay host-only and hardened, the theme can be broader and persistent, and the embedded widget may need SameSite=None; Secure to work cross-site.

Common pitfalls

Missing Secure or HttpOnly on auth cookies.
Using SameSite=None without Secure (rejected by modern browsers).
Setting overly broad Domain values that expose cookies across subdomains.
Assuming Path alone provides strong security isolation.
Forgetting that many browsers treat omitted SameSite like a Lax-style default.

Trade-off or test tip
Test cookie behavior in same-site navigation, cross-site redirect, embedded iframe context, and HTTPS-only environments to verify attributes behave as intended.

Still so complicated?

Think of cookie attributes like delivery rules on a package: when it expires, which addresses can receive it, and what security checks are required before handoff.