Solution Pack: Secure Account Portal

What this solution demonstrates

This solution pack shows a security- and reliability-heavy frontend architecture. It emphasizes browser trust boundaries, sensitive forms, idempotent mutations, CSP rollout, third-party governance, accessibility, observability, and incident response.

Architecture summary

Decision: build the account portal as an authenticated server-rendered shell with route-level sensitive-data policies, server-enforced authorization, explicit browser security controls, form mutation boundaries, and deny-by-default third-party script behavior.

Route policy matrix

Route	Sensitive data	Third-party default	Storage policy	Review level
/account/profile	name, email, phone	analytics through typed SDK only	no sensitive local storage	security/privacy review
/account/billing	payment metadata, invoice data	deny replay, deny marketing scripts	no payment data in browser storage	specialist review
/account/security	sessions, MFA, devices	deny all non-essential third parties	no long-lived client secrets	specialist review
/account/apps	connected app permissions	analytics through typed SDK only	no tokens in browser storage	security review
/account/support	free-form support text	support widget only in panel	drafts only if explicitly designed	privacy review

Sensitive mutation lifecycle

ADR bundle

ADR 1: Deny-by-default third-party scripts on sensitive routes

Decision: billing and security routes deny session replay, marketing tags, attribution pixels, and tag-manager-controlled scripts. Functional support widget may load only when the support panel is opened.

Verification:

• route allowlist tests
• third-party register review
• CSP report triage
• kill switch tested in staging

ADR 2: Sensitive forms use server-enforced mutation boundaries

Decision: profile, billing, security, and connected-app mutations validate input on the server, enforce authorization on the server, use idempotency keys for side effects, and preserve dirty form state on recoverable failures.

Verification:

• duplicate submit test
• session refresh failure test
• authorization denial test
• validation focus test

ADR 3: CSP report-only to enforcement rollout

Decision: start CSP in report-only during internal beta, triage violations weekly, then enforce before external GA.

Consequences:

• catches unsafe scripts before enforcement
• requires report ownership
• may reveal legacy unsafe inline scripts

Verification:

• report volume trend
• untriaged report age
• enforcement date
• exception register

Failure matrix

Failure	UX	Control	Signal
session refresh fails	preserve form, prompt re-auth	no submit until session restored	auth refresh failure
billing update times out after commit	pending state reconciles by idempotency key	idempotent mutation	duplicate prevention metric
third-party script blocked by CSP	user workflow continues	deny-by-default script policy	CSP violation report
CORS widened accidentally	blocked by review and server auth	config review and tests	security config diff
validation error	focus first invalid field	typed validation result	validation error class
support widget fails	support panel fallback link	lazy isolated dependency	widget failure metric

Accessibility requirements

• form errors connect to fields with accessible descriptions
• destructive actions require clear confirmation and keyboard support
• dialogs trap and restore focus
• session/device tables support keyboard navigation and screen-reader labels
• toasts do not replace inline errors
• re-auth prompts preserve user work and focus

Observability

Track:

• route error rate
• action started/completed/failed
• validation error classes
• idempotency duplicate suppression
• CSP violations by release
• third-party script load attempts on denylisted routes
• sensitive-event rejection count
• accessibility regression findings
• account audit event correlation id

Incident runbook

If sensitive data leaks through telemetry:

1. Disable telemetry destination or route-level event emission.
2. Preserve event schema, release, and destination config.
3. Identify affected payloads and users.
4. Notify security/privacy/legal.
5. Purge downstream data where required.
6. Add sensitive-field rejection test.
7. Keep destination disabled until review passes.

Launch readiness decision

Launch only when:

• security/privacy review passes
• CSP triage owner exists
• sensitive mutations have idempotency and authorization tests
• third-party register is complete
• telemetry schema rejects sensitive fields
• billing/security routes deny replay and marketing tags
• accessibility walkthrough passes for all critical forms
• rollback flags are tested

Portfolio summary

This capstone demonstrates high-stakes frontend architecture: browser trust boundaries, security headers, sensitive data minimization, third-party governance, form reliability, accessibility, observability, and incident response. A strong submission should include a threat model, route policy matrix, mutation lifecycle, CSP rollout ADR, failure matrix, and completed security/privacy review.