TC-010 - I3 Sensitive client-side storage access
Reading from document.cookie
Context profile
No restrictive Content Security Policy is present. A session-like cookie is readable by JavaScript.
Content Security Policy
No Content-Security-Policy header is sent.
Cookies
| Cookie | Type | HttpOnly | Secure | SameSite |
|---|---|---|---|---|
tc_session | session-like | no | no | Lax |
Cookie values are placeholders and are never collected. Of these attributes only HttpOnly decides whether JavaScript can read the cookie.
Test case
The script reads document.cookie, the JavaScript-visible cookie store. The output
below shows what JavaScript can read; switch the context profile above to compare. The values
are placeholders - what matters is which cookies are readable, not their contents.
document.cookie
What to observe
- C0: the session-like cookie
tc_sessionis readable, because it has noHttpOnlyattribute. This is the case where the finding is most relevant. - C1: the output is empty. The same
tc_sessioncookie is present (see the cookie table above) but markedHttpOnly, so JavaScript cannot read it. - C2: only
tc_ui_themeis readable - a non-session cookie. There is no session-like cookie to expose.
The static finding is the same in all three profiles - the read of document.cookie. The context decides how relevant it is: a JavaScript-readable session-like cookie (C0)
makes the finding more urgent; a protected (C1) or absent (C2) session cookie makes it
lower-risk. The finding is never proof that the cookie itself is sensitive.
Expected outcome
- Purpose
- Check whether JavaScript access to cookies is reported.
- Expected finding
- Finding on document.cookie.
- Expected interpretation
- More relevant when cookies look session-related or are JavaScript-readable; no proof that the cookie itself is sensitive.
- Expected priority
- Medium to high (C0)
- Notes
- Cookie values themselves are not collected or displayed.
Expected priority is shown for the active context profile. Other profiles for this case: C0, C1, C2.