Guide
Build and review a website script inventory
Inspect JavaScript resources using identity, provider, behavior, timing, browser capability, destination, and risk context.
Last reviewed September 12, 2026
A website script inventory is a current, project-scoped record of JavaScript and related browser resources observed across monitored journeys. SiteWall combines resource identity with provider ownership, first- and last-seen timing, browser behavior, network destinations, findings, and supporting sessions so reviewers can move from inventory coverage to an evidence-backed decision.
Resource inventory overview
Inventory is the project-wide list of observed resources. Search by URL or name and filter by risk, category, or provider. Each row combines identity with performance, access, score, and status context so you can choose what to inspect next.
What to review
Use the following table to understand how each area supports the task.
| Area | How to use it |
|---|---|
| Search | Narrow the current project’s records before interpreting totals or opening a detail view. |
| Filter | Narrow the current project’s records before interpreting totals or opening a detail view. |
| Risk | Use the value to prioritize review, then inspect the contributing findings and runtime evidence. A score or severity is a triage signal, not an approval decision or a confirmed incident. |
| Performance context | Compare like-for-like sessions and treat captured timing as context, not a complete causal proof. |
Inspect a resource
A resource page separates its record into Overview, Security, Performance, API Usage, Code Analysis, and Technical views. Review identity and source first, then compare capability, network, timing, and analysis records before deciding whether a finding or policy change is warranted.
Procedure
- 1.
Open the correct project and page
Use the project selector to choose the website you intend to review, then open Inventory in the left navigation. Confirm the organization, project, and monitored domain before interpreting a record or changing a control.
- 2.
Define the observation window
Record the page or journey, browser and consent state, test time, and active filters. Note the visible counts before narrowing the view so an empty filtered result is not mistaken for missing collection.
- 3.
Identity
Confirm the URL or domain, provider association, first and last observation, and the project in which the entity was recorded. Open the linked detail record; a display name or enrichment label is not proof of ownership or approval.
- 4.
Source
Review source in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 5.
Versions
Review versions in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 6.
APIs
Compare the observed browser access with the resource’s expected function before allowing or restricting it.
- 7.
Destinations
Trace the relationship from the loading resource to the observed destination or capability. Confirm required service endpoints and regional behavior in representative journeys before restricting access.
- 8.
Sessions
Open a representative session and record its page, time, browser context, and observed resources. Use it to establish that the behavior occurred in that captured journey, not that it occurred for every visitor.
- 9.
Confirm the record against known traffic
Refresh the view, remove unintended filters, and compare the provider, resource, relationship, or session with the page and journey you exercised. Follow the linked detail record before drawing a conclusion.
- 10.
Record the scoped observation
Preserve the record link, project, page or journey, filters, observation window, reviewer, and the next record to inspect. State untested conditions as coverage gaps.
Understand resource scores
Resource scores rank observed characteristics to help prioritize review. Read a score with the resource’s provider, capabilities, destinations, performance, findings, and observation window. A high or low score is not a standalone determination of safety.
What to review
Use the following table to understand how each area supports the task.
| Area | How to use it |
|---|---|
| Inputs | Use the value to prioritize review, then inspect the contributing findings and runtime evidence. A score or severity is a triage signal, not an approval decision or a confirmed incident. |
| Interpretation | Use the value to prioritize review, then inspect the contributing findings and runtime evidence. A score or severity is a triage signal, not an approval decision or a confirmed incident. |
| Limitations | Use the value to prioritize review, then inspect the contributing findings and runtime evidence. A score or severity is a triage signal, not an approval decision or a confirmed incident. |