Data collected and excluded

Use Data collected and excluded to confirm what WebRiskOps stores for accepted scan evidence, what it excludes, and how to stop before sharing unsafe artifacts.

Customers, developers, agencies and security reviewers

Feature availability

Product, package, provider and deployment boundaries for this page.

Available from
Current documentation
Deployment modes
cloudself-hosted

Product screenshots

Current customer-safe screenshots are generated from the application so examples do not drift from the product.

Generated customer-safe screenshot of the scan detail worker readiness and artifact availability state.

Before reviewing collected data

Use this page after an accepted scan creates evidence and before a report, screenshot, artifact or ticket export is shared. The goal is to prove that collected data belongs to the accepted public scope, and that private or unnecessary data stays excluded.

  • Review captured evidence
  • Confirm `accepted_scope`, `evidence_collection_status`, URL, response status, page title, `screenshot_path` and `html_snapshot_path` before sharing a report or export.
  • Treat console and network counts as finding context, not as broad data extraction.
  • Stop the workflow when `SECURITY_DATA_BOUNDARY`, `PRIVATE_PATH_EXCLUDED`, `DATA_REDACTED` or `EVIDENCE_INCOMPLETE` applies.

Confirm collected and excluded evidence

Follow the path `Accepted scan scope → Scan detail → Worker readiness → Artifacts → Privacy redaction → Share or stop`.

  1. Open `/scans/{scanRun}` from a completed accepted scan. Result: the scan detail page shows the exact run, worker readiness and artifact availability before anyone shares evidence.
  2. Compare the scan run with `accepted_scope`. Result: only approved public URLs, domains and paths are allowed to produce evidence.
  3. Open Worker readiness → Artifacts. Result: `evidence_collection_status`, `screenshot_path`, `html_snapshot_path` and scan coverage notes show whether evidence is available, redacted or incomplete.
  4. Review captured evidence for URL, response status, page title, screenshot path, HTML snapshot path, `console_error_count` and `network_error_count`. Result: reviewers see page-level context without collecting unrelated page data.
  5. Open the report preview or issue evidence entry. Result: finding evidence is limited to the page state, issue description, severity, confidence, fingerprint and customer-safe artifact references.
  6. Confirm excluded paths before sharing. Result: admin, account, checkout, logout, private, out-of-domain and customer-only paths stay outside the report and ticket export.
  7. If a screenshot, HTML snapshot, console message or issue snippet contains passwords, tokens, payment details, personal form values or private customer data, stop and use Privacy redaction. Result: `DATA_REDACTED` is resolved before publication or export.
  8. If an artifact comes from a private or out-of-scope path, remove that path from accepted scope and keep `PRIVATE_PATH_EXCLUDED` visible. Result: the next scan does not reuse unsafe evidence.
  9. Before exporting to a provider, preview the exact report or ticket fields. Result: external systems receive only the customer-safe evidence needed for the selected workflow.
  10. Continue to Artifact retention, Secret handling or Personal data boundaries when the evidence boundary is clear. Result: the next step explains storage lifetime, credential redaction or personal-data limits.

Data WebRiskOps can collect

Collected data should be tied to one account, one project, one accepted scan scope and one scan run.

  • Public in-scope URL, normalized URL, final URL, response status and page title.
  • Screenshot and HTML snapshot paths when artifacts are available.
  • Console error counts, network error counts and normalized issue evidence.
  • Issue category, severity, title, description, evidence snippet, fingerprint and confidence.
  • Scan coverage notes, skipped-page reasons, blocked artifact reasons and report/ticket fields needed to explain the automated next action.

Data WebRiskOps must exclude

Excluded data should not be captured, published, exported or used to expand scan scope.

  • Passwords, bearer tokens, API keys, private keys, webhook secrets and session identifiers.
  • Payment card numbers, payment method details, provider secrets and payment authorization values.
  • Admin dashboards, account-only pages, logout paths, employee-only areas and pages outside accepted scope.
  • Form values, personal details or customer records that are not needed to explain a public page finding.
  • Data from another account, client workspace, domain, project, provider or unsupported private network target.

Ready and blocked evidence states

Use these states to decide whether evidence can move to a report, export or shared artifact.

  • Evidence ready means `evidence_collection_status` is ready, the URL belongs to `accepted_scope`, and screenshot or HTML paths are customer-safe.
  • Redaction ready means `redaction_status` confirms sensitive values were removed or replaced before sharing.
  • Boundary blocked means `SECURITY_DATA_BOUNDARY` still applies because the evidence source, path or artifact content is outside the accepted workflow.
  • Private path excluded means `PRIVATE_PATH_EXCLUDED` removed a private, admin, checkout, account, logout or out-of-domain page from scan evidence.
  • Evidence incomplete means `EVIDENCE_INCOMPLETE` or a missing artifact reason needs a new accepted scan before the evidence is used.

Continue after data boundary review

When collected and excluded data are clear, use Artifact retention to understand storage lifetime, Secret handling to respond to token or credential exposure, Personal data boundaries to handle personal-data limits, Screenshots and HTML snapshots to inspect artifact availability and Privacy redaction before publishing or exporting evidence.

Related documentation

Was this page helpful?

Feedback goes into the product documentation review queue.