CAP-PC ENS common mistakes
CAP-PC ENS · Understand the traps and how to avoid them.
Treating a reflected XSS finding as fully mitigated because the application HTML-encodes the payload, without checking whether the same value is later written into an attribute, a JavaScript string, a URL parameter, or a CSS context where HTML encoding does not neutralise it.
Candidates learn a single encoding rule (HTML entity encoding) and apply it as a universal fix, so they stop analysis at the first context they see and miss context-shift sinks such as inline event handlers, href values, and template literals.
What to do instead
For every reflection, trace the value to its exact output context and recommend the matching control: HTML entities for element text, attribute quoting plus attribute encoding, JavaScript string escaping or JSON serialisation for script blocks, URL encoding for query components, and CSP as defence in depth. Explicitly state which context each control covers.
Reporting an access-control issue from a single request that returned 403 or 200 without replaying the request with a different session, a lower-privileged account, no cookie, and a manipulated object identifier to confirm the control is actually enforced server-side.
Candidates test as one user and infer authorisation from UI behaviour or from one status code, conflating authentication checks, UI hiding, and true object-level authorisation.
What to do instead
Run a fixed matrix for each endpoint: anonymous, low-privilege user, owner, and other-tenant user, each with the object ID swapped. Document the request pairs and responses, and distinguish horizontal from vertical escalation in the finding.
Reading source files in isolation and missing that a sanitizer is applied in one layer (controller or middleware) but bypassed by a second code path that reaches the same sink, such as a background job, admin endpoint, or alternate route registration.
Candidates do linear top-to-bottom reading of the file containing the obvious vulnerability instead of building a call graph, so they miss duplicate entry points and framework-level routing that bypasses the middleware chain.
What to do instead
Enumerate all routes and entry points first, then for each sink work backwards to every caller. Check framework configuration for route-level middleware exclusions, and flag any sink reachable by a path that skips the sanitizer.
Flagging a dangerous-looking function call as exploitable without proving attacker control of the argument, or conversely dismissing it because the variable name suggests it is safe.
Pattern-matching on function names (eval, exec, pickle.loads, innerHTML) substitutes for data-flow reasoning, and candidates trust variable naming and comments over actual taint.
What to do instead
For each candidate sink, produce a short taint trace from an untrusted source (request parameter, header, file upload, queue message) to the sink, noting any transform in between. If the trace cannot be completed, downgrade the finding and say what is missing.
Reviewing only application code during a cloud assessment and ignoring identity and resource-policy configuration, such as a role trust policy with a wildcard principal or a storage bucket policy granting public read.
Candidates carry an application-security mindset into cloud work and look for code bugs, while most cloud compromise paths are configuration and identity issues expressed in policy documents.
What to do instead
Build a separate configuration checklist per service: who can assume each role and under what conditions, which resources have public or cross-account access, whether logging and key management are enabled, and whether network exposure is intended. Report identity findings separately from code findings.
Assuming a private subnet, security group, or disabled public endpoint means a resource is unreachable, without checking for a load balancer, peering connection, NAT path, or an over-permissive instance profile that provides an alternate route.
Candidates evaluate network controls one component at a time and do not model the full path from an attacker position to the asset, so they treat each control as independently decisive.
What to do instead
Draw the reachability path explicitly from each assumed attacker position to the target, listing every hop and the control at each hop. State the assumed starting position in the finding so the reader can judge the claim.
Describing a red-team action as successful based on executing a technique, without capturing the evidence that the objective was met, such as the actual data accessed, the privilege obtained, or the persistence confirmed.
Candidates focus on tooling and technique execution under time pressure and treat a command completing without error as proof of impact, which collapses under review.
What to do instead
For each action, define the objective and the evidence before executing: the exact artefact, screenshot, log line, or file hash that proves success. Record failures as well, and keep a timestamped action log.
Performing actions outside the agreed scope or at a time not covered by the authorisation, such as testing a related domain, a shared SaaS tenant, or a production system during a change freeze.
Candidates chase an interesting lead discovered mid-engagement and assume implied permission, without re-reading the rules of engagement or confirming with the authorising contact.
What to do instead
Keep the scope and prohibited-action list open during the engagement, verify each new target against it before touching it, and pause to obtain written confirmation for anything ambiguous. Note the confirmation in the action log.
Treating an ML component as a normal API and testing only input validation, missing model-specific attack surfaces such as training-data poisoning, prompt injection through retrieved documents, model extraction, and adversarial inputs.
Candidates apply web habits to ML systems and do not map the ML lifecycle (data collection, training, retrieval, inference, output handling) to distinct threats.
What to do instead
Walk the lifecycle stage by stage and ask what an attacker can influence at each: data sources, fine-tuning inputs, retrieval corpus, system prompt, tool permissions, and downstream consumers of model output. Report which stage each finding touches.
Writing findings that state a vulnerability class and a severity but omit the concrete request, the observed versus expected behaviour, and the business impact, leaving the reader unable to reproduce or prioritise the issue.
Candidates optimise for finishing the report and assume the reader shares their context, so they compress reproduction steps and impact into generalities.
What to do instead
Use a fixed finding template: title with the affected component, reproduction steps with exact requests, observed and expected results, evidence, impact in business terms, and a specific remediation. Have each finding stand alone without reference to other sections.