GCIH Web App Injection Attacks Practice Question
An incident handler is analyzing a severe Cross-Site Scripting (XSS) incident where malicious JavaScript stole administrator session cookies. Which TWO of the following defensive configurations and practices effectively mitigate session theft risks via XSS?
⚠ Common exam trap
Many test-takers select encryption mechanisms or HTTPS enforcement thinking they protect session cookies from XSS, forgetting that encryption only secures data in transit.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set the HttpOnly flag on all sensitive authentication and session cookies.
Applying the HttpOnly flag prevents client-side scripts from accessing sensitive cookies via document.cookie, stopping direct session hijacking even if XSS exists. Combining this with a strong Content Security Policy restricts where scripts load and execute, providing defense-in-depth against malicious script injection attempts.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Set the HttpOnly flag on all sensitive authentication and session cookies.
Why this is correct
Enabling the HttpOnly attribute instructs browsers to restrict cookie access exclusively to the HTTP protocol. Consequently, malicious JavaScript running inside an exploited browser session cannot read or exfiltrate the session identifier via document.cookie properties during an XSS attack.
- ✗
Require strict TLS 1.3 encryption for all incoming and outgoing web traffic sessions.
Why it's wrong here
TLS encryption secures confidentiality and integrity while data traverses the network channel between client and server. However, it provides absolutely no defense against Cross-Site Scripting because the malicious script executes locally within the browser after decryption has already occurred.
- ✓
Implement a robust Content Security Policy (CSP) header restricting script execution sources.
Why this is correct
A well-configured Content Security Policy whitelist restricts the domains and inline sources from which JavaScript can execute. This blocks unauthorized malicious script payloads injected by attackers even if the application suffers from underlying reflected or stored XSS vulnerabilities.
- ✗
Store user session tokens inside local storage rather than standard browser cookies.
Why it's wrong here
Local storage is directly accessible to any JavaScript running on the page, making it significantly more vulnerable to theft via XSS than HttpOnly cookies. Moving tokens to local storage actually increases exposure because the browser offers no attribute equivalent to HttpOnly for web storage APIs.
- ✗
Encode all dynamic output using generic HTML entity encoding routines on the server side.
Why it's wrong here
While HTML body encoding helps prevent standard reflected XSS, it is insufficient on its own for complete mitigation across complex contexts like attributes or script blocks. Furthermore, it does not protect session tokens directly if scripts manage to execute via other bypass vectors or missing flags.
About these practice questions
This GCIH question is part of Courseiva's 322-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GCIH practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCIH exam.