ISTQB CT-SEC study materials
ISTQB CT-SEC study resources

ISTQB CT-SEC: Security Test Performance

ISTQB CT-SEC · Work through your exam, one topic at a time.

All guide sections

Security Test Performance

Security Test Performance

This domain tests execution: choosing an approach, staying inside the rules of engagement, finding real weaknesses, and producing evidence a developer can act on.

Core rules

  • Knowledge level drives technique. Black-box: no internal knowledge. Grey-box: partial knowledge such as valid credentials or architecture diagrams. White-box: source code and design. Penetration testing is goal-directed and human-led; vulnerability scanning is automated, broad and shallow; the two are complementary.
  • Typical phases: reconnaissance and enumeration, scanning, vulnerability analysis, controlled exploitation, evidence capture, reporting, retesting.
  • Rules of engagement are mandatory: written authorization, in-scope hosts and accounts, time windows, forbidden techniques (denial of service, data destruction), stop conditions, escalation contact and data-handling rules.
  • Recurring web weaknesses to probe: injection, broken authentication and session management, cross-site scripting, cross-site request forgery, broken access control and insecure direct object references, security misconfiguration, sensitive data exposure, and vulnerable components.
  • Capture reproducible evidence (request and response, timestamps, account used) without copying real personal data; prefer synthetic test data.

Worked example

A tester with a valid low-privilege account requests a profile endpoint with user id 1001, then changes it to 1002. The response is 200 with another customer's data. Repeating the request anonymously returns 401, so authentication is enforced but object-level authorization is not. The finding is recorded as broken access control (horizontal privilege escalation), high severity, with both request and response pairs as evidence. The reasoning: grey-box because credentials were used, and the anonymous control request distinguishes an authentication failure from an authorization failure.

Traps

Treating a scanner's severity label as business risk; exploiting beyond the agreed scope; testing production without approval; reporting a finding that cannot be reproduced; expecting tools to find business-logic flaws; closing a finding without retesting the fix.