Load the portal with browser developer tools, list every domain that serves a script or receives a request, match each to an owner and a reason, and remove anything without both. Then add a release check so a new script cannot appear without review. This is a manual first pass you can finish in an afternoon.
Why scripts deserve their own list
A script included from another domain runs inside your page with the same access as your own code. On a portal where students and parents sign in, that means it can see what is on screen, including names, grades, and messages, depending on how it is written. Package lockfiles do not show these scripts, because they are loaded at runtime from a URL or through a tag manager.
The FTC's COPPA guidance makes the same point from a legal angle for child-directed services: operators must examine third parties' collection practices, and may be liable for collection by others on their property. Treat each script as a third party collecting on your behalf.
Step by step
- Open the portal in a clean browser profile. Use the network tab, reload, and sign in as a test student and as a test parent.
- Sort requests by domain. Note every domain that is not yours.
- Separate scripts from other requests. Scripts, frames, and fonts are different risk levels. Scripts and frames matter most.
- Check page types. Sign in pages, grade pages, and messaging pages may load different sets. Test each.
- Look inside tag managers. A single tag manager entry can load many more scripts. Ask who can edit its container.
- Fill in a table.
| Domain | Purpose | Owner | Data it can see | Decision |
|---|---|---|---|---|
| Example chat provider | Support chat | Support lead | Page content on help pages | Keep, limit to help pages |
| Example analytics | Usage stats | Product | Page URLs | Review URL contents |
- Decide. Keep, limit to certain pages, replace, or remove.
Check what URLs reveal
Page addresses sometimes contain student identifiers. Analytics tools record the address. If your URLs include names or IDs, change them, or configure the tool to strip them.
Keep it from growing back
- Limit who can add tags, and log changes.
- Use browser security headers that restrict where scripts may load from. Start in report only mode so you can see what would be blocked before enforcing.
- Add a step in the release checklist: has the set of external domains changed?
- Re-run the inventory each term.
Separate marketing from student areas
Marketing sites often need more tools than a sign in area. Keep their tag configuration separate from the student-facing portal so a campaign experiment cannot add a tracker where students sign in.
Quick check
Do scripts matter if they come from well known companies?
Yes. The question is what the script can see and collect on your pages, not how familiar the name is.
Will our SBOM list these scripts?
Not usually. An SBOM covers packages in a build. Scripts loaded at runtime need their own inventory.
Safeguard's SBOM and dependency scanning cover the packages in your builds, so pair it with a runtime script list like the one above. The free scan covers the build side.
Sources
Last reviewed: 19 October 2026.
