# Web Application Security Architecture — Practical Intro

> **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

```mermaid
flowchart LR
    U[User Browser] --> CDN[CDN / Edge Cache]
    U --> WAF[WAF / Bot / DDoS Controls]
    CDN --> LB[Load Balancer / Reverse Proxy]
    WAF --> LB
    LB --> WEB[Web / Frontend Tier]
    WEB --> APP[Application / API Tier]
    APP --> IDP[IdP / Session / MFA]
    APP --> CACHE[Redis / Cache]
    APP --> MQ[Queue / Background Jobs]
    APP --> OBJ[Object Storage]
    APP --> DB[(Primary Database)]
    APP --> EXT[Third-Party APIs / Webhooks]
    OBS[Logs / Metrics / Traces / SIEM] <---> WEB
    OBS <---> APP
    OBS <---> DB
    MOB[Mobile App] --> APP
    EXT2[Partner / External Systems] --> APP
```

### Layer notes

| Layer                         | Why it exists                                            | Typical security concern                                     |
| ----------------------------- | -------------------------------------------------------- | ------------------------------------------------------------ |
| Browser / mobile client       | user interaction, state, rendering                       | XSS, token theft, CSRF, clickjacking, unsafe storage         |
| CDN / edge                    | performance, caching, TLS termination, traffic filtering | cache leakage, weak header policy, stale sensitive content   |
| Load balancer / reverse proxy | routing, TLS, protocol normalization                     | misrouting, weak origin trust, exposed admin paths           |
| Web / frontend tier           | static content and frontend delivery                     | dependency drift, headers, insecure redirects                |
| Application / API tier        | business logic and authz enforcement                     | BOLA/IDOR, injection, SSRF, workflow abuse                   |
| Identity tier                 | login, federation, MFA, session lifecycle                | broken auth, weak recovery, token replay                     |
| Data and job tier             | storage, async processing, privileged background actions | privilege creep, unsafe deserialization, queue abuse         |
| Integrations                  | outbound trust and inbound callbacks                     | webhook spoofing, third-party trust expansion                |
| Observability                 | security telemetry and evidence                          | missing context, weak retention, unverifiable investigations |

## 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

```mermaid
flowchart LR
    U[User Browser] --> EDGE[CDN + WAF + Bot Controls]
    EDGE --> LB[Load Balancer / Reverse Proxy]
    LB --> FE[Frontend Tier]
    LB --> API[API / App Tier]
    API --> IDP[IdP / MFA / Session Service]
    API --> AUTHZ[Central AuthZ / Policy Checks]
    API --> CACHE[Cache]
    API --> JOB[Worker / Queue]
    API --> DB[(Database)]
    API --> OBJ[Object Storage]
    API --> OUT[Outbound Proxy / Egress Policy]
    OUT --> EXT[Third-Party APIs]
    FE --> CSP[CSP / Headers / SRI]
    API --> SEC[Secrets / KMS / Vault]
    API --> DET[Audit Logs / Traces / SIEM]
    JOB --> DET
    DB --> DET
    SEG[Network Segmentation / Security Groups] --- API
    SEG --- DB
    SEG --- JOB
```

## 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:

| Need                                                  | Best fit                 |
| ----------------------------------------------------- | ------------------------ |
| turn architecture intent into developer guidance      | OWASP Proactive Controls |
| turn security expectations into explicit requirements | ASVS                     |
| turn review scope into concrete test cases            | WSTG                     |

## 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](/application-security-and-secure-sdlc/index-1/web-application-security-review-and-architecture-playbook.md)
* [Web Application Security Testing and Gate Patterns](/application-security-and-secure-sdlc/index-1/webapp-security-testing-and-gate-patterns.md)
* [Frontend Security Review Playbook](https://github.com/D3One/Product-Security-Gitbook/blob/main/18-frontend-and-browser-security/frontend-security-review-playbook.md)
* [API Authentication and Authorization](/architecture-api-crypto-and-identity/index/api-authentication-and-authorization.md)
* [API Authorization, Business Flows, and Third-Party API Consumption](/architecture-api-crypto-and-identity/index/api-authorization-business-flows-and-third-party-api-consumption.md)
* [Threat Modeling Methods and Workflows](/application-security-and-secure-sdlc/index/threat-modeling-methods-and-workflows.md)
* [Compliance-to-Engineering Evidence Pass](/metrics-audit-risk-evidence-and-compliance/index-1/compliance-to-engineering-evidence-pass.md)

## 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.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/application-security-and-secure-sdlc/index-1/web-application-security-architecture-intro-and-reference-model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.