A library XSS finding only triggers in an obsolete browser feature few patrons still use. How should the tester frame impact?
Select an answer to reveal the explanation.
Short Explanation
A leaky faucet in a locked basement still leaks — you just say so honestly. Obscure XSS belongs in the report with realistic likelihood tied to who still uses that path, not as instant database RCE and not swept under the rug.
Full Explanation
When a library XSS finding triggers only via an obsolete browser feature few patrons still use, impact framing must stay honest: report the issue with likelihood tied to the client's real user base, cookie flags (HttpOnly, Secure, SameSite), CSP, and browser controls—neither inflate nor hide it.
Marking every XSS as critical database RCE is typically inaccurate. Omitting obscure-trigger findings entirely hides residual risk leadership should weigh. Claiming identical impact for HttpOnly session cookies versus cookie-less apps ignores how session theft changes severity.
Exam caveat: obsolete vectors can still matter for internal admin browsers or long-lived kiosk images; calibrate to evidence, not fear or dismissiveness.
Operational check: document the exact trigger conditions, estimate affected patron and staff browser populations with the library, note cookie and CSP mitigations, and assign severity accordingly. Offer remediation that removes the sink even if likelihood is currently low. 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.