EC-Council CASE common mistakes
EC-Council CASE · Understand the traps and how to avoid them.
When asked to identify the vulnerability class in a code snippet, candidates pattern-match on a single keyword (for example seeing the word 'password' and answering 'hardcoded credentials') instead of tracing how untrusted input reaches a dangerous sink.
Exam stems often show short fragments where the surface vocabulary is misleading; candidates who studied by memorizing vulnerability names rather than data-flow reasoning pick the label the words suggest rather than the flaw the code actually contains.
What to do instead
For every code-based item, explicitly annotate the snippet: mark sources (request parameters, headers, cookies, file uploads), transformations (encoding, validation, sanitization), and sinks (SQL query, OS command, HTML output, file path, deserializer). Choose the answer that matches the actual source-to-sink path, and reject labels that require a precondition the snippet does not show.
Candidates treat threat modeling as a documentation deliverable and answer questions about it by describing a list of threats, rather than identifying the specific structured technique the question is testing (for example confusing STRIDE categories with attack trees or with DREAD scoring).
Threat modeling appears in both the threats domain and the requirements/design domains, so candidates blur the boundaries and answer with generic 'identify and mitigate risks' language that does not match the technique named in the stem.
What to do instead
Build a one-page reference that separates the artifacts: STRIDE is a per-element categorization of threat types; attack trees decompose a goal into sub-goals; DREAD (or a similar scheme) ranks risk; misuse/abuse cases capture attacker goals as requirements. When a stem names a technique, answer within that technique's vocabulary and do not substitute a different framework.
Candidates answer secure design questions by picking the control that mitigates the symptom (for example adding input validation) when the stem is asking for an architectural control that removes the whole class of weakness (for example eliminating the dangerous API or applying least privilege to the component).
Input validation is the most familiar control, so it becomes a default answer. Candidates under-weight the design-domain expectation that controls be placed at the right layer with defense in depth and trust-boundary reasoning.
What to do instead
Before answering, locate the trust boundary the stem describes. If the question is about architecture, prefer structural controls (segmentation, least privilege, safe-by-default APIs, output encoding at the rendering layer, centralized authentication) over point fixes. Reserve 'validate input' answers for items that explicitly ask about the input-handling layer.
Candidates equate input validation with sanitization and choose 'sanitize the input' as the fix for injection flaws, rather than identifying context-appropriate output encoding or parameterization as the correct control.
The words validation, sanitization, filtering, and encoding are used loosely in practice, and candidates carry that looseness into the exam, where the distinction between rejecting bad input and rendering data safe for a specific interpreter is precisely what is being tested.
What to do instead
Memorize the pairing: allow-list validation constrains what input is accepted; parameterized queries and prepared statements keep data out of the SQL grammar; output encoding is context-specific (HTML body, attribute, JavaScript, URL, CSS). For each injection variant, state the sink context first, then select the control that matches that context.
Candidates conflate authentication and authorization in scenario questions, answering 'add multi-factor authentication' when the stem describes a user reaching another user's records, or answering 'check permissions' when the stem describes credential stuffing.
Both controls are frequently implemented together, and the exam deliberately places them in the same scenario so that the candidate must decide whether the failure is about proving identity or about enforcing access to a resource.
What to do instead
Classify the failure in one sentence before reading the options: 'Who are you?' failures are authentication (credential handling, MFA, lockout, password storage); 'What may you do?' failures are authorization (missing object-level checks, privilege escalation, forced browsing, role confusion). Then eliminate every option that addresses the other question.
Candidates recommend a specific algorithm by reputation alone (for example 'use AES' or 'use SHA-256') without addressing mode of operation, IV/nonce handling, key management, or password-hashing requirements.
Algorithm names are memorable and heavily covered in study material, while mode, nonce reuse, and key lifecycle are easy to skim. Exam items often present correct algorithms used incorrectly, so the reputation answer is the trap.
What to do instead
For every cryptography item, check five things in order: purpose (confidentiality, integrity, password storage, key exchange), algorithm and parameters, mode and IV/nonce uniqueness, key generation and storage, and comparison/verification behavior. Choose the option that fixes the actual parameter problem, and remember that general-purpose hashes are not acceptable for password storage.
Candidates treat session management as a single 'use HTTPS and secure cookies' answer and miss the specific lifecycle defect in the stem, such as a session identifier that is not rotated after authentication or a logout that clears the cookie without invalidating server-side state.
Cookie flags are the most rehearsed part of this domain, so they crowd out the lifecycle concepts: creation, rotation on privilege change, idle and absolute timeout, and server-side invalidation.
What to do instead
Walk the session lifecycle for each item: issuance (randomness and length), transmission (Secure, HttpOnly, SameSite), fixation defense (new identifier at login and privilege change), expiration (idle and absolute), and termination (server-side invalidation on logout and on password change). Name the lifecycle stage in the stem before choosing.
Candidates answer error-handling questions by choosing 'show a generic error page' and stop there, missing the paired requirement to log detailed diagnostic information securely and to fail closed rather than open.
The visible user-facing half of error handling is emphasized in study material, while the logging, fail-safe, and information-leakage halves are treated as afterthoughts, so answers that address only the display layer feel complete.
What to do instead
For each error-handling item, confirm three properties: the user sees a non-revealing message with a correlation identifier; the server logs detail without secrets or full stack traces exposed to the client; and the failure path denies access rather than granting it. Prefer options that satisfy all three over options that only fix the display.
Candidates cannot distinguish what SAST and DAST each can and cannot find, so they select SAST for a runtime configuration flaw or DAST for a vulnerability in code paths that are hard to reach through the UI.
Both are 'security testing' in casual usage, and candidates memorize tool names without the coverage model: SAST reads code without executing it, DAST exercises a running application from the outside.
What to do instead
Anchor on the axis each tool operates on: SAST sees source, sinks, and data flow but not runtime state or environment; DAST sees real requests and responses but not internal code paths or unreachable branches. When a stem describes a defect tied to runtime behavior or deployed configuration, favor DAST or configuration review; when it describes a flaw in code logic, favor SAST. Note that neither replaces manual review or threat modeling.
Candidates treat secure deployment as a one-time hardening checklist and pick answers that ignore environment separation, secrets management, dependency lifecycle, and post-deployment monitoring.
Deployment content is often studied as a list of server settings, so candidates under-weight the pipeline concerns that the exam tests: how secrets reach the runtime, how builds are promoted between environments, and how vulnerabilities in third-party components are tracked after release.
What to do instead
Frame deployment answers around four questions: are secrets injected at runtime rather than baked into artifacts; are environments and credentials separated so production data and keys never reach lower environments; are dependencies inventoried and patched on an ongoing basis; and is there runtime detection and logging to catch exploitation. Choose the option that addresses the lifecycle concern named in the stem.