A city session cookie is missing the HttpOnly flag. In an XSS discussion, why does that matter?
Select an answer to reveal the explanation.
Short Explanation
HttpOnly is the “scripts keep their hands off this cookie” latch. Without it, a successful XSS can often read the session cookie directly. That flag does not magically invent Secure or kill all JavaScript on the site — it just changes how bad XSS can get for the session.
Full Explanation
Missing HttpOnly on a city session cookie can let malicious script read that cookie if XSS is present, increasing session-theft impact. In XSS discussions, HttpOnly is a defense-in-depth flag that keeps cookie values out of document.cookie for many scripts—important for citizen portal sessions that authorize account actions.
HttpOnly is not about surviving browser upgrades. Missing HttpOnly does not force cookies Secure. HttpOnly does not disable all JavaScript on the origin; it restricts script access to the cookie.
Exam caveat: HttpOnly complements encoding/CSP—it does not make XSS “safe,” but it reduces one common impact path. CPTS answers should pair cookie flags with XSS impact analysis.
Operational check: review Set-Cookie attributes on civic session cookies, enable HttpOnly (and Secure/SameSite as appropriate), retest XSS impact assumptions, and document residual risk if script can still call APIs using the victim’s browser session. Remember HttpOnly does not stop CSRF or credentialed API abuse in the victim browser; keep XSS eradication as the primary city fix. Pair cookie-flag hardening with XSS fixes so city session theft stories shrink on both axes. Cite the control owner in the civic remediation plan.