Courseiva
Software Development SecuritymediumMultiple SelectObjective-mapped

CISSP Software Development Security Practice Question

During a security audit of a web application, the following issues are found: (1) Session tokens are included in URLs, (2) The application does not invalidate session tokens after logout, and (3) Session tokens are predictable. Which THREE of the following controls are most appropriate to address these issues?

⚠ Common exam trap

ISC2 often tests the misconception that IP binding is a strong session management control, but in reality it is fragile and not a primary defense against session token exposure, predictability, or improper invalidation.

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

Store session tokens in cookies with Secure and HttpOnly flags

Option B is correct because storing session tokens in cookies with Secure and HttpOnly flags addresses the issue of tokens being included in URLs by keeping them out of URLs and providing additional protections. Option C is correct because invalidating session tokens on logout and setting short expiration times directly addresses the lack of invalidation. Option D is correct because using a cryptographically secure random number generator directly addresses the predictability of session tokens. Option A is incorrect because regenerating session tokens after login is primarily a control against session fixation, not directly addressing predictability, exposure in URLs, or lack of invalidation. Option E is incorrect because IP address binding is fragile and does not protect against token exposure or poor invalidation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Regenerate session tokens after login

    Why it's wrong here

    Regenerating session tokens after login is primarily used to prevent session fixation attacks, where an attacker sets a known session ID before authentication. It does not directly address session token predictability, exposure in URLs, or absence of logout invalidation, making it less appropriate for the listed issues.

  • Store session tokens in cookies with Secure and HttpOnly flags

    Why this is correct

    Storing session tokens in cookies with the Secure flag ensures they are only transmitted over encrypted HTTPS connections, preventing passive network eavesdropping. The HttpOnly flag prevents client-side scripts, such as JavaScript, from accessing the cookie's content, significantly mitigating the risk of session token theft via Cross-Site Scripting (XSS) attacks. These flags collectively enhance the confidentiality and integrity of session tokens during transit and storage.

  • Invalidate session tokens on logout and set short expiration times

    Why this is correct

    Invalidating session tokens on logout ensures that once a user explicitly ends their session, the associated token becomes immediately unusable, preventing an attacker from replaying a stolen token to regain access. Additionally, setting short expiration times for session tokens limits the window of opportunity for an attacker to exploit a compromised token, as it will automatically become invalid after a brief period, even if not explicitly logged out. This dual approach significantly reduces the risk of session hijacking and unauthorized access.

  • Use a cryptographically secure random number generator for token generation

    Why this is correct

    Using a cryptographically secure random number generator (CSPRNG) for token generation is crucial because it produces session tokens that are statistically unpredictable and computationally infeasible to guess or derive. This directly addresses the predictability issue, making it extremely difficult for attackers to enumerate valid session IDs through brute-force or pattern analysis. A strong, unpredictable token is a fundamental defense against session hijacking attempts based on token guessing.

  • Implement IP address binding for session tokens

    Why it's wrong here

    Implementing IP address binding for session tokens attempts to tie a session to a specific client IP address, but it introduces significant usability issues for legitimate users whose IP addresses may change during a session (e.g., mobile users, VPNs, or users behind load balancers). Furthermore, this control can often be bypassed by sophisticated attackers using proxies, botnets, or by compromising the user's local network, making it an unreliable and often counterproductive security measure.

About these practice questions

This CISSP question is part of Courseiva's 747-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 →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CISSP practice question is part of Courseiva's free ISC2 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 CISSP exam.