Web Application Security Architecture

A defense-in-depth guide to security controls, threat mitigation strategies, and implementation patterns for modern web applications—covering security headers, authentication, cryptography, and the OWASP Top 10:2025.

Abstract

Web security operates on a layered defense model where controls at each layer compensate for potential failures in others:

• Network layer: TLS 1.3 encrypts transport; HSTS prevents downgrade; WAF filters malicious requests
• Browser layer: CSP restricts resource origins and blocks inline scripts; security headers disable dangerous features
• Application layer: Authentication verifies identity; authorization enforces access boundaries; input validation rejects malformed data
• Data layer: Argon2id hashes passwords; AES-256-GCM encrypts sensitive data; secure random generation prevents predictability

The OWASP Top 10:2025 identifies Broken Access Control as the primary threat—not because it’s technically sophisticated, but because authorization logic is scattered throughout applications and easy to miss. CSP’s shift from domain allowlists to nonce-based validation represents a similar evolution: cryptographic proof of trust replaces reputation-based assumptions.

Foundational Security Principles

Security architecture rests on principles that, when consistently applied, prevent entire vulnerability classes rather than patching individual instances.

Defense in Depth

No single control is infallible. Defense in depth layers multiple independent controls so that one failure doesn’t compromise the system.

Why this design: Military fortification theory—breaching outer walls doesn’t grant access to inner keeps. Applied to software: a Cross-Site Scripting (XSS) attack that bypasses input validation still fails against a properly configured Content Security Policy (CSP).

Layer interaction:

Failure mode: Over-reliance on a single layer. A common antipattern is treating WAF as the sole XSS defense—attackers craft payloads that bypass WAF signatures but execute in browsers.

Principle of Least Privilege

Grant minimum permissions required for a specific function, nothing more.

Why this design: Limits blast radius. A compromised service account with read-only database access can’t exfiltrate data via DELETE statements or modify records.

Implementation pattern:

3 collapsed lines
1
// Least privilege: service accounts scoped to specific operations
2
const servicePermissions = {
3
  "api-read-service": {
4
    database: ["SELECT"],
5
    tables: ["users", "products"],
6
    columns: { users: ["id", "name", "email"] }, // No password_hash
7
  },
8
  "api-write-service": {
9
    database: ["INSERT", "UPDATE"],
10
    tables: ["orders", "cart"],
11
    // Cannot access users table at all
12
  },
13
}

Edge case: Temporary privilege elevation. When a user needs admin access for a specific task, grant time-bounded permissions that auto-revoke. Never grant persistent elevated access for occasional needs.

Fail Secure

Systems must default to a secure state when errors occur. Ambiguous conditions should deny access, not grant it.

Why this design: Attackers deliberately trigger error conditions to bypass controls. If authentication errors result in access granted, every exception becomes an attack vector.

Secure vs insecure failure:

1
// INSECURE: Fails open - errors grant access
2
async function checkAccess(userId, resource) {
3
  try {
4
    const allowed = await authService.check(userId, resource)
5
    return allowed
6
  } catch (error) {
7
    console.error("Auth check failed:", error)
8
    return true // Dangerous: failure grants access
9
  }
10
}
11

12
// SECURE: Fails closed - errors deny access
13
async function checkAccessSecure(userId, resource) {
14
  try {
15
    const allowed = await authService.check(userId, resource)
16
    return allowed === true // Explicit true check
17
  } catch (error) {
18
    logger.error("Auth check failed", { userId, resource, error: error.message })
19
    return false // Safe: failure denies access
20
  }
21
}

Gotcha: Error messages must not leak information. “Invalid username” vs “Invalid password” tells attackers which half of the credential pair is correct. Always use generic messages: “Invalid credentials.”

OWASP Top 10:2025

The OWASP Top 10:2025 represents a shift from symptom-based to root-cause categorization. Server-Side Request Forgery (SSRF), previously standalone, now rolls into Broken Access Control. Two new categories address supply chain and exception handling—reflecting real-world breach patterns.

A01: Broken Access Control

Position: #1 (unchanged from 2021)

Root cause: Authorization logic scattered across application code, inconsistently enforced. 3.73% of tested applications contain at least one of the 40 related CWEs (Common Weakness Enumerations).

Attack patterns:

• Insecure Direct Object Reference (IDOR): Manipulating resource identifiers (/api/users/123 → /api/users/124)
• Privilege escalation: Accessing admin endpoints without role verification
• SSRF (now consolidated here): Inducing server-side requests to internal resources

Vulnerable pattern:

1
// VULNERABLE: No authorization check - IDOR exploitable
2
app.get("/api/users/:id/documents", async (req, res) => {
3
  const documents = await db.documents.findByUserId(req.params.id)
4
  res.json(documents) // Anyone can access any user's documents
5
})

Secure implementation:

2 collapsed lines
1
// Authorization middleware
2
const requireOwnership = (resourceType) => async (req, res, next) => {
3
  const resourceId = req.params.id
4
  const userId = req.user.id
5

6
  const isOwner = await checkOwnership(userId, resourceType, resourceId)
7
  const isAdmin = req.user.roles.includes("admin")
8

9
  if (!isOwner && !isAdmin) {
10
    logger.warn("Access denied", { userId, resourceType, resourceId })
11
    return res.status(403).json({ error: "Access denied" })
12
  }
13
  next()
14
}
15

16
// SECURE: Ownership verified before data access
17
app.get("/api/users/:id/documents", authenticate, requireOwnership("user"), async (req, res) => {
18
  const documents = await db.documents.findByUserId(req.params.id)
19
  res.json(documents)
1 collapsed line
20
})

Design principle: Centralize authorization in middleware or decorators. Scattered inline checks inevitably have gaps.

A02: Security Misconfiguration

Position: #2 (up from #5 in 2021)

Root cause: Default configurations optimized for developer convenience, not production security. Debug endpoints exposed, default credentials unchanged, unnecessary features enabled.

Common misconfigurations:

Secure Express configuration:

5 collapsed lines
1
import express from "express"
2
import helmet from "helmet"
3
import rateLimit from "express-rate-limit"
4

5
const app = express()
6

7
// Security headers via helmet
8
app.use(
9
  helmet({
10
    contentSecurityPolicy: {
11
      directives: {
12
        defaultSrc: ["'self'"],
13
        scriptSrc: ["'self'"],
14
        styleSrc: ["'self'", "'unsafe-inline'"], // Review for Trusted Types
15
        imgSrc: ["'self'", "data:", "https:"],
16
        objectSrc: ["'none'"],
17
        frameAncestors: ["'none'"],
18
      },
19
    },
20
    hsts: { maxAge: 31536000, includeSubDomains: true, preload: true },
21
  }),
22
)
23

24
// Rate limiting
11 collapsed lines
25
app.use(
26
  rateLimit({
27
    windowMs: 15 * 60 * 1000,
28
    max: 100,
29
    standardHeaders: true,
30
    legacyHeaders: false,
31
  }),
32
)
33

34
// Body parsing with size limits
35
app.use(express.json({ limit: "100kb" }))
36

37
// Production error handler - no stack traces
38
app.use((err, req, res, next) => {
39
  logger.error("Request error", { error: err.message, requestId: req.id })
40
  res.status(500).json({ error: "Internal error", requestId: req.id })
41
})

A03: Software Supply Chain Failures (New)

Position: #3 (evolved from “Vulnerable and Outdated Components”)

Root cause: Transitive dependencies introduce unknown vulnerabilities. A direct dependency on package A pulls in packages B, C, D—each with their own vulnerability surface.

Attack vectors:

• Typosquatting: lodahs instead of lodash
• Dependency confusion: Internal package names shadowed by public registry
• Compromised maintainer accounts: Legitimate packages injected with malicious code
• Build pipeline compromise: CI/CD artifacts modified post-compilation

Mitigation strategy:

1
{
2
  "scripts": {
3
    "preinstall": "npm audit --audit-level=high",
4
    "postinstall": "npm audit signatures",
5
    "security:sbom": "npx @cyclonedx/cyclonedx-npm --output-file sbom.json"
6
  }
7
}

Subresource Integrity (SRI) for CDN resources:

1
<script
2
  src="https://cdn.example.com/lib.js"
3
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
4
  crossorigin="anonymous"
5
></script>

Design reasoning: SRI provides cryptographic proof that CDN-served content matches expected hashes. If the CDN is compromised, browsers reject modified files.

A04: Cryptographic Failures

Position: #4 (down from #2 in 2021)

Root cause: Using deprecated algorithms (MD5, SHA-1 for passwords), improper key management, or skipping encryption entirely.

Algorithm selection (OWASP Password Storage Cheat Sheet, 2025):

Secure password hashing:

2 collapsed lines
1
import { hash, verify } from "@node-rs/argon2"
2

3
async function hashPassword(password) {
4
  // Argon2id with OWASP-recommended parameters
5
  return await hash(password, {
6
    memoryCost: 47104, // 46 MiB
7
    timeCost: 1, // 1 iteration
8
    parallelism: 1,
9
  })
10
}
11

12
async function verifyPassword(password, hashedPassword) {
13
  return await verify(hashedPassword, password)
14
}

Why Argon2id over bcrypt: Argon2 is memory-hard, resisting GPU/ASIC attacks. bcrypt is CPU-hard only—modern GPUs can parallelize bcrypt attacks efficiently. Argon2’s memory requirements force sequential memory access patterns that GPUs cannot parallelize.

Prior to 2015: bcrypt was the gold standard. Argon2 won the Password Hashing Competition in 2015, designed specifically to resist hardware-accelerated attacks. OWASP now recommends Argon2id as primary, bcrypt only for legacy systems.

A05: Injection

Position: #5 (down from #3 in 2021)

Root cause: Untrusted data concatenated into commands or queries, interpreted as code rather than data.

Injection types:

SQL injection defense:

1
// VULNERABLE: String concatenation
2
const query = `SELECT * FROM users WHERE email = '${email}'`
3

4
// SECURE: Parameterized query
5
const [rows] = await db.execute("SELECT * FROM users WHERE email = ?", [email])

Command injection defense:

2 collapsed lines
1
import { execFile } from "child_process"
2
import { promisify } from "util"
3

4
const execFileAsync = promisify(execFile)
5

6
// VULNERABLE: Shell interpretation
7
// exec(`ping -c 4 ${host}`) // Attacker: "google.com; rm -rf /"
8

9
// SECURE: No shell, arguments as array
10
async function ping(host) {
11
  // Validate input first
12
  if (!/^[a-zA-Z0-9.-]+$/.test(host)) {
13
    throw new Error("Invalid hostname")
14
  }
15
  const { stdout } = await execFileAsync("ping", ["-c", "4", host])
16
  return stdout
17
}

A06–A10: Summary

Security Headers

HTTP security headers instruct browsers to enforce security policies. They operate at the protocol level, providing defense-in-depth against entire vulnerability classes.

Content Security Policy (CSP)

Specification: W3C CSP Level 3 (Working Draft, June 2025)

CSP restricts resource origins, blocking XSS and data exfiltration by preventing unauthorized script execution.

Why domain allowlists fail: If script-src includes cdn.example.com and that CDN is compromised, attackers serve malicious scripts from the allowlisted domain. Google research found that 94.72% of CSP policies could be bypassed due to allowlist-based configurations.

Nonce-based CSP (modern approach):

1
Content-Security-Policy:
2
  default-src 'self';
3
  script-src 'self' 'nonce-R4nd0mN0nc3' 'strict-dynamic';
4
  style-src 'self' 'nonce-R4nd0mN0nc3';
5
  object-src 'none';
6
  base-uri 'self';
7
  frame-ancestors 'none';
8
  report-to csp-endpoint

How nonces work:

1. Server generates cryptographically random nonce per response
2. Nonce included in CSP header and legitimate <script> tags
3. Browser executes only scripts with matching nonces
4. 'strict-dynamic' propagates trust to dynamically loaded scripts

3 collapsed lines
1
import crypto from "crypto"
2

3
function generateCSP(req, res, next) {
4
  const nonce = crypto.randomBytes(16).toString("base64")
5
  res.locals.nonce = nonce
6

7
  res.setHeader(
8
    "Content-Security-Policy",
9
    `
10
    default-src 'self';
11
    script-src 'self' 'nonce-${nonce}' 'strict-dynamic';
12
    style-src 'self' 'nonce-${nonce}';
13
    object-src 'none';
14
    base-uri 'self';
15
    frame-ancestors 'none';
16
  `
17
      .replace(/\s+/g, " ")
18
      .trim(),
19
  )
20

21
  next()
22
}

HTML with nonce:

1
<script nonce="R4nd0mN0nc3">
2
  // This script executes
3
</script>
4
<script>
5
  // This script blocked - no matching nonce
6
</script>

Trusted Types

Specification: W3C Trusted Types (integrated with CSP)

Trusted Types prevent DOM-based XSS by requiring type-safe objects for dangerous DOM sinks like innerHTML.

Browser support: Chrome 83+, Edge 83+. Firefox and Safari require polyfills.

Enforcement:

1
Content-Security-Policy: require-trusted-types-for 'script'; trusted-types myPolicy

1
// Create a policy that sanitizes HTML
2
const policy = trustedTypes.createPolicy("myPolicy", {
3
  createHTML: (input) => DOMPurify.sanitize(input),
4
  createScript: (input) => {
5
    throw new Error("Scripts not allowed")
6
  },
7
  createScriptURL: (input) => {
8
    const url = new URL(input, location.origin)
9
    if (url.origin !== location.origin) {
10
      throw new Error("Cross-origin scripts not allowed")
11
    }
12
    return url.toString()
13
  },
14
})
15

16
// Usage - raw strings rejected, TrustedHTML required
17
element.innerHTML = policy.createHTML(userInput)

Design reasoning: Trusted Types shift XSS prevention from “hope developers remember to sanitize” to “browser rejects unsanitized input.” Google reports 60% reduction in DOM XSS after deployment.

HTTP Strict Transport Security (HSTS)

Specification: RFC 6797

HSTS instructs browsers to only connect via HTTPS, preventing protocol downgrade attacks.

1
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HSTS preload: Browsers ship with hardcoded lists of HSTS-enabled domains. First-visit protection—users never make insecure requests to preloaded sites.

Gotcha: Once preloaded, removal takes months. Ensure all subdomains support HTTPS before enabling includeSubDomains.

Other Essential Headers

1
X-Content-Type-Options: nosniff
2
X-Frame-Options: DENY
3
Referrer-Policy: strict-origin-when-cross-origin
4
Permissions-Policy: camera=(), microphone=(), geolocation=()
5
Cross-Origin-Opener-Policy: same-origin
6
Cross-Origin-Embedder-Policy: require-corp

Authentication and Session Security

WebAuthn (Passkeys)

Specification: W3C WebAuthn Level 3 (Candidate Recommendation, January 2026)

WebAuthn enables passwordless authentication using public-key cryptography. The private key never leaves the authenticator device.

Registration flow:

5 collapsed lines
1
// Client-side registration
2
async function registerPasskey(userId, userName) {
3
  const challenge = await fetch("/api/webauthn/challenge").then((r) => r.json())
4

5
  const credential = await navigator.credentials.create({
6
    publicKey: {
7
      challenge: Uint8Array.from(challenge.value, (c) => c.charCodeAt(0)),
8
      rp: { name: "Example Corp", id: "example.com" },
9
      user: {
10
        id: Uint8Array.from(userId, (c) => c.charCodeAt(0)),
11
        name: userName,
12
        displayName: userName,
13
      },
14
      pubKeyCredParams: [
15
        { alg: -7, type: "public-key" }, // ES256
16
        { alg: -257, type: "public-key" }, // RS256
17
      ],
18
      authenticatorSelection: {
19
        authenticatorAttachment: "platform",
20
        userVerification: "required",
21
        residentKey: "required", // Discoverable credential for passkeys
22
      },
23
      timeout: 60000,
24
    },
25
  })
26

27
  await fetch("/api/webauthn/register", {
28
    method: "POST",
29
    body: JSON.stringify({
30
      id: credential.id,
31
      rawId: btoa(String.fromCharCode(...new Uint8Array(credential.rawId))),
32
      response: {
33
        clientDataJSON: btoa(String.fromCharCode(...new Uint8Array(credential.response.clientDataJSON))),
34
        attestationObject: btoa(String.fromCharCode(...new Uint8Array(credential.response.attestationObject))),
35
      },
36
    }),
37
  })
38
}

Why passkeys over passwords: Phishing-resistant by design. The authenticator verifies the relying party’s origin—users cannot accidentally authenticate to attacker-controlled sites. No shared secrets to steal from server databases.

Secure Session Management

Cookie configuration:

1
const sessionOptions = {
2
  name: "__Host-session", // __Host- prefix enforces Secure + no Domain
3
  secret: process.env.SESSION_SECRET,
4
  cookie: {
5
    httpOnly: true, // Inaccessible to JavaScript
6
    secure: true, // HTTPS only
7
    sameSite: "strict", // No cross-site requests
8
    maxAge: 15 * 60 * 1000, // 15 minutes
9
    path: "/",
10
  },
11
  resave: false,
12
  saveUninitialized: false,
13
}

SameSite attribute (RFC 6265bis):

Default behavior change: Modern browsers treat cookies without SameSite as Lax by default. Explicit SameSite=None; Secure required for legitimate cross-site use cases.

Token Storage Security

Design reasoning: HttpOnly cookies are inaccessible to JavaScript, eliminating XSS-based token theft. SameSite=Strict prevents CSRF by blocking cross-origin requests from including the cookie.

Attack Vectors and Defenses

Cross-Site Scripting (XSS)

XSS injects malicious scripts into web pages, executing in victims’ browser contexts.

Types:

DOM XSS defense with Trusted Types:

1
// Without Trusted Types - vulnerable
2
document.getElementById("output").innerHTML = userInput
3

4
// With Trusted Types - safe
5
const policy = trustedTypes.createPolicy("sanitizer", {
6
  createHTML: (input) => DOMPurify.sanitize(input),
7
})
8
document.getElementById("output").innerHTML = policy.createHTML(userInput)

Cross-Site Request Forgery (CSRF)

CSRF tricks authenticated users into performing unintended actions.

Defense layers:

1. SameSite cookies: Prevents cross-origin cookie inclusion
2. CSRF tokens: Synchronizer token pattern for state-changing requests
3. Origin/Referer validation: Verify request source

4 collapsed lines
1
import csrf from "csurf"
2

3
const csrfProtection = csrf({ cookie: { sameSite: "strict", httpOnly: true } })
4

5
app.get("/form", csrfProtection, (req, res) => {
6
  res.render("form", { csrfToken: req.csrfToken() })
7
})
8

9
app.post("/transfer", csrfProtection, (req, res) => {
10
  // Token automatically validated by middleware
11
  processTransfer(req.body)
12
})

Server-Side Request Forgery (SSRF)

SSRF induces servers to make requests to unintended destinations, often internal networks or cloud metadata services.

High-value targets:

• 169.254.169.254 - AWS/GCP metadata (credentials, tokens)
• localhost:6379 - Redis
• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 - Internal networks

Defense:

3 collapsed lines
1
import { URL } from "url"
2
import dns from "dns/promises"
3

4
const BLOCKED_HOSTS = new Set(["169.254.169.254", "metadata.google.internal", "localhost", "127.0.0.1"])
5

6
const PRIVATE_RANGES = [
7
  { start: 0x0a000000, end: 0x0affffff }, // 10.0.0.0/8
8
  { start: 0xac100000, end: 0xac1fffff }, // 172.16.0.0/12
9
  { start: 0xc0a80000, end: 0xc0a8ffff }, // 192.168.0.0/16
10
]
11

12
async function isAllowedUrl(urlString) {
13
  const url = new URL(urlString)
14

15
  // Protocol check
16
  if (!["http:", "https:"].includes(url.protocol)) return false
17

18
  // Hostname blocklist
19
  if (BLOCKED_HOSTS.has(url.hostname)) return false
20

21
  // DNS resolution to catch rebinding
22
  const addresses = await dns.resolve4(url.hostname)
23
  for (const addr of addresses) {
24
    const ip = addr.split(".").reduce((acc, oct) => (acc << 8) + parseInt(oct), 0)
25
    if (PRIVATE_RANGES.some((r) => ip >= r.start && ip <= r.end)) {
26
      return false
27
    }
28
  }
29

30
  return true
31
}

Security by Rendering Strategy

Rendering strategy determines attack surface and appropriate defenses.

Server-Side Rendering (SSR)

Attack surface: Template injection, SSRF, session fixation, CSRF

Key defenses:

• Automatic template escaping
• CSRF tokens for state changes
• Session regeneration on authentication
• Request origin validation

Static Site Generation (SSG)

Attack surface: Build-time supply chain, DOM XSS in client JS, cached vulnerabilities

Key defenses:

• Dependency scanning in CI/CD
• SRI for external resources
• Hash-based CSP (stable content allows pre-computed hashes)
• Immutable deployments

Client-Side Rendering (CSR)

Attack surface: DOM XSS, token leakage, open redirects

Key defenses:

• Trusted Types
• HttpOnly cookie tokens
• Strict CSP with nonces
• Client-side input validation (defense in depth, not primary)

Conclusion

Security architecture prioritizes controls that eliminate vulnerability classes over those that patch individual instances. Nonce-based CSP eliminates entire categories of XSS. Argon2id eliminates password cracking as a practical attack vector. HttpOnly cookies eliminate JavaScript-based token theft.

The OWASP Top 10:2025 reflects this shift—Broken Access Control remains #1 not because it’s technically sophisticated, but because it requires consistent enforcement across every endpoint. The solution is architectural: centralized authorization middleware, not scattered inline checks.

Defense in depth assumes every layer will fail. Design accordingly.

Appendix

Prerequisites

• HTTP protocol fundamentals (headers, methods, status codes)
• Basic cryptography concepts (symmetric vs asymmetric, hashing)
• JavaScript/Node.js familiarity
• Web application architecture (client-server model)

Terminology

• CSP: Content Security Policy—browser-enforced resource loading restrictions
• CSRF: Cross-Site Request Forgery—attacks that trick users into unintended actions
• HSTS: HTTP Strict Transport Security—forces HTTPS connections
• IDOR: Insecure Direct Object Reference—unauthorized resource access via ID manipulation
• OWASP: Open Worldwide Application Security Project
• SRI: Subresource Integrity—cryptographic verification of external resources
• SSRF: Server-Side Request Forgery—inducing servers to make unintended requests
• XSS: Cross-Site Scripting—malicious script injection
• WAF: Web Application Firewall—HTTP traffic filtering

Summary

• OWASP Top 10:2025 prioritizes Broken Access Control (#1) and introduces Supply Chain Failures (#3) and Mishandling Exceptional Conditions (#10)
• CSP Level 3 shifts from domain allowlists to nonce-based validation for XSS prevention
• Argon2id replaces bcrypt as the recommended password hashing algorithm
• WebAuthn Level 3 enables phishing-resistant passwordless authentication
• SameSite cookies default to Lax, mitigating CSRF by default
• Trusted Types prevent DOM XSS by requiring type-safe DOM operations
• Defense in depth: layer controls so single failures don’t compromise systems

References

Specifications

• OWASP Top 10:2025 - Current web application security risks
• W3C Content Security Policy Level 3 - CSP specification (Working Draft, June 2025)
• W3C WebAuthn Level 3 - Web Authentication API (Candidate Recommendation, January 2026)
• RFC 6797 - HTTP Strict Transport Security - HSTS specification
• RFC 6265bis - Cookies - HTTP State Management (includes SameSite)

Official Documentation

• OWASP Password Storage Cheat Sheet - Password hashing recommendations
• OWASP CSP Cheat Sheet - CSP implementation guidance
• MDN Content Security Policy - CSP documentation
• MDN Trusted Types API - Trusted Types documentation
• web.dev Trusted Types - DOM XSS prevention guide

Tools

• Security Headers - Header analysis
• Mozilla Observatory - Web security scanning
• SSL Labs Server Test - TLS configuration analysis