🌐 Web Application Security Architecture — Practical Intro and Reference Model

Intro: This page is a practical architecture-first introduction to web application security. It was inspired by a strong Russian-language architecture article and then updated for the KB’s 2026 model: browser trust boundaries, API-heavy backends, identity providers, edge controls, observability, and business-process prioritization.

What this page includes

• a modern reference architecture for web applications;
• a defended architecture view with security controls placed by layer;
• component-by-component threat framing;
• a short requirement set that translates architecture into engineering work.

Why start with architecture

A web application usually fails between components, not inside a single isolated bug class.

Architecture review answers five questions first:

1. where the browser trust boundary starts and ends;
2. where identity is established and refreshed;
3. where authorization is actually enforced;
4. which components are internet-facing versus internally reachable;
5. which business-critical workflows deserve stronger isolation and logging.

A modern reference architecture

Layer notes

Threat clusters by zone

Browser and frontend zone

Focus on:

• DOM and reflected XSS;
• insecure token storage;
• weak cookie settings;
• frontend-only authorization assumptions;
• risky third-party script inclusion.

Edge and delivery zone

Focus on:

• cache-control mistakes on authenticated content;
• direct-to-origin bypass paths;
• TLS/HSTS/header drift;
• bot and abuse pressure on signup, reset, search, and checkout flows.

Application and API zone

Focus on:

• broken object-level authorization;
• server-side input injection;
• SSRF and outbound fetch abuse;
• file upload and parser boundaries;
• privilege escalation in background jobs and admin features.

Data and integration zone

Focus on:

• tenant isolation failures;
• dangerous exports and bulk APIs;
• over-privileged service accounts;
• insecure message handling;
• webhook or callback signature failures.

Defended reference architecture

Where to place controls first

1) Edge and browser controls

Minimum expected controls:

• TLS everywhere, HSTS, secure header baseline;
• cache rules that avoid storing authenticated or personalized responses publicly;
• CSP, clickjacking protection, strict cookie scoping;
• abuse controls on login, reset, signup, invite, and search.

2) Identity and session controls

Minimum expected controls:

• MFA for privileged and admin accounts;
• deliberate session lifecycle and revocation behavior;
• strong recovery and password-reset design;
• step-up authentication for high-risk actions.

3) Authorization controls

Minimum expected controls:

• enforce authorization server-side, not in UI only;
• validate object ownership and tenant scope on every sensitive request;
• make admin-plane routes explicit and separately reviewable;
• review background jobs for privilege amplification.

4) Data and parser controls

Minimum expected controls:

• parameterized database access;
• file upload allowlists, storage outside web root, and size/content checks;
• safe parser choices for XML, archives, templates, and document imports;
• explicit outbound request rules for SSRF-prone features.

5) Detection and evidence controls

Minimum expected controls:

• audit logs for auth events, admin actions, exports, and policy decisions;
• actor / object / tenant context in logs;
• enough retention and integrity to support investigation and reporting;
• release-time evidence that security gates actually ran.

Practical engineering requirements

This page works best when paired with three sources of requirements:

• OWASP Proactive Controls 2024 for early secure-design and secure-coding guidance;
• OWASP ASVS 5.0 for testable application security requirements;
• OWASP WSTG for verification scenarios and review coverage.

Use them like this:

Business-process-first prioritization

Do not protect every component equally.

Protect the workflows that create unacceptable loss first:

• login and recovery;
• checkout, billing, or wallet movement;
• admin and support impersonation paths;
• export, backup, and reporting paths;
• tenant management and privileged API operations.

A good architecture isolates these workflows with:

• stronger authentication;
• tighter authorization;
• stricter logging;
• smaller network reachability;
• more deliberate deployment and change control.

A compact review sequence

1. map all browser, API, admin, and third-party trust boundaries;
2. identify where identity starts, refreshes, and terminates;
3. identify which endpoint really enforces authorization;
4. review parser boundaries: uploads, exports, markdown, XML, archives, image/document processing;
5. review outbound connectivity and SSRF exposure;
6. review background jobs and service accounts for privilege amplification;
7. verify observability, audit evidence, and rollback paths.

Use this page with

• Web Application Security Review and Architecture Playbook
• Web Application Security Testing and Gate Patterns
• Frontend Security Review Playbook
• API Authentication and Authorization
• API Authorization, Business Flows, and Third-Party API Consumption
• Threat Modeling Methods and Workflows
• Compliance-to-Engineering Evidence Pass

Sources and adaptation note

This page is inspired by and adapted from the Russian-language architecture article on RezBez, but it is intentionally translated into the KB’s own structure and updated for 2026 browser/API/identity realities rather than copied as a mirror.

Recommended source material:

• RezBez article on cybersecure web-application architecture
• OWASP Application Security Verification Standard (ASVS)
• OWASP Top 10 Proactive Controls 2024
• OWASP Web Security Testing Guide (WSTG)
• OWASP Top 10 2021 and API Security Top 10 2023

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.