ISTQB CT-SEC key terms

Testing that evaluates whether a system protects data and services against threats, covering confidentiality, integrity, authentication, authorization, availability, and non-repudiation rather than only functional correctness.

Planning and prioritizing security test effort according to the likelihood and business impact of identified threats, so the highest-exposure assets and attack paths are examined first.

A structured description of assets, entry points, adversaries, and possible attack paths, used to decide which security tests to design and where controls are missing.

The sum of interfaces, inputs, protocols, accounts, and services through which an attacker could interact with or reach a system, used to scope test coverage.

A stated, verifiable expectation about protection, such as authentication strength, encryption of data at rest, logging, or session timeout, that security tests can be designed against.

A use case written from the attacker's viewpoint, describing a hostile goal and the steps to reach it, which is then turned into negative security test cases.

A description of how a system could be misused or harmed by an actor with hostile or careless intent, used alongside normal use cases to derive security test scenarios.

A document defining security test objectives, scope, in-scope assets, techniques, environments, entry and exit criteria, roles, and reporting for a test project or iteration.

An isolated, controlled test setup that mirrors production closely enough for realistic security testing while preventing damage to live data or real users.

Any location where data or commands can cross into a system, such as a web form, API endpoint, file upload, header, or message queue, and therefore a place to test input handling.

Checking that incoming data has the expected type, format, length, and range before processing, tested with malformed, oversized, and boundary inputs to confirm rejection.

A class of attack where crafted input is interpreted as code or commands by a downstream component, as in SQL injection or command injection, tested by submitting hostile payloads.

A vulnerability where attacker-supplied script is stored or reflected into a page and executed in another user's browser, tested by submitting script payloads and checking encoding and output handling.

Removing or neutralizing dangerous characters and constructs from data before it is stored, displayed, or executed, verified by attempting payloads that should be stripped or altered.

Converting data into a safe representation for the context where it is rendered, such as HTML or JavaScript, tested by confirming that injected markup appears as text rather than executing.

Verifying that identity claims are proven as specified, including password policy, multi-factor flows, credential recovery, lockout, and resistance to credential stuffing and replay.

Checking that authenticated users can only perform actions and reach resources their role permits, including tests for privilege escalation and access to other users' data.

The mechanism that decides which subjects may perform which operations on which objects, tested for correct enforcement at every entry point rather than only in the user interface.

Gaining rights beyond those granted, either vertically to a higher role or horizontally to another user's resources, tested by replaying requests with altered identifiers or roles.

How a system creates, maintains, and ends user sessions, tested for token randomness, timeout, invalidation on logout, and protection against fixation and hijacking.

Taking over an active session by stealing or predicting its token, tested by checking cookie attributes, transport protection, and token rotation after login.

Systematically trying many credentials or values until one succeeds, tested by confirming rate limiting, account lockout, and detection of repeated failures.

Exhausting or blocking resources so legitimate users cannot be served, tested in controlled conditions by measuring behavior under high load or resource-heavy requests.

An authorized, goal-driven simulation of an attacker against a defined scope, combining manual skill and tools to find exploitable weaknesses and demonstrate business impact.

Automated probing of systems and components against known weakness signatures and configuration checks, producing candidate findings that require human triage.

Examining source code or binaries without executing them to find insecure patterns such as hard-coded secrets, unsafe APIs, or missing checks, often with high false positive rates.

Testing a running application to observe actual behavior, such as responses to hostile input, and to detect runtime weaknesses that static inspection cannot reveal.

A reported security finding that is not actually exploitable or present in the tested context, requiring analysis before it is accepted as a defect.

A real vulnerability that testing failed to detect, which is more dangerous than a false alarm because it creates false confidence in the system's protection.

Reviewing and classifying reported security findings by validity, severity, exploitability, and business impact to decide what is fixed, accepted, or dismissed.

A flaw in a work product that could weaken protection, recorded with reproduction steps, evidence, severity, and the requirement or control it violates.

The practical ease with which a weakness can be used by an attacker, considering required access, complexity, available tools, and existing compensating controls.

A rating of how damaging a security finding would be if exploited, usually combined with likelihood to set priority for remediation and retesting.

The degree to which security tests exercise specified requirements, identified threats, entry points, and code paths, used to judge confidence in the test result.

The influence of user and operator behavior, habits, workload, and error on security outcomes, tested through usability checks, social engineering scenarios, and review of warning effectiveness.

Manipulating people into revealing information or performing unsafe actions, assessed through authorized simulations and by reviewing processes that rely on human trust.

The extent to which staff recognize threats and follow safe practice, evaluated by targeted exercises and surveys rather than assumed from training completion records.

Management's documented rules for acceptable use, access, data handling, and incident response, which security tests check for existence, clarity, and actual enforcement.

A recognized specification or framework, such as ISO/IEC 27001, OWASP ASVS, or PCI DSS, used to derive security requirements, select controls, and structure test coverage.

Checking that a system and its processes meet obligations from laws, regulations, contracts, or chosen standards, producing evidence that auditors can review.

Protocol that encrypts and authenticates data in transit, tested for correct versions and ciphers, valid certificates, and rejection of insecure fallback.