Review Packet: Client-Side Security and Privacy

When to use

Use this packet for:

• third-party scripts
• analytics, attribution, session replay, experimentation, or personalization
• raw HTML or user-generated content
• browser storage of sensitive data
• auth/session behavior
• client-side permission rendering
• GenUI generated components or tool calls
• routes that expose account, billing, health, finance, identity, or regulated data

Intake questions

Browser trust boundary

• What attacker-controlled input reaches DOM, URL, storage, postMessage, workers, or script sinks?
• What code can create HTML, script, style, URL, or navigation behavior?
• Which browser security controls are enabled: CSP, Trusted Types, frame policy, opener policy, cookie attributes?
• What client-side checks are UX only and what is enforced on the server?

Sensitive data

• What sensitive data appears in HTML, JavaScript bundles, API payloads, logs, analytics, errors, session replay, local storage, IndexedDB, cookies, or URLs?
• What data is minimized before redaction?
• What data is sent to third parties?
• How is consent applied before scripts load or events emit?

Third-party origin control

• Which third-party scripts run?
• Who owns each one?
• What can each script read or modify?
• What is the load strategy?
• What is the performance budget?
• What is the kill switch?
• How do you detect JavaScript drift or unauthorized changes?

Client-side logging and monitoring

• Are CSP violations collected and triaged?
• Are client-side security errors observable?
• Can you detect unexpected script changes, sensitive-data rejection, or storage misuse?
• Does logging avoid copying secrets or personal data into observability tools?

Required artifacts

• browser threat model
• sensitive data flow map
• third-party script register
• CSP/security header plan
• consent-aware loading plan
• storage and retention decision
• security monitoring plan
• incident response and kill-switch plan

Decision matrix

Risk	Required control
Broken client-side access control	server authorization for every protected operation; UI checks only improve UX
DOM XSS	safe rendering boundaries, sanitization, CSP, Trusted Types where applicable
Sensitive data leakage	minimization, redaction, URL/log/storage review, third-party routing controls
Outdated components	dependency ownership, update SLA, SBOM or inventory where appropriate
Third-party origin risk	owner, purpose, consent category, load strategy, kill switch, performance budget
JavaScript drift	script inventory, integrity/change monitoring, vendor review cadence
Sensitive client storage	explicit storage decision, retention, encryption limits understood, logout behavior
Logging gaps	CSP/security telemetry, client error classification, privacy-safe trace correlation
Missing browser controls	CSP, cookie attributes, frame/opener/referrer/permissions policies as appropriate
Proprietary information in client	bundle review, source map policy, secrets scanning, environment variable controls

Red flags

• "The user cannot click it" is treated as authorization.
• Session replay is enabled on sensitive forms without blocking/masking proof.
• Analytics events accept free-form object dumps.
• Raw HTML has no named sanitizer boundary.
• A tag manager can add scripts without engineering review.
• CSP exists but no one triages reports.
• Sensitive filters or identifiers appear in URLs.
• Local storage contains long-lived tokens or regulated data.
• Third-party scripts have no owner or kill switch.
• Prompt-generated UI can produce arbitrary links, HTML, or actions.

Approval criteria

• Server-side authorization is documented for protected operations.
• Sensitive data is minimized before browser emission.
• Third-party scripts are registered, owned, budgeted, and kill-switchable.
• CSP/security headers have rollout and triage owners.
• Consent affects loading and routing, not only event labels.
• Storage decisions include retention and logout behavior.
• Monitoring can detect drift, violations, and sensitive-data rejection.
• Incident playbook names who disables what.

Reviewer comments

• "This role check can stay for UX, but the mutation must document server authorization."
• "This session replay setting needs a fixture proving the payment fields are blocked, not only masked."
• "The analytics schema allows arbitrary properties. Please add typed events and sensitive-field rejection."
• "This vendor script needs an engineering owner, load strategy, consent category, and kill switch before launch."
• "CSP report-only is acceptable for beta, but the report triage owner and enforcement date are missing."

Exercise

Review a real or simulated route with:

• one auth-protected action
• one third-party analytics script
• one session replay tool
• one raw HTML or rich-text field
• one local storage key

Complete the required artifacts and list launch blockers.