Inspect page evidence and consent behavior

Read headers, cookies, resources, console messages, and credential-storage signals.

Start from the exact page

  1. Open an asset, choose Pages, and select the intended target, port, and path.
  2. Review its latest observation, redirect, and monitoring-coverage state.
  3. Inspect Consent Attempt to see whether a banner was found and an interaction was attempted or completed.
  4. Use the related evidence pages below, checking observation times and before/after-consent phases where available.
Page Details showing evidence counts and consent attempt status
Page Details links to collected evidence and records the consent attempt. Select the image to enlarge it and inspect the details.

Inspect HTTP headers

  1. Open HTTP Headers from the page.
  2. Locate the relevant header and inspect its full value and observed response context.
  3. Compare it with the intended redirect, caching, or security policy and follow any related finding for its assessed evidence.
HTTP Headers table for an example monitored page
Inspect the observed header names and values for the selected page. Select the image to enlarge it and inspect the details.
  1. Open Cookies and select the available capture phase.
  2. Inspect cookie name, domain, expiry, Secure, HttpOnly, SameSite, and available attribution.
  3. Compare before- and after-consent observations with the Consent Attempt result to see whether the banner interaction completed.
  4. Investigate the applicable cookie finding when a recorded configuration needs review.
Cookies table with flags and example cookie domains
Compare cookie attributes and capture context for the selected page. Select the image to enlarge it and inspect the details.

Follow resources and runtime errors

  1. Open Resources and use its available filters to inspect scripts, images, APIs, and other loaded dependencies.
  2. Open Console Logs to inspect observed warnings or errors. Check the affected URL and same-origin context before assigning the issue to your application.
  3. Compare related operational events for durable third-party service adoption or removal rather than treating every rotating resource URL as a new service.
  4. If a browser-storage credential finding is present, review its sanitized storage location, detector, phase, and value length, then investigate the source application through your normal remediation process.
Resources table with example dependency URLs and response status
Review loaded dependencies and their observed response status. The image shows the first rows. Select the image to enlarge it and inspect the details.

Understand page services

Page services summarize durable third-party usage inferred from cookies, resources, and other runtime evidence. Use service-adoption or removal events to investigate a change in a page’s external service footprint. A rotating resource URL or cookie can change while the underlying service remains the same; recurring provider noise can be suppressed without removing the useful service signal.

Identify collection traffic

If a WAF or access control blocks collection

  1. Compare the observed URL, screenshot, and Monitoring limited state with the page you intended to monitor.
  2. If your WAF, bot protection, or source-IP restrictions block authorized monitoring, ask the responsible administrator to review the current Kantoku collection source IPs.
  3. Where required, permit those collection sources under your organization’s approved access policy, then inspect a later successful observation. Use the current published list rather than copying addresses from guide screenshots.
  4. For a protected custom page that needs sign-in, configure an authorized authentication profile rather than treating an allowlist as a substitute for application credentials.

A challenge page, blocked collection, or collector execution failure describes monitoring coverage. It is not itself a customer finding and does not lower the Exposure Score. Incomplete coverage does not confirm that an earlier finding was fixed.

Expected outcome

You can inspect the collected page evidence, its capture phase, and any coverage limitations.

Supported browser-storage checks inspect top-level same-origin localStorage and sessionStorage before and after the consent attempt. High-confidence matches can include authentication tokens, passwords, private keys, provider credentials, authorization credentials, and credential-bearing connection strings. Local storage persists beyond the current tab, so a local-storage match is treated as more severe than an otherwise equivalent session-storage match. Credential values, decoded tokens, and value hashes are not retained in finding evidence. Incomplete storage coverage does not resolve an existing finding. Cookie findings can group related evidence by page and service, and recurring tracker or challenge churn may be suppressed from events to reduce noise.

Screenshot

Scroll to inspect the image, or choose Fit image to see the whole screen.