Cookie security and scope

Secure, HttpOnly and SameSite protect different properties.

UnderstandStudy an examplePractise

Understand the concept

Cookies are automatically attached to matching requests. Secure restricts transport; HttpOnly prevents script reads, but does not stop all actions by an XSS-compromised page. SameSite controls cross-site sending, and None requires Secure.

Omitting Domain yields host-only scope. Path is a routing filter, not a strong authorisation boundary. Supporting browsers enforce __Host- prefix rules including Secure, Path=/ and no Domain.

Use carefully scoped session mechanisms rather than exposing secrets. Set-Cookie is not an ordinary script-readable Fetch response field. Browser storage and cross-site policies can reject cookies even when server headers appear correct.

WHEN TO USE IT

Store and diagnose admin sessions correctly.

COMMON PITFALL

Assuming HttpOnly eliminates XSS or CSRF.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

Set-Cookie: theme=dark; Path=/; SameSite=Lax

A non-sensitive preference example.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

Does HttpOnly prevent a script from acting as the user through Fetch?

Show the solution and explanation

Worked solution

Read protection ≠ action protection

Not by itself; prevent XSS and enforce server authorisation.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.