Capstone: Secure and Reliable Account Portal

Product scenario

Design an account portal where users manage profile data, billing, security settings, sessions, connected applications, and support requests. The surface handles sensitive data and must remain understandable during partial failures.

Functional requirements

• Authenticated account shell.
• Profile and billing forms with validation and dirty-state protection.
• Session/device management.
• Connected-app permissions.
• Support request workflow.
• Audit-visible account changes.

Non-functional requirements

Concern	Requirement
Security	XSS, CSRF, clickjacking, tabnabbing, CORS misuse, dependency, and third-party risks are addressed.
Reliability	Critical account actions have retry, idempotency, and clear failure states.
Accessibility	Forms, dialogs, tables, errors, and toasts meet accessibility contracts.
Privacy	Sensitive values are minimized in logs, browser storage, and analytics.
Observability	Errors, security policy violations, release, route, and action context are captured.

Architecture constraints

• Frontend visibility checks do not replace server authorization.
• Browser storage must not contain long-lived sensitive data.
• Security headers must be specified as product architecture, not deployment trivia.
• Failure states must preserve user intent and prevent duplicate destructive actions.

Required diagrams

• Browser trust boundary diagram.
• Auth/session bootstrap flow.
• Form mutation and idempotency lifecycle.
• CSP and third-party script policy map.
• Reliability/degradation state diagram.

Sample browser trust boundary

Sample sensitive mutation lifecycle

Sample reliability state matrix

Failure	UI behavior	Data behavior	Observability
session refresh fails	preserve form, show re-auth prompt	do not submit	auth error with route/action
billing API timeout	keep pending state with retry	idempotency key retained	timeout event and trace id
profile validation error	focus first invalid field	no local success state	validation error type
CSP violation	user sees no raw policy detail	block unsafe script	violation report with release

Implementation milestones

1. Define sensitive actions and attacker-controlled inputs.
2. Create browser threat model.
3. Specify auth/session and permission propagation model.
4. Define CSP, frame, opener, referrer, cookie, and CORS policy.
5. Design form state, validation, retry, and duplicate prevention.
6. Define degraded UX for partial API failures.
7. Add accessibility and observability gates.
8. Run incident and launch-readiness review.

ADRs to write

• ADR: Account portal browser trust boundaries.
• ADR: Session bootstrap and permission display model.
• ADR: CSP rollout and Trusted Types strategy.
• ADR: Sensitive form mutation reliability.

Gates

Gate	Evidence
Security	Threat model, CSP policy, dependency/script register, CORS/CSRF notes.
Reliability	Failure matrix, idempotency strategy, retry and timeout behavior.
Accessibility	Form, dialog, toast, and table verification notes.
Privacy	Storage/logging/analytics data minimization checklist.
Incident response	Disable path, rollback notes, postmortem template.

Failure-mode review

• User loses billing form data after session refresh.
• Third-party script accesses sensitive DOM content.
• CORS is widened to unblock local development and ships.
• CSP report-only violations are ignored.
• Account update succeeds but UI times out.
• Connected app permission copy is misleading.

Architecture drills

Drill	Expected architect-level answer	Common weak answer
Billing form data is lost after session refresh.	Classify data sensitivity, preserve safe draft state, refresh session without clearing form, and define recovery copy and telemetry.	Store the whole form in localStorage.
A third-party script needs to run on account settings.	Classify purpose/data access, isolate or deny sensitive routes, update CSP and script register, add owner/kill switch.	Approve it because marketing needs it.
Account update succeeds server-side but the UI times out.	Use idempotency/reconciliation, show recoverable pending state, refetch authoritative status, and trace by action/release.	Show a generic error and ask the user to retry.

Final review rubric

Use rubrics/frontend-architect-rubric with special emphasis on accessibility/security/reliability, observability, written communication, and business alignment.

Portfolio deliverables

• Threat model.
• Security header policy.
• Reliability state matrix.
• Sensitive action checklist.
• Accessibility verification packet.
• Incident runbook.
• Launch review summary.

Completed artifact targets

By the end, the capstone should include:

• one browser threat model using part-xii/completed-examples/completed-threat-model-example
• one completed security/reliability review using review-packets/security-reliability-review-packet
• one CSP rollout ADR
• one incident drill and postmortem using Part XII templates

Use capstones/solution-packs/capstone-solution-pack-secure-account-portal and part-xii/completed-examples/completed-client-side-security-privacy-review as calibrated examples of a strong final answer.