CAP-C01 common mistakes
CAP-C01 · Understand the traps and how to avoid them.
When asked to identify a web vulnerability from a described request/response, the candidate names the class of bug (e.g., 'SQL injection') but cannot state the specific injection point or the parameter/value that proves it, so a scenario asking 'which parameter is exploitable' is answered by category instead of by evidence.
Candidates memorize vulnerability taxonomy and pattern-match keywords like 'error' or 'quote' without practicing the habit of tracing tainted input from source to sink in the provided text.
What to do instead
For every practice scenario, write a one-line chain: input field -> transport (query/body/header/cookie) -> sink (query string, template, redirect, file path) -> observable effect. Answer questions from the chain, not from the label.
Treats all reflected/stored input as equally severe and cannot distinguish a genuine cross-site scripting finding from a case where the value is safely encoded or placed in a non-executable context, so the candidate over-reports or under-reports the same payload depending on context.
Candidates learn payload strings (script tags, event handlers) without learning HTML/attribute/JS/URL context rules, and exam items deliberately vary the output context.
What to do instead
Drill context mapping: for each sink, identify whether output lands in element text, an attribute, a URL, or a script block, and state which encoding neutralizes it. Practice judging 'is this exploitable here' before choosing an answer.
On internal network scenarios, the candidate jumps straight to a single exploit or tool output and skips the enumeration/segmentation reasoning (what hosts are reachable from the current foothold, which service is the pivot), so questions about the next best pivot or reachable target are answered from the attacker's original position.
Candidates practice tool commands in isolation and never build a mental map of network position, trust boundaries, and reachability from a given host.
What to do instead
For each internal-network item, first restate the current position (which host/subnet the attacker controls) and list reachable services before evaluating options. Reject any answer that assumes reachability not established by the scenario.
Confuses authentication weaknesses with authorization weaknesses on internal services (e.g., labels a missing access check on an admin endpoint as 'weak credentials'), producing a plausible-sounding but wrong root cause.
Both appear as 'I got in without proper permission', and candidates answer by symptom rather than by the control that failed.
What to do instead
Ask 'did the system verify who I am, or what I am allowed to do?' Map each finding to exactly one control (identity proof vs. permission check vs. session handling) and justify the choice in one sentence.
On external perimeter questions, the candidate recommends blocking or 'hardening' a service that the business scenario requires to stay exposed, instead of choosing a compensating control (segmentation, WAF rule, authentication layer, rate limiting) that preserves the requirement.
Candidates default to 'disable it' as the safest answer and ignore the stated business constraint embedded in the scenario.
What to do instead
Before answering, extract the explicit requirement (must remain public, must support legacy clients, etc.) and eliminate any option that violates it. Then pick the control that reduces risk while satisfying the requirement.
Misreads TLS/certificate and DNS-related external findings: treats an expired or mismatched certificate as a confidentiality break, or treats a DNS record pointing to a third party as proof of compromise, rather than describing the actual impact (availability/trust warning vs. takeover precondition).
Candidates conflate 'something is wrong with the certificate/DNS' with 'data is exposed', because they memorize severity labels instead of the mechanism.
What to do instead
For each finding, state the mechanism in one line (what breaks, for whom) and the concrete impact. If the impact cannot be stated without assuming facts not in the scenario, the option is wrong.
On mobile application items, the candidate evaluates only the app binary and ignores the platform's inter-process and storage model, so questions about data-at-rest exposure, exported components, or IPC trust are answered as if the app were a standalone desktop program.
Candidates carry web/desktop mental models into mobile and do not practice reasoning about the OS sandbox, component exposure, and backup/clipboard/keychain surfaces.
What to do instead
For each mobile scenario, enumerate the platform surfaces explicitly: local storage, keychain/keystore, exported components, deep links, backups, and IPC. Answer only from the surface the scenario actually implicates.
When reviewing source code, the candidate flags every use of a risky API as a vulnerability without checking whether untrusted input can actually reach it, producing false positives that the exam marks wrong.
Pattern-based review (grep for dangerous functions) is faster to practice than data-flow reasoning, so candidates over-index on sink presence.
What to do instead
For each candidate sink, trace backward to a source and forward to a control. Only report a finding when a path from untrusted input to the sink exists and no sanitizer/allowlist intercepts it; otherwise state why it is not exploitable.
On cloud assessment items, the candidate attributes an exposure to the wrong layer (application bug vs. identity/permission policy vs. storage/resource configuration), so the recommended remediation targets a layer that would not have prevented the finding.
Cloud findings often present as 'data was reachable', and candidates answer by symptom instead of identifying which configuration or policy granted the access.
What to do instead
For each cloud scenario, identify the principal, the resource, and the policy/configuration that links them. Remediation must change the specific link (policy, ACL, public-access setting, role trust) that permitted access.
Recommends a remediation that is technically valid but does not address the demonstrated root cause (e.g., suggests input validation for a finding actually caused by missing server-side authorization), because the candidate matches the fix to the vulnerability name rather than to the evidence in the scenario.
Candidates study fixes as a lookup table keyed by vulnerability class and do not re-read the scenario's causal detail before selecting an answer.
What to do instead
Before choosing a remediation, write the root cause in one sentence from the scenario evidence, then verify the chosen fix would break that exact causal chain. Discard any fix that only reduces symptoms.