CNSP Certification common mistakes
CNSP Certification · Understand the traps and how to avoid them.
For a reflected XSS finding, the candidate reports the payload string alone and stops, without stating the injection context (HTML body, attribute, script block, URL) or demonstrating a working end-to-end exploit path.
Candidates memorize payload lists from blogs and assume a popup proves impact, so they skip the context analysis that determines whether the payload actually executes in the target's rendering path.
What to do instead
Practice classifying each reflection point by its surrounding syntax before choosing a payload, and write findings as context, payload, and observed execution. For example, note that a value reflected inside a double-quoted attribute requires breaking out of the attribute before a script event handler can fire. Include the request, the response snippet showing the sink, and the browser-observed effect.
When asked to assess authentication in a web application, the candidate tests only the login form for default credentials and never examines session token generation, cookie attributes, logout invalidation, or password reset flows.
Login pages are the visible entry point, so attention anchors there; session and reset logic is buried in redirects and secondary endpoints that candidates do not enumerate.
What to do instead
Build a checklist for each authentication surface: entropy and predictability of session identifiers, Secure and HttpOnly and SameSite flags, rotation on privilege change, server-side invalidation on logout, reset token lifetime and single use, and host-header handling in reset links. Walk every flow in a proxy and record token values before and after each state change.
The candidate scans the internal range with a single tool, reports open ports, and never attempts service-specific validation such as anonymous LDAP binds, SMB signing status, or unauthenticated share enumeration.
Port lists feel like deliverables and are fast to produce, while service validation requires protocol knowledge and careful low-noise interaction that candidates fear will break something.
What to do instead
Convert every discovered port into a protocol-specific hypothesis and test it with the lightest possible query: an anonymous bind against directory services, a null session share listing, an SMB signing check, an SNMP community string read. Report each result with the exact command and response so the finding is reproducible.
The candidate treats the internal network as flat, assuming that a single compromised host grants reach to all segments, and never maps segmentation controls or identifies which hosts are reachable from the initial foothold.
Lab environments are usually one subnet, so candidates never develop the habit of testing egress from the compromised host before planning lateral movement.
What to do instead
After any foothold, first enumerate the host's own network configuration, routes, DNS servers, and reachable peers, then test connectivity to each discovered segment. Document which paths are blocked and by what, since a failed path is itself a segmentation finding. Plan movement only along verified reachable edges.
For an external assessment, the candidate runs a broad port scan against every in-scope address and reports the raw output, without correlating hosts to owning business units or validating whether a service is actually exposed versus filtered.
Scan output is voluminous and looks authoritative, so candidates submit it as the deliverable instead of narrowing to exploitable or misconfigured exposure.
What to do instead
Reduce results to a per-host inventory with service version, ownership evidence from certificates or banners, and a validation step confirming the service responds to a real protocol handshake. Separate confirmed exposure from filtered or decoy ports, and prioritize findings by whether the service is internet-reachable and unauthenticated.
The candidate finds a TLS or DNS misconfiguration on an external host and reports it as critical without checking whether the affected hostname serves production traffic or is a parked or decommissioned record.
Severity is assigned from the vulnerability class rather than from the asset's role, and candidates skip the ownership and liveness checks that would downgrade the finding.
What to do instead
Before assigning severity, confirm the asset is live, in scope, and serving real users: resolve the name, inspect the certificate subject and validity, fetch the page, and look for production indicators. Record the evidence for the asset's role alongside the misconfiguration so the rating is defensible.
In mobile testing, the candidate confirms that certificate pinning blocks interception, declares the app secure, and never inspects local storage, exported components, or backup behavior.
Interception failure is a visible dead end that consumes the session, and candidates interpret it as a pass rather than as one control among many.
What to do instead
Treat pinning as a single control. Separately examine the app's private data directory for tokens and cached secrets, enumerate exported activities, services, providers, and receivers, test whether backups expose data, and check clipboard and logging behavior. Report each control independently with pass or fail evidence.
When reviewing source code, the candidate greps for a list of dangerous function names and reports every match as a vulnerability without tracing whether user input actually reaches the sink.
Pattern matching is fast and produces many hits, and candidates lack confidence in building a data-flow argument from entry point to sink.
What to do instead
For each candidate sink, trace backwards to a source: identify the entry point, follow the variable through assignments and function calls, and check for sanitizers or parameterization on the path. Report only paths with a demonstrated source-to-sink flow, and note the exact file and line for the source, the sink, and any bypassed control.
The candidate reviews cloud configuration by listing every setting flagged by a benchmark tool as non-compliant, without determining whether the affected resource holds sensitive data or is reachable from untrusted principals.
Benchmark output is easy to generate and looks complete, and candidates conflate compliance deviation with exploitable risk.
What to do instead
For each flagged setting, establish the resource's data classification, its network exposure, and the identities that can assume or access it. Prioritize findings where a public principal can reach sensitive data, and explicitly mark low-impact deviations as informational with the reasoning stated.
During a red team assessment, the candidate executes exploitation steps against production targets without agreeing on rules of engagement details such as allowed hours, prohibited techniques, or emergency stop contacts, relying on a general scope statement.
Candidates focus on the technical plan and assume the scope document covers operational constraints, so they never confirm deconfliction or escalation procedures.
What to do instead
Before any action, confirm in writing the in-scope assets, prohibited techniques, permitted hours, data-handling rules, and a named point of contact with a stop procedure. Keep an activity log with timestamps so any unexpected impact can be attributed and halted immediately.
The candidate assesses an ML system by testing only the model endpoint with adversarial inputs and ignores the training pipeline, feature stores, model artifacts, and access controls around the model registry.
The inference API is the visible interface, and candidates transfer web-testing habits to ML systems without mapping the broader ML supply chain.
What to do instead
Map the full lifecycle: data ingestion and labeling, feature computation, training jobs, artifact storage, registry permissions, and deployment. Test each stage for integrity controls, access restrictions, and provenance, and report findings per stage so supply-chain risks such as unverified model artifacts or writable feature stores are captured.
The candidate describes an AI/ML finding such as prompt injection only in terms of the model's text output, without tracing how that output reaches a downstream tool, agent action, or data store.
Prompt injection is often framed as a chatbot curiosity, so candidates stop at the generated text and do not follow the output into the system that consumes it.
What to do instead
For each model output path, identify the consumer: tool calls, code execution, database queries, or rendered HTML. Demonstrate impact at that consumer, such as an unauthorized action or data exposure, and report the full chain from input to downstream effect with the observed evidence.