Web architecture
The fictional structure connecting browser-facing components, application services, identity, data services, APIs, administration, suppliers, monitoring, and recovery.
High School AdvancedModule A10Lesson A10.1Secure Architecture
A10.1 Secure Web Architecture Principles
Learn how professional defenders review a web system as a connected architecture rather than a collection of settings. Map assets, users, data flows, trust boundaries, identity, application logic, APIs, data services, administration, suppliers, monitoring, recovery, privacy, resilience, secure defaults, and owner decisions using a fully fictional Northbridge web environment.
Lesson Progress
Secure Web Architecture Principles
High School Advanced • A10: Advanced Web Security Defense • Lesson 1 of 10
10% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
A Secure Web App Is More Than the Page the User Sees
A fictional support portal can have a polished login page and still have weak architecture. The application may depend on identity, data, APIs, suppliers, administration, monitoring, and recovery services with very different trust and privilege assumptions.
Professional defenders therefore ask architecture questions first: what must be public, what must remain internal, where trust changes, who owns each dependency, which data crosses each boundary, how administrative privilege is separated, what happens when a service fails, and whether defenders can still observe important state.
Weak architecture thinking
“The portal has authentication, so the architecture is secure.”
Defender architecture thinking
“Authentication is one layer. We also need explicit trust boundaries, authorization, data protection, API contracts, administrative separation, monitoring, resilience, recovery, privacy, and owner accountability.”
Learning Objectives
Five Objectives for A10.1
Objective 1
Explain how secure web architecture connects business purpose, assets, users, trust boundaries, data flows, identity, application services, APIs, data stores, administrative functions, suppliers, monitoring, and recovery.
Objective 2
Evaluate fictional web architectures using least exposure, secure defaults, separation of responsibilities, least privilege, resilience, observability, privacy, and owner accountability.
Objective 3
Distinguish architecture dependencies from security assumptions and explain why every trust boundary and dependency should have an owner, purpose, expected behavior, and review condition.
Objective 4
Use fictional evidence to identify architecture-level strengths, weaknesses, Unknowns, single points of failure, excessive trust, monitoring gaps, and recovery dependencies without offensive exploitation.
Objective 5
Create a professional fictional Web Architecture Review package containing assets, data flows, trust boundaries, owners, security goals, assumptions, design decisions, risks, validation questions, and public-safe diagrams.
Why It Matters
Architecture Determines Which Security Decisions Are Even Possible
If administrative capability is mixed into ordinary user functions, if monitoring depends on the same component it is supposed to observe, if recovery cannot function without a failed dependency, or if one service holds every privilege, later controls may be forced to compensate for a weak architecture.
Secure architecture reduces unnecessary trust and exposure before individual controls are configured. It also makes ownership, monitoring, failure, recovery, privacy, and review easier to reason about.
Advanced Vocabulary
Secure Web Architecture Language
Asset
A fictional system, service, data set, account, API, workflow, administrative function, secret class, or business capability that needs protection.
Trust boundary
A conceptual point where data, identity, privilege, ownership, environment, or control assumptions change and should be re-evaluated.
Data flow
A fictional movement of information between users, browsers, application services, identity systems, APIs, data services, suppliers, or monitoring systems.
Attack surface
In A10, a high-level defensive concept describing which fictional components or interfaces are exposed to interaction. This lesson does not teach exploitation of those interfaces.
Least exposure
A design principle that keeps fictional services, administrative functions, data, and interfaces available only to the users or systems that need them.
Secure default
A fictional design state that starts with restrictive, safe assumptions and requires deliberate owner approval before adding access, exposure, or capability.
Separation of responsibilities
Dividing fictional browser, application, identity, data, administrative, monitoring, and recovery duties so one component does not unnecessarily hold every privilege.
Dependency
A fictional internal or third-party service that another component needs for authentication, data, messaging, monitoring, storage, recovery, or another business function.
Single point of failure
A fictional component whose failure could stop a critical service because no acceptable alternate path or recovery design exists.
Observability
The ability of fictional defenders and service owners to understand important system state through approved logs, health signals, audit records, and monitoring sources.
Resilience
A fictional system's ability to continue critical business functions, recover safely, and maintain essential visibility when one component or dependency fails.
Assumption
A fictional statement believed to be true for the architecture review but not yet fully validated.
Compensating control
A fictional defensive measure that reduces risk when the preferred architecture change cannot yet be implemented.
Architecture decision record
A fictional document explaining a design choice, security goal, alternatives, tradeoffs, owners, validation, residual risk, and review triggers.
Core Framework
Ten Secure Web Architecture Principles
1
Start with business purpose
A web system exists to support a fictional user or business capability. Security decisions should protect that purpose rather than treat controls as isolated settings.
Defender question
Which users, workflows, data, service levels, and business outcomes must the architecture protect?
2
Map trust boundaries
Browser-to-application, application-to-identity, application-to-data, application-to-API, administration, supplier, monitoring, and recovery relationships all involve different trust assumptions.
Defender question
Where does identity, privilege, ownership, environment, or data sensitivity change?
3
Use least exposure
Public-facing functions should not automatically expose administrative, data, monitoring, or recovery functions.
Defender question
Which fictional component truly needs to be reachable by which user or service?
4
Separate responsibilities
A single fictional component should not unnecessarily hold browser-facing duties, administrative privilege, identity authority, data control, and recovery access at the same time.
Defender question
Can responsibilities be separated so one failure does not grant excessive capability?
5
Use secure defaults
Default architecture states should minimize access, privilege, data exposure, and optional capability until an owner approves a business need.
Defender question
What is the safest reasonable default if no exception has been approved?
6
Treat dependencies as governed trust
Internal and third-party services may be necessary, but they should have purpose, owner, expected behavior, monitoring, failure planning, and re-review conditions.
Defender question
What would change if this fictional dependency became unavailable, unexpected, or no longer trusted?
7
Design observability
Important authentication, access, configuration, administrative, application, dependency, and recovery events should be visible to the correct fictional owners.
Defender question
Which defender questions must the architecture be able to answer later?
8
Design for failure
A secure architecture assumes components, suppliers, monitoring sources, and recovery paths can fail.
Defender question
What critical business function continues if one fictional component or dependency becomes unavailable?
9
Protect privacy by architecture
Minimization, data classification, separation, retention, access, logging, and supplier handling should be designed before unnecessary data spreads across the system.
Defender question
Can the same fictional business goal be achieved with less personal or sensitive information?
10
Make ownership explicit
Architecture risks remain unresolved when no one owns the service, dependency, trust assumption, exception, monitoring source, or recovery decision.
Defender question
Who owns this fictional component, decision, validation, and re-review?
Professional Workflow
The Ten-Step Web Architecture Review Workflow
1. Define purpose and scope
Identify the fictional web service, user groups, business workflows, security goals, sensitive data, availability needs, privacy goals, owners, exclusions, and public-safe boundaries.
Output
Architecture review charter.
2. Inventory assets
List browser-facing components, application services, identity services, data services, APIs, administrative functions, suppliers, monitoring sources, recovery services, and important data classes.
Output
Asset and owner register.
3. Map data flows
Describe how fictional users and services exchange authentication context, requests, responses, case data, reporting data, administrative actions, monitoring events, and recovery information.
Output
High-level data-flow map.
4. Mark trust boundaries
Identify where identity, privilege, network environment, application responsibility, data sensitivity, supplier ownership, or administrative authority changes.
Output
Trust-boundary map.
5. Review exposure
Ask which fictional functions must be user-facing, service-facing, administrator-only, internal, monitored, or recovery-only.
Output
Exposure and access-purpose matrix.
6. Review dependencies
Document internal and supplier dependencies, expected behavior, owners, service importance, monitoring, alternatives, failure effect, and recovery expectations.
Output
Dependency register.
7. Review observability
Identify which important fictional state changes and decisions must be visible to application, identity, service, monitoring, privacy, and recovery owners.
Output
Defender-question and visibility map.
8. Review resilience
Identify single points of failure, alternate workflows, recovery paths, dependency failure modes, monitoring dependencies, and acceptable degraded operation.
Output
Resilience and continuity map.
9. Record architecture decisions
For each important design choice, document security goal, alternatives, tradeoffs, owner, assumptions, validation, residual risk, and review triggers.
Output
Architecture decision records.
10. Review and improve
Prioritize fictional architecture findings, assign owners, define validation questions, record accepted risk, and set re-review conditions after meaningful change.
Output
Web architecture review package.
Fake Dashboard
Fictional Northbridge Web Architecture Dashboard
A10.1 — architecture review only
Architecture zones
9
Browser, application, identity, data, APIs, administration, monitoring, recovery, and supplier
Core evidence records
8
Architecture, service-owner, data, API, monitoring, recovery, supplier, and change records
Trust boundaries
8
Every boundary requires a defensive question rather than automatic trust
Primary design rule
Least exposure
Only users and services that need a capability should receive it
Fictional Architecture
Nine Northbridge Web Architecture Zones
Zone A — Browser / User Interface
Purpose
Presents the fictional Support Portal to approved users and collects only the information needed for supported workflows.
Trust principle
Treat browser-originated state and data as untrusted until validated by the application and relevant owners.
Key questions
Which data is displayed? Which actions are available? Which state belongs only on the server side? Which privacy and session assumptions apply?
Zone B — Application Service
Purpose
Coordinates fictional business logic, user workflows, authorization checks, validation, service calls, and response generation.
Trust principle
Acts as a central decision point but should not assume that browser, API, supplier, or identity data is automatically trustworthy.
Key questions
Which responsibilities belong here? Which privileges are necessary? Which actions require independent authorization and audit?
Zone C — Identity Service
Purpose
Provides fictional authentication, session, recovery, and identity context to approved web services.
Trust principle
Identity information should be validated, scoped, monitored, and kept separate from application authorization decisions.
Key questions
Which identity facts are needed? How does recovery work? How does session state affect risk? Which owner reviews high-risk changes?
Zone D — Data Service
Purpose
Stores fictional account, case, reporting, and service information under controlled access.
Trust principle
Data sensitivity, ownership, purpose, access need, retention, backup, and monitoring should be explicit.
Key questions
Which data classes exist? Who may access them? How are administrative and application access separated? Which data should not be stored?
Zone E — API Services
Purpose
Provides fictional internal service contracts for account, case, reporting, and administrative workflows.
Trust principle
Every caller, action, resource, input, output, and dependency relationship needs explicit defensive expectations.
Key questions
Who calls the API? What may they do? Which objects do they own? Which requests are valid? Which events should be logged?
Zone F — Administrative Functions
Purpose
Supports fictional privileged service configuration, user support, workflow administration, and security-sensitive changes.
Trust principle
Administrative capability should be separated, least-privileged, strongly owned, monitored, and inaccessible to ordinary users.
Key questions
Which actions are privileged? Who approves access? How are changes reviewed? Which emergency paths exist and how are they governed?
Zone G — Monitoring and Audit
Purpose
Receives fictional security, health, access, application, configuration, dependency, and recovery events needed for defender questions.
Trust principle
Monitoring should preserve source health, integrity, privacy, ownership, and decision relevance.
Key questions
Which events answer real defender questions? Which data should be minimized? What happens when a source becomes Degraded or Blind?
Zone H — Recovery and Continuity
Purpose
Supports fictional backup, restoration, alternate workflow, configuration recovery, and service continuity planning.
Trust principle
Recovery needs separate ownership, dependency awareness, validation, monitoring, rollback, and return-to-service criteria.
Key questions
Which dependencies must exist for recovery? Which state is trusted? What business gap is acceptable? How is successful recovery validated?
Zone I — Supplier / External Dependency
Purpose
Provides a fictional third-party service required for a limited business function.
Trust principle
Supplier access should be purpose-limited, owner-approved, monitored, documented, and designed for failure or change.
Key questions
Why is the dependency needed? What data is shared? Which service level matters? What happens if the supplier is unavailable or changes behavior?
Fake SOC Alert
Fictional Architecture Review Warning
Source: A10.1 design-review board • Time: Northbridge architecture review 10:15
A proposed portal redesign would place administrative configuration functions inside the same browser-facing pathway used by ordinary support users, with no separate owner, privilege boundary, monitoring requirement, or rollback plan.
Defensive recommendation: Do not approve the architecture as written. Separate privileged administrative responsibility from ordinary user functions, define explicit identity and authorization requirements, minimize exposure, assign an owner, add change monitoring and validation, and document rollback and re-review conditions.
Trust Boundaries
Eight Boundaries That Must Never Be Treated as Automatic Trust
Browser → Application
What changes
Data and actions move from a user-controlled fictional environment into server-side business logic.
Defender focus
Validation, session context, authorization, safe output, error handling, request purpose, privacy, and monitoring.
Not proof
A browser request is not automatically trusted because it came from an authenticated user.
Application → Identity
What changes
Application decisions depend on identity and session context owned by another fictional service.
Defender focus
Identity purpose, session lifecycle, recovery, failure behavior, data minimization, monitoring, and service ownership.
Not proof
Identity confirmation does not automatically authorize every application action.
Application → Data
What changes
Business logic requests access to fictional sensitive or important records.
Defender focus
Least privilege, object ownership, service identity, data classification, logging, retention, backup, and audit.
Not proof
Application connectivity does not mean every data action is permitted.
Application → API
What changes
The application becomes a caller of another fictional service contract.
Defender focus
Caller identity, authorization, schemas, ownership, errors, versioning, monitoring, resilience, and dependency trust.
Not proof
Internal service status does not eliminate the need for authorization and validation.
Application → Supplier
What changes
Data or service requests cross into a fictional third-party ownership domain.
Defender focus
Business purpose, data minimization, expected behavior, contractual role, monitoring, outage planning, and re-review.
Not proof
A contracted supplier is not automatically trusted for unlimited data or capability.
Administrator → Administrative Function
What changes
A fictional user receives higher-impact capability than ordinary service users.
Defender focus
Strong identity, least privilege, approval, separation, logging, change review, session controls, and emergency access governance.
Not proof
Employment role or seniority does not automatically justify every administrative capability.
Production → Monitoring
What changes
Security and operational events leave source systems and enter fictional visibility pipelines.
Defender focus
Source health, integrity, minimization, retention, access, correlation, alert quality, and privacy.
Not proof
A collected log does not automatically mean the event is complete, independent, or correctly interpreted.
Production → Recovery
What changes
Fictional operational state must be preserved or restored through separate resilience processes.
Defender focus
Trust, provenance, dependencies, owner approval, validation, rollback, re-containment, and monitoring.
Not proof
A backup or available service does not automatically mean recovery is trustworthy or complete.
Fake Log Panel
Fictional Architecture Review Log
training-log-viewer.log
10:00 | CHARTER | service=SupportPortal | purpose=case-support | scope=fictional-only 10:03 | ASSET | Identity-I | owner=IdentityOwner | criticality=High 10:04 | ASSET | Data-D | owner=DataOwner | sensitivity=High 10:05 | BOUNDARY | Browser-to-App | trust=validate-and-authorize 10:06 | BOUNDARY | App-to-Identity | authentication-not-authorization=true 10:07 | BOUNDARY | App-to-Supplier | data_minimized=true | owner=SupplierOwner 10:09 | MONITORING | source=M | health=Healthy | recovery_dependency=true 10:11 | RECOVERY | R-depends-on=Identity-I,Data-D,Monitoring-M 10:15 | REVIEW | admin-path-mixed-with-user-path=true | approval=hold
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Analyze the Architecture Change
ARCH-08 proposes a new browser-to-reporting relationship.
The change would alter an existing trust boundary.
Authorization ownership, data handling, monitoring, and rollback are not yet documented.
No supplied evidence proves the design is insecure.
What is the strongest interpretation of ARCH-08?
Fictional Evidence
Northbridge Architecture Evidence Set
ARCH-01Current
Fictional architecture diagram
Observation
The Support Portal connects to Identity I, Data D, API P, Monitoring M, Recovery R, and Supplier S.
Supports
A high-level dependency and trust-boundary review.
Limits
The diagram does not prove that permissions, validation, monitoring, or resilience are correct.
Review use
Asset inventory, boundary mapping, dependency review, and owner questions.
ARCH-02Current
Fictional service-owner note
Observation
Administrative Console F is used only for privileged configuration and support operations.
Supports
Administrative separation as an explicit design goal.
Limits
Does not prove the console is inaccessible to ordinary users or that privilege is minimal.
Review use
Administrative access, session, logging, approval, and monitoring review.
ARCH-03Current
Fictional data inventory
Observation
Case Data D contains support case content, service metadata, and minimized fictional user contact fields.
Supports
Data classification, privacy, access, retention, logging, and recovery review.
Limits
Does not prove data minimization or retention is implemented correctly.
Review use
Privacy and data-governance questions.
ARCH-04Conditional
Fictional API contract summary
Observation
API P documents caller roles and resource categories, but object-ownership rules are not fully described.
Supports
A useful API contract exists but one authorization assumption remains incomplete.
Limits
Does not prove an access-control failure.
Review use
Record an architecture Unknown and assign API/application owners.
ARCH-05Healthy
Fictional monitoring design
Observation
Authentication, authorization decisions, administrative changes, application errors, configuration changes, and recovery events are monitored.
Supports
Good high-level observability coverage.
Limits
Does not prove alert quality, complete source health, appropriate retention, or privacy minimization.
Review use
Monitoring coverage and defender-question review.
ARCH-06Current
Fictional recovery map
Observation
Recovery R depends on Identity I, Data D, and Monitoring M for staged validation.
Supports
Recovery is treated as an architecture dependency rather than an isolated backup function.
Limits
Does not prove recovery points are trustworthy or that recovery targets are met.
Review use
Resilience, dependency, and single-point-of-failure review.
ARCH-07Current
Fictional supplier record
Observation
Supplier S receives only a limited fictional service identifier and status value for one support function.
Supports
Purpose limitation and data minimization are design goals.
Limits
Does not prove all supplier processing, retention, access, or failure handling is acceptable.
Review use
Third-party trust, privacy, monitoring, and failure-planning review.
ARCH-08Current
Fictional change record
Observation
A planned feature would allow the browser-facing portal to call a new reporting function directly rather than through the existing application service.
Supports
A meaningful architecture change is proposed.
Limits
Does not prove the design is insecure.
Review use
Review trust-boundary change, exposure, authorization ownership, data handling, monitoring, and rollback before approval.
Architecture Decisions
Six Fictional Design Decisions
Keep administrative functions separate
Reason
Privileged configuration and support operations should not share the same exposure and user pathways as ordinary portal actions.
Tradeoff
Additional ownership and operational complexity.
Validation
Confirm ordinary users cannot reach administrative capabilities and privileged changes remain auditable.
Route business actions through the application service
Reason
Centralized server-side business logic can keep authorization, validation, ownership, logging, and service coordination consistent.
Tradeoff
The application service becomes a critical component that needs resilience and observability.
Validation
Confirm important decisions remain server-controlled and recovery/monitoring dependencies are documented.
Separate identity from application authorization
Reason
Identity answers who or what the caller is; the application still decides what the caller may do.
Tradeoff
More explicit policy design and owner coordination.
Validation
Review resource/action decisions independently of successful sign-in.
Minimize supplier data
Reason
Supplier S needs only limited fictional service context, not full support-case content.
Tradeoff
May require translation or integration logic inside the application.
Validation
Review shared data fields, purpose, retention, monitoring, and failure behavior.
Preserve monitoring during recovery
Reason
Recovery decisions require healthy fictional evidence rather than blind restoration.
Tradeoff
Monitoring becomes a recovery dependency that must itself be resilient.
Validation
Confirm recovery validation sources are Healthy before staged progression.
Use explicit architecture change review
Reason
New browser-facing or supplier relationships can alter trust boundaries, exposure, ownership, data flow, and monitoring needs.
Tradeoff
Changes require structured review before release.
Validation
Document the changed boundary, owner, security goal, validation evidence, rollback, and re-review trigger.
Scenario Decision Lab
Scenario Decision Lab 1: The Convenient Admin Feature
A fictional product team wants to add administrative configuration controls directly into the ordinary Support Portal because it would be convenient for senior staff. The proposal does not define a separate privileged role, monitoring, approval workflow, or recovery plan.
Resilience
Six Fictional Failure Scenarios
Identity Service I unavailable
Business effect
New fictional sign-ins and some session/recovery functions may be unavailable.
Design question
Which already-established sessions remain acceptable, and which business functions should enter a safe degraded state?
Defensive response
Use predefined continuity rules, user communication, monitoring, and owner-approved recovery rather than improvised bypass.
Monitoring M Degraded
Business effect
The application may still operate, but defenders lose confidence in important visibility.
Design question
Which high-risk changes or recovery actions should pause when required monitoring is unhealthy?
Defensive response
Limit absence claims, preserve Unknowns, use alternate evidence, and define whether critical changes must wait.
Supplier S unavailable
Business effect
One fictional support capability is reduced.
Design question
Can the portal continue core support work without the supplier?
Defensive response
Use a planned alternate workflow, bounded retry/failure behavior, user communication, and owner review.
Data Service D unavailable
Business effect
Primary support-case functions may stop.
Design question
Which read-only, queueing, or alternate fictional business modes are acceptable, if any?
Defensive response
Use predefined continuity and recovery rather than bypassing data protections.
Administrative Console F unavailable
Business effect
Privileged configuration work is delayed while ordinary users may continue.
Design question
Which emergency changes are truly required and how are they governed?
Defensive response
Use approved emergency ownership and recovery processes rather than exposing admin capability elsewhere.
Recovery R unavailable
Business effect
Normal service may continue, but resilience is reduced.
Design question
Should high-risk changes continue while recovery capability is unhealthy?
Defensive response
Make risk acceptance explicit and prioritize restoration of recovery readiness.
Analyze the Evidence
Analyze the API Architecture Note
API P documents caller roles and resource categories.
Object-ownership rules are not fully described.
The source is Conditional because one important design area is incomplete.
No supplied evidence shows an authorization bypass.
What is the strongest response to ARCH-04?
Scenario Decision Lab
Scenario Decision Lab 2: Monitoring Is Down During a Major Change
Northbridge plans a fictional high-impact web configuration change, but Monitoring M is Degraded. The change is not an emergency, and the review plan says monitoring is required to validate important state after release.
Common Mistakes
Eight Architecture Mistakes to Avoid
Start with individual controls
Why it fails
A team may add settings without understanding trust boundaries, data flows, dependencies, business goals, or failure modes.
Professional correction
Begin with purpose, assets, users, data, boundaries, owners, dependencies, monitoring, and recovery.
Trust internal services automatically
Why it fails
Internal status does not remove the need for caller identity, authorization, validation, monitoring, or least privilege.
Professional correction
Treat every service relationship as a governed trust decision.
Treat sign-in as permission
Why it fails
Authentication answers identity; authorization answers allowed actions.
Professional correction
Keep access-control decisions independent and resource-specific.
Expose admin functions with ordinary user paths
Why it fails
Privileged operations have higher impact and different identity, monitoring, and ownership requirements.
Professional correction
Separate administrative functions, privileges, sessions, access review, and change monitoring.
Ignore supplier failure
Why it fails
A necessary third-party dependency can affect availability, privacy, data flows, and recovery.
Professional correction
Document supplier purpose, data, monitoring, outage behavior, owners, alternatives, and re-review triggers.
Make monitoring optional
Why it fails
Important changes or recovery decisions become harder to validate without healthy visibility.
Professional correction
Design monitoring as an architecture dependency with source health and owner accountability.
Assume backup equals resilience
Why it fails
Recovery also depends on trusted state, identity, data, monitoring, application behavior, owner approval, and continuity.
Professional correction
Map recovery dependencies and staged validation into the architecture.
Prove findings through exploitation
Why it fails
A10 is designed to teach secure architecture and review without offensive testing.
Professional correction
Use architecture evidence, trust assumptions, control gaps, business impact, owner decisions, and safe validation questions.
Safe Fictional Lab
Build the Northbridge Web Architecture Review
Use only the invented zones, assets, trust boundaries, evidence, and decisions on this page. The goal is architecture reasoning, ownership, resilience, privacy, and review—not exploitation or live security testing.
Phase 1 — Create the architecture charter
- • Define the fictional Northbridge Support Portal purpose, users, business workflows, security goals, availability goals, privacy goals, owners, scope, exclusions, and public-safe boundary.
- • State that no exploitation, scanning, probing, credential attacks, bypass testing, or real-system interaction is allowed.
- • Identify the primary architecture question the review should answer.
Phase 2 — Build the asset register
- • List Zone A through Zone I and assign each fictional component a purpose, owner, data class, criticality, and security goal.
- • Identify which assets are browser-facing, internal, administrative, monitoring, recovery, or third-party.
- • Mark which assets are necessary for critical business continuity.
Phase 3 — Map data flows and trust boundaries
- • Draw safe abstract arrows showing user, identity, application, data, API, supplier, monitoring, and recovery relationships.
- • Label what kind of fictional information crosses each boundary without using real requests, secrets, tokens, addresses, or payloads.
- • Write a defender question for every trust boundary.
Phase 4 — Review exposure and privilege
- • Identify which components should be public-facing, user-facing, service-only, admin-only, monitoring-only, or recovery-only.
- • Document least-exposure and secure-default assumptions.
- • Record any architecture Unknowns instead of inventing implementation details.
Phase 5 — Review dependencies and resilience
- • Document Identity, Data, API, Supplier, Monitoring, and Recovery dependencies.
- • Identify at least four fictional failure scenarios.
- • Create continuity, monitoring, owner, and recovery questions for each.
Phase 6 — Create architecture decision records
- • Write at least six design decisions.
- • For each, include security goal, alternatives, tradeoffs, owner, assumptions, validation questions, residual risk, rollback concept, and review trigger.
- • Do not use offensive proof-of-concept testing as validation.
Phase 7 — Produce findings and priorities
- • Create at least eight fictional architecture findings or review notes.
- • Classify each as Strength, Improvement, Risk, or Unknown.
- • Assign evidence, owner, business effect, validation, and re-review trigger.
Phase 8 — Build the public-safe package
- • Create an abstract architecture diagram with invented labels only.
- • Write a one-page technical review summary.
- • Write a one-page leadership summary focused on business value, major decisions, risks, owners, resilience, and next steps.
- • Remove all real or sensitive implementation details.
Lab boundary
Do not test real websites, APIs, accounts, sessions, login pages, admin panels, services, or suppliers. Do not scan, probe, enumerate, fuzz, exploit, bypass, brute-force, attempt credential access, or construct attack payloads. Use only the fictional architecture evidence supplied in this lesson.
Advanced Challenge
Redesign a Convenient but Over-Trusted Architecture
A fictional Northbridge proposal combines ordinary user functions, administration, direct reporting-service access, supplier access, and recovery control inside one web-facing application role because the product team believes one component will be easier to maintain. Redesign it using the A10.1 principles.
Separate ordinary user, administrative, application, identity, API, data, monitoring, recovery, and supplier responsibilities.
Identify at least six trust boundaries and the defender question at each boundary.
Create least-exposure rules for every component and explain which capability stays internal.
Define secure-default assumptions for user, service, and administrative access.
Create a dependency map and identify at least three single-point-of-failure concerns.
Design monitoring dependencies and state what should happen when a source is Degraded.
Create a fictional continuity plan for identity, supplier, data, and monitoring failure.
Write at least five architecture decision records with tradeoffs and validation questions.
Create a privacy-minimization review for user, case, monitoring, and supplier data.
Write a leadership summary explaining why the redesign improves security and resilience without offensive proof-of-concept testing.
Defender Habits
A10.1 Secure Web Architecture Checklist
Check Your Understanding
A10.1 Mini Quiz: Secure Web Architecture Principles
Choose your answers first. Explanations appear only after submission.
1. What should come first in a professional fictional web security architecture review?
2. Why is an authenticated user request not automatically trusted?
3. Which design best demonstrates least exposure?
4. What does a Degraded monitoring source mean for an important architecture change?
5. Why should administrative functions be architecturally separated from ordinary user functions?
6. Which is the strongest way to treat a fictional supplier dependency?
7. What is the strongest A10.1 response to an incomplete architecture assumption?
Portfolio Prompt
Portfolio Prompt: Secure Web Architecture Review
Create a fully fictional A10.1 Secure Web Architecture Review for Northbridge. Include business purpose; user groups; critical workflows; security goals; privacy goals; availability goals; scope; exclusions; owners; asset register; data classes; browser, application, identity, data, API, administrative, monitoring, recovery, and supplier zones; trust-boundary map; high-level data flows; least-exposure rules; secure defaults; dependency register; supplier purpose; administrative separation; monitoring dependencies; source-health expectations; single points of failure; continuity questions; recovery dependencies; architecture decision records; assumptions; Unknowns; compensating controls; findings; remediation owners; validation questions; accepted risk; re-review triggers; technical summary; leadership summary; and a public-safe abstract diagram. Every system, user, service, supplier, data label, event, owner, decision, and outcome must be invented.
Start with business purpose and trust boundaries before reviewing controls.
Keep authentication, authorization, application logic, data, APIs, administration, monitoring, and recovery distinct.
Treat every dependency as governed trust rather than automatic trust.
Use least exposure, secure defaults, ownership, source health, and resilience throughout the review.
Record Unknowns and assumptions instead of inventing implementation facts.
Keep the artifact abstract and public-safe with no real hosts, addresses, credentials, secrets, requests, or defensive configuration details.
Confidence / Readiness Reflection
Are You Ready for A10.2 Authentication and Session Design?
Rate your readiness from 1 to 5 for explaining secure web architecture, trust boundaries, least exposure, secure defaults, administrative separation, dependency governance, monitoring, resilience, privacy, and owner accountability.
I can explain why a web application is a connected architecture rather than only a user interface.
I can identify assets, data flows, trust boundaries, dependencies, and owners.
I can distinguish authentication from authorization at the architecture level.
I can apply least exposure and secure defaults.
I can explain why administrative capability needs stronger architectural separation.
I can treat suppliers and internal services as governed dependencies.
I can make monitoring and source health part of architecture design.
I can identify resilience and recovery dependencies.
I can document assumptions, Unknowns, architecture decisions, and review triggers.
I am ready to focus specifically on authentication and session design in A10.2.
Portfolio Build Guide
What a Strong A10.1 Portfolio Artifact Should Show
Portfolio element 1
A clear fictional business purpose and review boundary
Portfolio element 2
An asset register with owners and security goals
Portfolio element 3
An abstract architecture diagram with nine zones
Portfolio element 4
A trust-boundary map with defender questions
Portfolio element 5
High-level data flows without real requests or sensitive implementation details
Portfolio element 6
Least-exposure and secure-default decisions
Portfolio element 7
Administrative separation and privilege ownership
Portfolio element 8
Supplier purpose, minimization, monitoring, and failure planning
Portfolio element 9
Monitoring and source-health dependencies
Portfolio element 10
Recovery and continuity dependencies
Portfolio element 11
Architecture decision records with tradeoffs and validation
Portfolio element 12
Assumptions and Unknowns that remain visible
Portfolio element 13
Findings with owners and re-review triggers
Portfolio element 14
A technical summary and leadership summary
Portfolio element 15
A public-safe version containing invented abstract information only
Portfolio element 16
A reflection explaining why secure architecture can be reviewed without offensive exploitation
Key Takeaways
What You Should Remember
1.Secure web architecture begins with business purpose, users, assets, data, trust boundaries, owners, dependencies, monitoring, and recovery.
2.Authentication, authorization, application logic, data, APIs, administration, monitoring, and recovery are connected but distinct responsibilities.
3.Least exposure and secure defaults reduce unnecessary reachability, capability, privilege, and trust.
4.Internal services and suppliers still require explicit purpose, authorization, validation, ownership, monitoring, privacy, and failure planning.
5.Administrative capability should be separated from ordinary user functions because it carries different privilege and monitoring requirements.
6.Observability is an architecture dependency: important decisions become harder to validate when required sources are Degraded or Blind.
7.Resilience requires understanding single points of failure, alternate workflows, dependency behavior, recovery paths, and acceptable degraded operation.
8.Architecture diagrams and summaries are evidence sources, not proof that controls are implemented correctly.
9.Professional architecture review records assumptions, Unknowns, tradeoffs, owners, validation, residual risk, and re-review triggers.
10.A10.1 establishes the structure that A10.2 will use to examine authentication and session design in greater depth.
Safety Boundary
Secure Architecture Review — No Offensive Web Testing
Nothing in A10.1 authorizes testing real websites, APIs, accounts, sessions, login flows, administrative interfaces, suppliers, or services. Do not scan, probe, enumerate, fuzz, brute-force, exploit, bypass authentication or authorization, attempt credential access, use attack payloads, or collect private web traffic. Use only the invented architecture evidence and safe conceptual review questions supplied in this lesson.
Lesson Complete
Continue to Authentication and Session Design
A10.1 established the architecture foundation: purpose, assets, trust boundaries, least exposure, secure defaults, separation of responsibilities, dependencies, observability, resilience, privacy, and owner accountability. A10.2 will zoom into identity assurance, login design, recovery, session lifecycle, high-risk events, usability, privacy, support, and monitoring.