CyberScan Browser Tools — user help

The toolkit reviews information you supply in your browser. Choose a tool, read its supported inputs, wait for Ready, then paste text or choose the files you want examined. Tools accepting supplied evidence have a synthetic example you can try before using your own material. The browser diagnostic observes the actual current page. Select Analyse to run the check; inspect its scope, coverage, findings and limitations before acting on the result.

This is a collection of local evidence checks. It does not scan an arbitrary website, certify a device, provide antivirus clearance or establish that an account is secure. A domain name alone does not supply DNS answers, a live certificate or a website export.

What happens to your input

The page and its fixed application assets are delivered by the website. After those assets are ready, the analysis engines use the supplied content locally and do not request the links, domains, keys or endpoints found in it. Tool pages have no analytics, tag managers or remote analysis services in their application document. Hosting still sees ordinary requests needed to deliver that document and its assets.

Inputs and results stay in application memory by default. Clear/reset drops the application's references, clears the form and terminates the analysis worker. It cannot promise forensic memory erasure or delete a report you already saved. A browser diagnostic can create and immediately remove disposable storage test values; it does not read your existing stored values.

Do not supply account login credentials, API secrets or private signing keys. The password tool is for a candidate you are considering, not an account-login test. Public-key verification requires a public key you independently trust. Pattern-based redaction is best-effort: review a report before sharing it, especially if public-looking certificate names, hostnames or business identifiers are sensitive to you.

Imported HTML, SVG, emails, scripts and configuration are data. They are not shown as executable previews. Suspicious destinations appear as text. The toolkit does not install packages, open submitted links, replay network captures or execute attachments.

Choose the right evidence mode

Tools and supported inputs

The interface displays each tool's byte and format limits. The detailed parser ceilings are in parser-limits.md. Input limits include supplementary text and selected files. Password, QR, archive and cryptographic formats have additional bounds. A skipped entry or unsupported format is not a pass.

Understand the results

Read the short conclusion first, then expand the evidence and limitations for the finding you want to understand. Every finding has a stable rule identifier/version, tool version, subject, evidence mode, outcome, explanation and next action. Severity and heuristic confidence are separate from outcome.

Coverage shows what ran and what remains unresolved. A partial report means some evidence or findings were not processed completely. There is no overall security score or certification badge. A safe-looking brand string, HTTPS URL or absence of a heuristic finding is never proof that a destination is safe.

Workflows requiring supplementary evidence

Compare two captures, zones, inventories or log snapshots

Put the current evidence in the main input and the previous evidence in the supplementary input where offered. Set labels that describe the actual capture, such as “before consent” and “after rejection”. For HAR, these labels describe your captures, not independently verified user-consent states.

General logs can use 5-minute, 15-minute, hourly or daily UTC buckets. The displayed first and last timestamps are observed events, not proven capture boundaries. Two unequal observation windows can have different totals without establishing a rate increase. Dedicated CSP/DMARC/TLS report comparison is outside this release's supported range; each report can be summarised independently.

Supply sitemap-index children without network access

Select the index and child XML files. Choose Index document URL mapping for the supplementary mode. Declare the HTTP(S) URL represented by each document:

{
  "documents": [
    {"document": 1, "url": "https://example.test/sitemap.xml"},
    {"document": 2, "url": "https://example.test/pages.xml"}
  ]
}

Document numbers follow the input order: pasted text first when present, then the displayed selected-file order. No mapping is inferred from a filename. Missing children, duplicate mappings, nested indexes and cycles remain explicit. The URLs are identifiers in your evidence; the toolkit does not fetch them.

Review DMARC discovery and identifier alignment

Select DMARC DNS snapshot and alignment, set the From domain and any supplied authenticated DKIM/SPF identifiers, and provide the documented local response envelope. Leave supplementary DNS text empty in this mode. This synthetic direct-policy example is deliberately small:

{
  "format": "dmarc-dns-v1",
  "responses": [
    {
      "name": "_dmarc.example.test",
      "type": "TXT",
      "status": "answer",
      "complete": true,
      "records": ["v=DMARC1; p=reject; psd=n"]
    }
  ]
}

For other questions, supply answer, nodata, nxdomain or error with the corresponding completeness assertion and records. TXT records may be strings or arrays of concatenated TXT segments. TXT, A and AAAA response questions are supported. Omitted answers are unknown, not proof of absence. A discovery/alignment calculation is conditional on these assertions; it does not authenticate the original message, validate DNSSEC or prove fresh publication.

The mode supports bounded RFC 9989 tree walks and direct/organisational/PSD preference, including applicable sp, np and testing semantics. It does not resolve CNAME/DNAME answer chains or duplicate-tag policy recovery. It accepts one supplied DKIM identifier and one SPF identifier per run.

Match an explicitly supplied advisory snapshot

In Software inventory, choose the supplementary Advisory snapshot mode. Use a fixed npm declaration or npm lock inventory. Supply a source, version and snapshot date, then OSV-style records with identifiers, modified dates and explicit affected versions:

{
  "source": "https://advisories.example.test/snapshot",
  "version": "synthetic-1",
  "snapshotDate": "2026-11-01",
  "advisories": [
    {
      "id": "EXAMPLE-2026-1",
      "modified": "2026-10-31T10:00:00Z",
      "affected": [
        {
          "package": {"ecosystem": "npm", "name": "example-library"},
          "versions": ["1.2.3"]
        }
      ]
    }
  ]
}

This is synthetic data, not a real advisory. The source URL is recorded as supplied provenance and is not opened. Only exact explicitly listed version strings are matched. Version ranges, Git ranges, other ecosystems and unspecified/unpinned declarations remain unverified. A missing match cannot establish that a package is unaffected or current. Check the snapshot's authenticity, completeness and date independently.

Add supporting notes to the questionnaire

Use one labelled note per line, such as restore: Synthetic restore exercise recorded on 2026-10-01. Supported control codes are mfa, access, leavers, passwords, backup, restore, patch, encryption, domain, supplier, payment, incident and continuity. Notes are supplementary self-reported assertions, not verified evidence or binary attachments. Keep secrets and personal details out of them.

Saving and clearing

Download JSON creates a local structured report from the visible result. Print opens the browser's print workflow; available save-as-PDF options depend on your browser and operating system. Neither action automatically attaches your original files. Reports include scope, provenance, rule/tool versions, coverage, limitations and a timestamp from your device's clock.

Passwords, private keys, authentication-cookie values and bearer-token values are excluded from ordinary reports. Other evidence is minimised and redacted on a best-effort basis. Downloading is an explicit persistence action; saved reports are then subject to your normal file-sharing and backup arrangements. No CSV export is offered.

Change the input and rerun to produce a new result. Previous findings are invalidated when inputs change. Cancel stops the worker; clear/reset removes the application's current input/result references. A timed-out, cancelled or malformed analysis does not produce a security pass.

Compatibility and offline limits

Use a supported modern browser over HTTPS. Some algorithms need Web Crypto; QR processing needs worker bitmap/canvas support. Unsupported APIs produce a clear limitation rather than a weaker cryptographic substitute. A page controlled by an unreviewed service worker is blocked from accepting input until the host resolves that scope.

The design requires no analysis network after the page and selected tool's fixed assets are ready. This does not promise first visits, reloads or unopened modules will work offline. At documentation handoff, browser-level physical network-disable testing has not been available; see the actual release verification report for the recorded evidence rather than treating runtime request guards as an offline-switch test.

If a parser rejects your material, check the supported format and size, reduce it to the relevant evidence, and retain originals privately. Do not remove an “unknown” outcome by inventing missing records or keys. Current references, dependency versions, data licences and remaining advanced features are documented in the delivery registers.