Episode 6 · Module 2 · How the Web Works

How Web Apps Actually Work

18 May 2026 · 10:00 · Security for Legal SaaS

0:00 10:00

Every time a lawyer clicks “Open Case File,” an invisible HTTP conversation happens. In this episode, Alice and Dan break down requests and responses, cookies and sessions, REST APIs and the browser trust boundary — the foundational mechanics that every security control in this series builds upon.

Today’s Lesson

Security for Legal SaaS — Episode 6: How Web Apps Actually Work

The Invisible Machine

Every time a lawyer clicks "Open Case File" in their practice management system, an invisible conversation happens. The browser sends a request across the internet, a server processes it, and a response comes back — all in under 300 milliseconds. Understanding this conversation is the foundation of every security control that follows.

Most legal SaaS vulnerabilities exploit gaps in this conversation. The browser trusts the server to send safe content. The server trusts the browser to send valid requests. Attackers exploit both assumptions.

Key stat: Web applications were the attack vector in 26% of all breaches in 2023, making them the single most exploited category according to the Verizon DBIR.

The Request/Response Cycle

HTTP (HyperText Transfer Protocol — the text-based language that web browsers and servers use to exchange information) is the language browsers and servers speak. Every interaction follows the same pattern:

Client sends a request — a method (GET, POST, PUT, DELETE), a path (/api/cases/12345), headers, and optionally a body
Server processes it — authenticates the user, validates the input, queries data, applies business logic
Server returns a response — a status code (200 OK, 403 Forbidden, 500 Internal Server Error), headers, and a body

HTTP Method	Purpose	Legal SaaS Example
GET	Retrieve data	Load a case file listing
POST	Create a resource	Upload a new document
PUT/PATCH	Update a resource	Edit matter notes
DELETE	Remove a resource	Archive a closed case

Every request carries headers — metadata about the request. Security-critical headers include Authorization (who you are), Content-Type (what you're sending), and Origin (where the request came from). Attackers routinely manipulate these.

Clients, Servers, and the Trust Problem

The client is anything sending requests — a browser, a mobile app, a command-line tool, or an attacker's script. The server is the system that processes them.

Critical principle: The server cannot trust anything the client sends. HTTP requests can be crafted, modified, or replayed by anyone with a network connection. OWASP's Testing Guide emphasises that every client-supplied value — URLs, headers, cookies, form fields, hidden fields — must be treated as potentially malicious.

In legal SaaS, this matters acutely. A matter management system might send the matter ID in the URL: GET /api/matters/4521/documents. If the server only checks "is this user logged in?" without checking "does this user have access to matter 4521?", any authenticated user can enumerate and access every matter by changing the number. This is Insecure Direct Object Reference (IDOR), consistently in the OWASP Top 10.

Cookies, Sessions, and State

HTTP is stateless — each request is independent. The server doesn't inherently know that request #47 comes from the same user as request #46. Cookies solve this by storing a session identifier in the browser that gets sent with every subsequent request.

Session Mechanism	How It Works	Security Consideration
Server-side sessions	Cookie holds opaque ID; server stores state	Session fixation, session hijacking
JWTs (JSON Web Tokens)	Token holds claims, signed by server	Token theft, no server-side revocation
OAuth tokens	Delegated access via tokens	Token leakage, scope creep

Session Security Requirements

HttpOnly flag — prevents JavaScript from reading the cookie (mitigates XSS token theft)
Secure flag — cookie only sent over HTTPS
SameSite attribute — restricts cross-origin cookie sending (mitigates CSRF attacks)
Short expiry + rotation — limits the window of stolen session exploitation

NIST SP 800-63B recommends session timeouts proportional to the sensitivity of the data. For legal SaaS handling privileged communications, session durations should be aggressive — 15-30 minutes of inactivity.

APIs: REST, JSON, and Endpoints

Modern legal SaaS is typically a single-page application (SPA) communicating with a REST API (REST stands for Representational State Transfer — an architectural style where each URL represents a resource, and you use standard HTTP methods like GET and POST to interact with it). The browser loads once, then sends JSON requests to API endpoints for data.

The OWASP API Security Top 10 identifies the most critical API risks:

Risk	Description	Legal SaaS Impact
Broken Object Level Auth	Accessing other users' objects via ID manipulation	Reading opposing party's documents
Broken Authentication	Weak token handling, credential stuffing	Unauthorised access to entire firm's data
Unrestricted Resource Consumption	No rate limiting on endpoints	Automated bulk exfiltration of case files
Broken Function Level Auth	Calling admin endpoints as a regular user	Paralegal invoking partner-only case closure

Every API endpoint is an attack surface. Each must independently verify authentication and authorisation — never assume that because the frontend only shows certain buttons, the backend is protected.

The Browser as Trust Boundary

The browser is simultaneously the user's agent and a hostile execution environment. It runs code from your server, but also code from third-party scripts, browser extensions, and potentially injected content.

The Same-Origin Policy (SOP) is the browser's fundamental security model: scripts from https://legalapp.com cannot read responses from https://bankofamerica.com. Without SOP, any website could steal data from any other website you're logged into.

Cross-Origin Resource Sharing (CORS) relaxes SOP in controlled ways. Misconfigured CORS — particularly Access-Control-Allow-Origin: * on authenticated endpoints — is a common vulnerability that allows any website to read your API responses.

Legal SaaS Browser Trust Issues

Browser extensions — a malicious extension can read DOM content of your legal SaaS, including privileged documents displayed on screen
Third-party scripts — analytics, chat widgets, and error tracking scripts have full DOM access. Supply chain attacks via compromised third-party scripts have hit thousands of websites
Local storage — tokens stored in localStorage are accessible to any JavaScript on the page, including injected scripts
DevTools — any user can inspect network traffic, modify requests, and replay them. Client-side validation is UX, not security

Putting It Together: A Legal SaaS Request

When a lawyer opens a privileged document in your SaaS platform, here is what actually happens:

Browser sends GET /api/matters/4521/docs/789 with session cookie
Server validates session cookie (authentication)
Server checks: does this user have access to matter 4521? (authorisation)
Server checks: does this user's role allow document reads? (function-level auth)
Server retrieves document from storage
Server sets response headers: Content-Type, X-Content-Type-Options: nosniff, Content-Security-Policy
Browser receives and renders the document

Every step is a potential failure point. Skip step 3, and you have IDOR. Skip step 6, and you're vulnerable to content-type sniffing attacks. Return the document without proper Content-Disposition headers, and the browser might execute embedded scripts instead of displaying a PDF.

Conclusion

Web applications are conversations between untrusted parties over an untrusted network. The browser cannot be trusted to send valid requests. The server cannot assume requests come from legitimate clients. Every security control in the episodes that follow — input validation, injection prevention, access control — builds on this foundation.

Next episode: Input Validation and Sanitisation — where we examine how to verify that what the client sends is actually what you expect, before it touches your business logic.

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 6 — How Web Apps Actually Work. Alice, we’ve spent five episodes talking about security controls and threat models. Today we’re going underneath all of that to understand the actual machine.

Alice: Right. Because every vulnerability we’ll discuss from here on — injection attacks, cross-site scripting, broken access control — they all exploit specific parts of how web applications communicate. If you don’t understand the conversation, you can’t understand how it gets subverted.

Dan: So let’s start at the beginning. I click “Open Case File” in my legal practice management system. What actually happens?

Alice: Your browser constructs an HTTP request. It includes a method — GET in this case, because you’re retrieving data — a path like /api/matters/4521/documents, a set of headers including your session cookie, and it sends that across the internet to the server. The server processes it, checks who you are, checks whether you’re allowed to see matter 4521, fetches the data, and sends back a response. Status code 200, content-type application/json, and the document list in the body.

Dan: That sounds simple enough. Where does it go wrong?

Alice: Everywhere. The fundamental problem is trust. HTTP is a text-based protocol. Anyone can craft an HTTP request. You don’t need a browser. You can use curl, Postman, or a Python script. Which means the server cannot assume the request came from your legitimate web interface. It might have come from an attacker who stole your session cookie, or an attacker who’s just changing the matter ID in the URL to see if they can access someone else’s cases.

Dan: That last one — changing the ID — I’ve heard that called IDOR?

Alice: Insecure Direct Object Reference. It’s been in OWASP’s Top 10 under Broken Access Control for years, and it’s embarrassingly common. The frontend only shows you your own matters. But the API endpoint doesn’t actually verify ownership — it just checks “is this a valid session?” If it is, here’s the data. Any authenticated user can access any matter by guessing or incrementing IDs.

Dan: In legal SaaS, that’s catastrophic. You’d be exposing one client’s privileged litigation strategy to another client.

Alice: Or to opposing counsel if they happen to have an account on the same platform. Multi-tenant legal SaaS has to get this right at the API layer, not the UI layer.

Dan: OK, let’s talk about state. HTTP is stateless — the server doesn’t remember you between requests. How does it know I’m still logged in?

Alice: Cookies. When you authenticate, the server creates a session — either a server-side record with a random ID, or a signed token like a JWT — and sends it back as a cookie. Your browser stores it and attaches it to every subsequent request to that domain. The server reads the cookie and says, “ah, that’s the lawyer from Morrison & Partners who logged in four minutes ago.”

Dan: And if someone steals that cookie?

Alice: They are you. Full stop. That’s why cookie security flags matter enormously. HttpOnly means JavaScript can’t read it — so even if there’s an XSS vulnerability, the attacker’s script can’t grab the session cookie directly. Secure means it only transmits over HTTPS. SameSite controls whether it gets sent on cross-origin requests, which mitigates CSRF attacks.

Dan: What about JWTs? I see those everywhere in modern apps.

Alice: JWTs encode claims — user ID, roles, expiry — into a signed token. The advantage is the server doesn’t need to store session state. The disadvantage is revocation. If a user’s access should be terminated immediately — they’re fired, their account is compromised — you can’t invalidate a JWT until it expires. You need a deny-list or short expiry windows. For legal SaaS with sensitive data, I lean toward server-side sessions with aggressive timeouts. NIST 800-63B recommends timeouts proportional to data sensitivity.

Dan: Let’s talk about APIs. Most modern legal SaaS is a single-page app talking to a REST API, right?

Alice: Correct. The browser loads the application once, then communicates with the server entirely through JSON API calls. POST to create, GET to read, PUT to update, DELETE to remove. Each endpoint is a separate attack surface. The OWASP API Security Top 10 came out in 2023 specifically because API-first architectures introduced new vulnerability patterns that the traditional web Top 10 didn’t cover well.

Dan: Like what?

Alice: Unrestricted resource consumption — no rate limiting. An attacker writes a script that calls your document search endpoint in a loop and downloads every document in the system. Broken function-level authorisation — the frontend only shows admin buttons to admins, but the API endpoint doesn’t check roles, so anyone who knows the URL can call it. These are architecture-level mistakes. You can’t patch them with a WAF.

Dan: Now, the browser itself. You called it a trust boundary?

Alice: The browser is simultaneously your user’s agent and a hostile execution environment. It runs your code, but it also runs third-party analytics scripts, advertising scripts, browser extensions. The Same-Origin Policy is the browser’s fundamental security boundary — scripts from your domain can’t read responses from other domains. But that only works if you don’t misconfigure CORS to allow any origin, and if you don’t have XSS vulnerabilities that let attackers inject scripts running in your origin.

Dan: And third-party scripts you intentionally include?

Alice: They have full DOM access within your origin. If your error tracking library is compromised — and supply chain attacks on JavaScript libraries happen regularly — the attacker’s code can read everything on the page. Including that privileged contract your user just opened. For legal SaaS, every third-party script is a supply chain risk that should be evaluated, pinned to specific versions, and monitored.

Dan: What about client-side validation? If I validate a form field in the browser, is that security?

Alice: It’s UX. Not security. The browser is the attacker’s machine. They can modify or bypass any JavaScript. Client-side validation prevents accidental invalid input from legitimate users. Server-side validation prevents deliberate malicious input from attackers. You need both, but only the server-side one is a security control.

Dan: So the summary is — everything runs on HTTP requests and responses, the server can’t trust anything from the client, cookies maintain state but must be protected, APIs are individually attackable endpoints, and the browser is a controlled execution environment that’s only controlled if you get the details right.

Alice: That’s the machine. Every vulnerability we discuss going forward — input validation failures, injection attacks, XSS, broken auth — maps back to a specific failure in this conversation between client and server.

Dan: Next episode — Input Validation and Sanitisation. How do you verify that what the client sends is what you expect, before it ever touches your database or business logic?

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.