EC-Council CASE key terms

A structured exercise that identifies assets, entry points, adversaries, and abuse cases before code exists, so that design-level weaknesses are found and mitigated while changes are still cheap.

A mnemonic classifying threats as Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege; each category points to a matching class of security control.

The total set of points where an attacker can interact with or extract data from an application, including network ports, APIs, file uploads, authentication flows, and third-party dependencies.

A description of how a malicious or careless actor misuses a legitimate feature, written from the attacker's viewpoint to expose missing controls during requirements and design reviews.

A defect where untrusted input is concatenated into an interpreter's command, query, or template, letting the attacker change the intended instruction rather than merely supply data.

An attack that gets attacker-supplied script executed in a victim's browser by reflecting, storing, or DOM-injecting unescaped data, enabling session theft and page tampering.

A database call that sends SQL text and values separately so the engine treats user input purely as data, structurally preventing SQL injection regardless of characters in the input.

Checking data at a trust boundary against an allowlist of expected type, length, format, and range, rejecting anything else before the data reaches business logic or interpreters.

Transforming data at the moment it is written into a specific context, such as HTML, attribute, URL, or JavaScript, so metacharacters become inert text instead of executable syntax.

Reducing input to a single standard representation, decoding encodings and resolving path aliases, before validation so that obfuscated payloads cannot slip past filters.

Supplying sequences such as dot-dot-slash so a file reference escapes its intended directory, allowing reads or writes of files outside the application's permitted root.

Testable statements describing what the system must protect and how, expressed as functional controls, quality attributes, and constraints rather than vague aspirations like 'must be secure'.

Concrete, verifiable conditions attached to a user story that state exactly how a security control's correct behavior will be demonstrated and confirmed before the story is considered done.

An external obligation such as a privacy law, payment card standard, or industry regulation that imposes specific, auditable security requirements on the application and its data handling.

Assigning labels such as public, internal, confidential, or restricted to data assets so that protection, retention, and access rules can be applied consistently and proportionately.

Layering independent controls so that failure or bypass of any single safeguard does not by itself expose the asset, buying detection and response time for the remaining layers.

Granting each user, service, and process only the permissions strictly needed for its current task, and for no longer than needed, to limit the blast radius of compromise.

Any line where data or control passes between components of differing trust, such as browser to server or service to database, marking where validation and authentication must occur.

Designing error and exception paths so that a failed check denies access and preserves state integrity, rather than defaulting to an open, permissive, or partially applied condition.

Shipping configuration with the safest settings already active, such as disabled debug modes and forced encryption, so that omissions by administrators do not create exposure.

Weakness arising from default accounts, verbose errors, unnecessary features, permissive headers, or unpatched components left in a deployed environment rather than from flawed code logic.

The process of verifying that a claimed identity is genuine, typically through passwords, tokens, certificates, or biometrics, before any authorization decision is made.

Deciding what an already-authenticated principal may do, enforced server-side on every request against policy rather than relying on hidden interface elements or client-side checks.

Requiring two or more independent evidence types, such as a password plus a hardware key or one-time code, so a single stolen credential is insufficient to gain access.

Automated replay of username and password pairs leaked from other breaches, exploiting password reuse; rate limiting, breach checks, and multi-factor authentication blunt it.

Inferring which accounts exist from differences in login, registration, or password-reset responses and timing, giving attackers a validated target list for later attacks.

An access flaw where a request supplies an identifier for a record and the server returns it without confirming the caller owns or may view that record.

An authorization model assigning permissions to roles and roles to users, simplifying administration and reducing the chance of ad hoc, over-broad grants.

An attack where the attacker plants a known session identifier on the victim, then reuses it after login; rotating the identifier at authentication defeats it.

Stealing or guessing a live session token, often via script injection or an unencrypted channel, and using it to act as the victim without knowing their password.

Issuing a fresh, unpredictable session token whenever privilege level changes, especially at login and logout, so tokens captured earlier become useless to an attacker.

Flags such as HttpOnly, Secure, and SameSite that keep session cookies out of script reach, off plaintext channels, and away from cross-site requests respectively.

A attack that tricks a logged-in victim's browser into sending a state-changing request to a site that trusts the victim's cookies, unless a per-request token or strict SameSite policy blocks it.

Automatic invalidation of a session after a defined period of inactivity or a fixed maximum lifetime, shrinking the window in which a stolen token remains usable.

Storing a slow, salted, one-way digest of each password using a memory-hard algorithm, so that a database leak does not immediately reveal usable plaintext credentials.

A unique random value generated per password and stored alongside its digest, ensuring identical passwords produce different hashes and defeating precomputed lookup tables.

The lifecycle discipline of generating, distributing, storing, rotating, and destroying cryptographic keys in protected stores, so that compromise is bounded and recoverable.

Designing systems so algorithms, key sizes, and providers can be swapped through configuration without rewriting application logic, allowing rapid response to newly broken primitives.

Using a general-purpose pseudo-random generator for tokens, keys, or identifiers, producing predictable values that attackers can reproduce and thereby forge or guess secrets.

Returning generic, non-revealing messages to users while logging rich diagnostic detail server-side, so stack traces, queries, and internal paths never leak externally.

Structured catching and processing of runtime faults so that failures are contained, resources released, and the application continues in a safe, predictable state.

Automated analysis of source, bytecode, or binary without executing it, tracing data flows from sources to sinks to flag dangerous patterns, with results needing triage for false positives.

Testing a running application from the outside by sending crafted requests and observing responses, finding runtime and configuration issues that source inspection may miss.

Instrumenting a running application with agents that observe code execution during functional or automated tests, correlating observed behavior with source locations to reduce noise.

Tracking whether values from untrusted sources reach sensitive sinks without passing through a sanitizer, the core technique behind most static injection findings.

A reported finding that does not represent an exploitable weakness in this context; unchecked, it wastes remediation effort and erodes trust in the testing program.

Identifying third-party libraries and their versions in a build, then matching them against vulnerability and license data to flag outdated or risky dependencies.

Locking builds to exact, verified library versions with recorded hashes, preventing silent adoption of unreviewed or tampered transitive components between releases.

A documented, version-controlled configuration standard for servers, containers, and runtimes, applied and verified at deployment so drift and permissive defaults are caught early.

An HTTP response header restricting which script, style, and network sources a page may load, providing a strong second layer against injected script execution.