PS Product SecurityKnowledge Base

🌐 Web Application Security Review and Architecture Playbook

Intro: A lot of web security guidance becomes more useful when you stop treating it as a scanner topic and start treating it as an architecture + code review + browser trust-boundary topic. This page is a practical review playbook for modern web applications, APIs, SPAs, and mixed frontend/backend systems.

What this page includes

  • how to review a modern web application by trust boundary instead of bug class alone;
  • the checks that still matter most for sessions, tokens, browser behavior, and API access;
  • how to interpret older web security books in a modern SPA/API-heavy world;
  • concise review prompts that point back into deeper KB pages.

Start with the architecture, not the payload list

A good review starts with four questions:

  1. What talks directly to the browser?
  2. Where is identity established and refreshed?
  3. Which backend endpoint actually enforces authorization?
  4. Which data stores, third-party services, or background jobs can be reached after compromise?

This moves the review from “can I find XSS?” to “what happens if this layer is fooled, bypassed, or abused?”

A practical trust-boundary map

Browser boundary

Review:

  • cookies and storage choices;
  • CSP, framing, and mixed-content behavior;
  • where tokens are stored;
  • whether sensitive decisions are trusted merely because JavaScript hid a button.

Application edge

Review:

  • route exposure and weak admin paths;
  • input handling and content-type assumptions;
  • upload and download behavior;
  • cache headers for sensitive responses;
  • rate limits and abuse protections.

Identity boundary

Review:

  • session lifecycle;
  • token issuance and refresh;
  • MFA or step-up rules;
  • invite, reset, recovery, and device enrollment flows;
  • logout and session revocation.

Data and integration boundary

Review:

  • object-level authorization;
  • tenant isolation;
  • background jobs with privileged service accounts;
  • third-party webhooks and callback validation;
  • export/report endpoints and indirect data leaks.

The highest-value review topics

1) Authentication and session handling

Ask:

  • Are browser sessions cookie-backed or token-backed?
  • If cookies are used, are Secure, HttpOnly, and appropriate SameSite attributes present?
  • If tokens are used in the browser, where are they stored and what can script access reach?
  • Can reset, invite, magic-link, or OAuth callback flows be replayed or confused?
  • Are session transitions clear across login, logout, MFA, password reset, and account recovery?

2) Authorization and object access

Most serious modern web issues are authorization flaws, not classic form bugs.

Review:

  • object ID predictability;
  • missing ownership checks;
  • role checks in UI only;
  • admin endpoints hidden but not actually protected;
  • background jobs that act on behalf of a user without verifying scope.

3) Browser trust assumptions

Review:

  • does the application rely on client-side checks for security decisions?
  • is CSP deliberate or cargo-culted?
  • are cross-origin rules understood for APIs, uploads, and embedded widgets?
  • can the application be framed, embedded, or abused through postMessage confusion?

4) Input, output, and parser boundaries

Classic bugs still matter:

  • XSS;
  • injection;
  • file upload parsing;
  • template injection;
  • unsafe markdown or rich text rendering;
  • archive extraction and image-processing abuse.

But review them where they matter most:

  • rendering surfaces;
  • background parsers;
  • admin tooling;
  • import/export paths.

5) Third-party dependency and integration risk

Review:

  • what frontend packages or UI libraries are used;
  • whether important auth or crypto behavior is delegated to unreviewed packages;
  • whether payment, analytics, or support widgets expand the trust boundary;
  • whether third-party scripts run with more page access than they need.

Secure-coding anti-patterns worth calling out explicitly

Blacklists as a primary defense

Bad for validation, file type restrictions, and route protection.

Trust-by-default

For example: “if the request reached this function, the caller must already be allowed.”

UI-driven security

A hidden menu item or disabled button is not authorization.

Boilerplate copied without ownership

Security-sensitive middleware, auth helpers, and proxy configuration often drift because nobody owns them after copy-paste.

A modern review sequence

  1. map routes, APIs, roles, and trust boundaries;
  2. identify where identity is issued and where authorization is actually enforced;
  3. review storage of secrets, tokens, cookies, and browser-accessible state;
  4. review highest-risk workflows first: login, reset, invite, export, admin, billing, file handling;
  5. run automation for headers, passive DAST, contract linting, and dependency review;
  6. perform manual authz and business-workflow checks on the changed flows;
  7. capture regression tests for every meaningful bug fix.

A minimal browser and API review checklist

  • Are session cookies properly scoped and protected?
  • Is CSRF still relevant for this app’s auth model, and if so, is it actually enforced?
  • Does every sensitive API endpoint perform server-side authorization?
  • Are object identifiers guessable or enumerable without ownership verification?
  • Do upload and download endpoints validate content, size, and storage behavior?
  • Does CSP reflect real script sources, not generic catch-all policy?
  • Are third-party scripts justified and bounded?
  • Are security headers validated in production-like responses, not just in framework defaults?

Example response-header smoke check

curl -I https://app.example.com | sed -n '1,20p'

Look for:

  • content-security-policy
  • strict-transport-security
  • x-content-type-options: nosniff
  • cache-control on authenticated responses
  • set-cookie attributes that match the session model

Example object-level access smoke check

curl -i -H "Authorization: Bearer $TOKEN_USER_A"   https://api.example.com/v1/invoices/123

curl -i -H "Authorization: Bearer $TOKEN_USER_B"   https://api.example.com/v1/invoices/123

The second request should fail unless the workflow explicitly shares access.

How to read older web security books in 2026

Still valuable:

  • thinking by architecture and trust boundaries;
  • recon as a way to understand surface area;
  • session, authorization, and data-flow review;
  • code review anti-patterns like blacklists and trust-by-default;
  • manual validation of workflow risk that scanners cannot prove.

Needs modernization:

  • some examples assume server-rendered apps are the default;
  • GraphQL, BFF, rich SPA state, and webhook-heavy systems deserve more explicit treatment now;
  • some attack classes remain educational but should be placed into today’s API, browser, and identity models.

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