A city admin portal keeps the same session identifier after a user elevates from read-only staff to full administrator. What session hygiene issue should the tester flag?
Select an answer to reveal the explanation.
Short Explanation
Getting a promotion should come with a new badge, not the old visitor sticker. Keeping the same session ID after privilege elevation is classic fixation/elevation hygiene failure. Marketing cookies are not the model here.
Full Explanation
A city admin portal that keeps the same session identifier after a user elevates from read-only staff to full administrator fails session hygiene: identifiers should rotate after login and after privilege elevation to reduce session fixation and stolen-session reuse across privilege boundaries.
Never expiring session identifiers so help desks can replay tickets is poor security guidance. Limiting rotation to anonymous marketing cookies ignores authenticated civic sessions where risk is higher. Privilege elevation does not automatically invalidate CSRF tokens while leaving sessions untouched as a universal rule—both controls need explicit design.
Exam caveat: rotation alone is incomplete without secure cookie flags, idle timeouts, and absolute lifetimes appropriate to municipal admin portals.
Operational check: authenticate as read-only staff, capture the session cookie, elevate privileges within the portal, and verify whether the identifier changes. Recommend forced re-issue of session state on role change and document residual risk if legacy SSO integrations delay rotation. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.