fix(security): scope screenshots, baselines and metrics to the caller's team

[snevesbarros]

Summary

A security review found several endpoints that let an authenticated user of one team read or change another team's data. Each was confirmed against a running instance, acting as a plain (non-admin) user of a second team. This PR adds team checks to all of them.

Issue	Before	After
GET /metrics/screenshot?thumbnail=true, /screenshot/grouped/platform, /screenshot/grouped/tag	Returned every team's screenshots, including thumbnails, build ids and server paths	Only search builds of the caller's teams
/screenshot/views, /screenshot/tags	Listed every team's view and tag names	Same scoping
Baselines	No team at all: only DELETE checked access. Any user could list, read, edit (e.g. ignore the whole image) and create baselines for any team. Comparison found the baseline by view and platform only, so a team using another team's view name got a diff image of that team's baseline	Baselines record the team of their screenshot's build. Every endpoint checks that team, and comparisons only use the screenshot's own team's baseline
POST /execution, POST /screenshot	Accepted writes into any team's build	403 without access to the build's team. A rejected screenshot upload's file is removed
GET /metrics/phase?teamId=	Returned any team's metrics, test titles included	403 without access to the team
PUT /environment/:id, PUT /phase/:id	Open to every user and API token	Admin-only, like create and delete (environments and phases are shared by all teams)

Baselines in detail

• Create: requires access to the screenshot's team. The "already exists" check only considers that team's baselines, so two teams can each have a baseline for the same view name.
• Update: requires access to the baseline's team. A new screenshotId must belong to the same team.
• GET /baseline:
  • New optional teamId, which must be a team the caller can read.
  • Without it, non-admins only get their own teams' baselines.
  • Admins still get every team's. The released UI and JS client look baselines up by view and platform without a team, so this keeps them working; comparisons are scoped correctly regardless.
• Existing baselines: startup runs an idempotent backfill (baselineUtils.backfillTeams) that sets each legacy baseline's team from its screenshot's build, so existing comparisons keep working after the upgrade. A legacy baseline whose screenshot or build no longer exists is left without a team and is only accessible to admins.

Also fixed

• GET /baseline/:id read the id from req.query instead of req.params, so it always returned 404.
• GET /screenshot/tags without a limit always returned 500, because it defaulted to $limit: 0, which MongoDB rejects. It now defaults to 10, like /screenshot/views. This was broken on master too.

Compatibility

• Users within their own team: no change.
• API tokens or scripts that renamed environments or phases, or that wrote into another team's build, now get 403.
• Admins viewing a screenshot whose view name is shared by several teams can still see more than one baseline from GET /baseline until the UI passes teamId. That's a small follow-up in angles-ui and angles-javascript-client.

Testing

• New test/team-scoping.tests.js (20 tests). Each acts as a user of one team against another team's data and asserts 403 / 404 / filtered results. It also covers:
  • per-team baselines for the same view
  • comparisons against the team's own baseline only
  • the startup backfill
  • that the owner team still works
• Full suite against a local MongoDB: 569 passing (549 before, plus 20 new). npx eslint app server.js is clean.
• Re-ran the live attack script from the review against this branch. Every cross-team request now returns 403 or 404, and the startup log showed Baseline team backfill: 1 of 1 baseline(s) updated.

Notes

• feat(attachments): let automated tests attach logs, HAR files, videos, traces and HTML #133 (test attachments) also changes the start of POST /execution, so whichever PR merges second may need a small conflict resolved.
• Remaining findings from the review are not part of this PR: HTML injection via step info in the UI, login rate limiting, and clickjacking / security headers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KgQXSUjuLVXmLWxobnMfSf

---

Generated by Claude Code