Web application architecture
Map browser, edge, application, data, and integration boundaries so each user action has a clear identity, authorization, and evidence path.
The idea
Web applications commonly involve a client, application server, data services, and external dependencies. Requests cross trust boundaries, so input from clients needs validation and server-side authorization. The browser interface is not a trusted enforcement point: users can change requests or call APIs directly. Architecture also includes identity, session management, logging, and deployment configuration. A clear model helps explain both vulnerabilities and defenses.
In practice
A browser sends an invoice ID to an API. The server checks the caller’s relationship to that invoice before querying and returning data.
A common misunderstanding
Hiding a button is not access control, and a client-side check does not replace a server-side decision.
Check your understanding
Which input should a server distrust?
Think it through: Anything controlled by the client or an untrusted source, including headers, parameters, and claimed identity context.
Follow one meaningful action
Imagine a fictional learner opens their progress report. The browser may contact an edge service, an application API, and a backend that reads stored records. Additional scripts or integrations can participate without appearing as separate screens to the learner.
Draw the action across those components. Identify where the account is authenticated, where report ownership is checked, and which component returns the final content. A visual button is a user-interface feature, not the server's proof that the action is permitted.
Data crosses changing trust levels
The application receives identifiers, headers, uploaded data, and other client-controlled values. A backend-to-backend call can also carry untrusted values originally supplied by a user. Internal location does not automatically transform those values into trusted instructions.
Validate data according to its destination and authorize the resource operation independently. Safe database parameter binding prevents a syntax problem but cannot decide whether the selected report belongs to the learner.
Alternate paths need the same policy
Suppose an export job or older endpoint reaches the same reports. It needs appropriate access controls even if the main browser workflow never links to it. Cached responses and asynchronous jobs can also retain data after the original request is complete.
The architecture should show session lifecycle, logging, and deployment dependencies alongside the main request arrows. A troubleshooting or incident report then has specific places to look for evidence.
For an exercise, trace an authorized report read and a cross-account read that must fail. Mark the exact enforcement point and expected records. Add a background export and explain how the account and resource context follow it. This produces a useful model for testing and maintenance rather than a diagram whose server boxes imply trust without explaining it.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Web Security Testing Guide