2. Web Architecture, Protocols and Security Boundaries

Introduction and Context

A web application is not a single program running in one place. It is a distributed system in which browsers, mobile clients, application servers, databases, identity providers, reverse proxies, content delivery networks, DNS services, operating systems, and network devices exchange data across multiple trust boundaries. A user may perceive a single page load, yet that action can involve name resolution, several encrypted connections, redirects, cookies, cached objects, API calls, and interactions with services hosted by different organisations.

Security failures often arise because developers understand individual technologies but not the boundaries between them. An application may correctly validate input at its API layer and still expose sensitive data through browser caching. A server may use HTTPS and still be vulnerable to session theft caused by weak cookie settings. A CDN may improve availability while accidentally caching personalised responses. Secure coding therefore requires architectural reasoning: one must identify where data travels, which component makes each security decision, and which assumptions are valid at each stage.

This chapter examines the principal protocols and components involved in full-stack web communication. It treats HTTP, HTTPS and TLS as security-relevant protocols rather than merely transport mechanisms; explains DNS, browsers, cookies, sessions, caching, proxies and CDNs; and relates these technologies to the same-origin policy and client–server architectures. The central theme is the idea of a security boundary: a point at which trust, authority, confidentiality, or interpretation changes.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain how a browser resolves, establishes, and uses a web connection.

2. Distinguish HTTP, HTTPS, TLS, DNS, cookies, sessions, caches, proxies, and CDNs.

3. Analyse security boundaries in browser–server and full-stack data flows.

4. Explain the purpose and limitations of the same-origin policy.

5. Design safer cookie, session, caching, proxy, and TLS configurations.

6. Evaluate architectural trade-offs involving performance, availability, privacy, and security.

7. Investigate common failures such as request smuggling, cache poisoning, CSRF, session fixation, and misconfigured cross-origin access.

A Web Request as a Chain of Security Decisions

Consider a user visiting `https://shop.example`. The browser first obtains an address through DNS. It then establishes a connection to the destination, normally using TCP with TLS for HTTP/1.1 or HTTP/2, or QUIC with TLS integrated into HTTP/3. The browser validates the server certificate, sends an HTTP request, receives a response, interprets headers and content, stores selected state, and may issue additional requests for scripts, stylesheets, images, fonts, and API data.

Each stage has a different security responsibility. DNS determines where the browser attempts to connect, but ordinary DNS does not prove that the returned address is trustworthy. TLS authenticates the endpoint named by the certificate and protects data in transit, but it does not guarantee that the application is free from vulnerabilities. HTTP defines messages and semantics, but a reverse proxy and an application server may interpret the same request differently. The browser enforces origin-based restrictions, while the server must still authenticate users and authorise actions.

A useful analytical model is to trace four properties across the request path:

• Confidentiality: Can an unauthorised party read the data?
• Integrity: Can an unauthorised party modify the data or meaning?
• Authenticity: Is the communicating endpoint or user who they claim to be?
• Authority: Is the requester permitted to perform the operation?

TLS primarily supports confidentiality, integrity, and server authentication during transit. Cookies help carry an application identifier but do not themselves establish authorisation. Application logic must make the final access-control decision.

HTTP: Semantics, State, and Exposure

HTTP is an application-layer protocol based on requests and responses. A request typically contains a method, target, headers, and optionally a body. A response contains a status code, headers, and a body. Common methods have different intended semantics: `GET` retrieves a representation, `POST` submits or creates processing, `PUT` replaces a resource, `PATCH` partially modifies one, and `DELETE` requests removal. These meanings matter for security. An operation that changes state should not be implemented as a `GET`, because browsers, crawlers, prefetchers, and caches may issue or replay GET requests unexpectedly.

HTTP is effectively stateless: each request can be understood independently at the protocol level. Applications create continuity through cookies, tokens, server-side sessions, or other mechanisms. Headers such as `Authorization`, `Cookie`, `Origin`, `Referer`, `Cache-Control`, and `Content-Type` carry information that influences security decisions. They must not be trusted merely because they came from a browser; an attacker can construct requests with tools that do not follow browser conventions.

HTTP message parsing creates an important boundary between intermediaries. If a front-end proxy interprets `Content-Length` and `Transfer-Encoding` differently from the application server, an attacker may exploit request smuggling to cause the two components to disagree about request boundaries. Defences include using well-tested servers, rejecting ambiguous messages, normalising requests consistently, and maintaining compatible proxy configurations.

Status codes also have security consequences. A careless distinction between `401 Unauthorized` and `403 Forbidden` can reveal account existence or confuse clients. Redirects must be controlled because open redirects can support phishing and token leakage. Error responses should not disclose stack traces, database details, internal hostnames, or secrets.

HTTPS and TLS: Protection in Transit

HTTPS is HTTP transported through TLS. TLS negotiates cryptographic algorithms, authenticates the server through a certificate chain, establishes session keys, and protects records against eavesdropping and alteration. The browser verifies that the certificate is valid, within its validity period, issued by a trusted certification authority, and applicable to the requested hostname.

TLS does not make an application trustworthy by itself. It cannot prevent SQL injection, broken authorisation, malicious JavaScript delivered by a compromised server, or a user voluntarily sending credentials to a fraudulent but correctly encrypted site. It also does not protect data after it reaches a reverse proxy or application process. Consequently, an organisation must define where TLS terminates and how protection continues internally.

Modern deployments should disable obsolete protocol versions and weak cryptographic options, automate certificate renewal, monitor expiry, and protect private keys. HTTP Strict Transport Security (HSTS) instructs a browser to use HTTPS for future visits. The `Secure` cookie attribute prevents a cookie from being sent over an unencrypted connection, but it is most effective when the entire site consistently uses HTTPS. Mixed content—an HTTPS page loading active content over HTTP—can undermine the security of the page and should be eliminated.

TLS termination at a CDN or load balancer improves scalability, but it introduces a new trust boundary. The internal connection to the origin should also be authenticated and encrypted where the network or threat model requires it. The origin must not blindly trust headers such as `X-Forwarded-For` or `X-Forwarded-Proto`; these are meaningful only when inserted by trusted intermediaries and processed according to a defined proxy configuration.

DNS: Naming, Discovery, and Redirection Risk

The Domain Name System maps human-readable names to records such as IPv4 addresses, IPv6 addresses, mail servers, and service aliases. A recursive resolver obtains answers from authoritative servers and may cache them according to their time to live. This improves performance but means that changes do not necessarily take effect immediately.

DNS is a discovery mechanism, not an application authorisation mechanism. An attacker who controls a DNS record, registrar account, authoritative server, or compromised resolver may redirect traffic. Even when TLS prevents interception because the attacker lacks a valid certificate, incorrect DNS can create denial of service, expose metadata, or direct users to a fraudulent service. DNSSEC can provide authenticity and integrity for DNS data when properly deployed, although it does not encrypt ordinary DNS queries or replace HTTPS.

Security teams should protect registrar and DNS-provider accounts with strong authentication, restrict record-management privileges, monitor unexpected changes, and understand dependencies such as email, identity services, APIs, and certificate validation. Subdomain takeover is another risk: a DNS record pointing to a deleted cloud resource may allow an attacker to claim that resource and serve content under the organisation’s subdomain.

Browsers as Security Enforcement Environments

The browser is both a client and a security boundary. It parses HTML, executes JavaScript, manages cookies, enforces origin restrictions, follows redirects, applies content-security controls, and decides how resources are cached. Its security model assumes that content from different origins should not freely read one another.

An origin is defined by scheme, host, and port. Thus, `https://app.example` and `http://app.example` have different origins, as do `https://app.example` and `https://api.example` because their hosts differ. The same-origin policy generally prevents a script from reading protected data from another origin. It does not prevent all communication: a page may submit a form, load an image, or send a cross-origin request subject to CORS rules. This distinction is crucial. The policy controls script access to responses; it is not a universal network firewall.

Cross-Origin Resource Sharing (CORS) allows a server to declare which origins may read selected responses. A server that reflects arbitrary origins while allowing credentials can unintentionally expose private data. CORS is not a substitute for authentication or authorisation, and a permissive CORS policy should never be used merely to solve a front-end integration problem without identifying the exact origins, methods, headers, and credential requirements.

Browser security also includes content security policies, sandboxing, mixed-content blocking, download controls, and protection against some forms of clickjacking. These controls reduce risk but depend on correct server headers and safe application behaviour.

Cookies, Sessions, and Identity Continuity

A cookie is a browser-managed name–value pair associated with a domain and path. Servers create cookies through `Set-Cookie`; browsers return applicable cookies in the `Cookie` header. Cookies commonly store a random session identifier rather than personal or authorisation data itself. The server uses that identifier to locate session state in a database, cache, or session store.

Important cookie attributes include:

• Secure: sends the cookie only over HTTPS.
• HttpOnly: prevents ordinary JavaScript from reading the cookie, reducing the impact of many script-injection attacks.
• SameSite: controls whether the browser sends the cookie in cross-site contexts. `Strict` offers stronger isolation, while `Lax` and `None` support selected cross-site behaviours; `None` requires `Secure`.
• Domain and Path: restrict where the cookie is sent, although they should not be treated as complete substitutes for authorisation.
• Max-Age or Expires: determines persistence.

A session identifier is a bearer credential: possession may be sufficient to act as the user. It must therefore be generated unpredictably, transmitted only through protected channels, rotated after login or privilege changes, invalidated on logout where appropriate, and protected from fixation. Session fixation occurs when an attacker causes a victim to use a session identifier known to the attacker, after which the server associates that identifier with the victim’s authenticated account. Regenerating the identifier after authentication is a principal defence.

Cookie-based sessions also create cross-site request forgery risk. If a browser automatically attaches a valid session cookie to a cross-site request, the target may process an action initiated by another site. SameSite controls, anti-CSRF tokens, origin verification, and appropriate method design provide layered protection. For high-impact operations, the server should verify both the user’s session and the intended action.

Token-based designs do not remove these issues. A token in a cookie remains subject to browser attachment and CSRF concerns; a token in a browser-readable storage location may be exposed by cross-site scripting. The correct choice depends on threat model, client types, revocation requirements, and operational needs.

Caching: Performance with Confidentiality Consequences

Caching occurs in browsers, shared proxies, CDNs, reverse proxies, and application layers. A cache stores a response and reuses it when a later request appears to match. HTTP caching is controlled through headers such as `Cache-Control`, `Expires`, `ETag`, and `Vary`.

Public, immutable assets such as versioned JavaScript bundles are excellent cache candidates. Personalised responses require more care. `Cache-Control: private` indicates that a response is intended for a private cache, while `no-store` instructs caches not to retain it. `no-cache` does not mean “do not store”; it means that stored content must be revalidated before reuse. A response containing user-specific information that is mistakenly cached publicly can disclose one user’s data to another.

Cache keys and variation rules must reflect all inputs that affect the response. If the application varies by language, authorisation, host, or a request header but the cache ignores that factor, cache confusion or cache poisoning may result. Query-string handling, normalisation, and cache invalidation also require explicit design. Sensitive pages should generally use conservative caching directives, and security testing should examine both cache hits and misses.

Proxies, Load Balancers, and CDNs

A forward proxy acts on behalf of a client, whereas a reverse proxy acts on behalf of servers. Reverse proxies commonly perform TLS termination, routing, compression, rate limiting, authentication integration, logging, and web application firewall functions. Load balancers distribute requests across application instances, supporting horizontal scaling and availability.

A CDN distributes content through geographically dispersed edge locations. It reduces latency and origin load, but it becomes capable of receiving, storing, and sometimes modifying application traffic. CDN configuration is therefore part of the application’s security design. Origin access should be restricted so that attackers cannot bypass CDN controls by discovering the origin address. Purge operations, cache rules, administrative APIs, and edge scripting require strong governance.

Every intermediary can alter headers, paths, host information, protocol indicators, and request bodies. The architecture must document which component is authoritative for client IP, scheme, host, authentication, and request normalisation. Logs from multiple layers should be correlated, because an event visible at the edge may look different at the origin.

Architectural Styles and Security Boundaries

In a traditional three-tier architecture, the browser communicates with a web tier, the web tier communicates with an application tier, and the application tier accesses databases and external services. The database should not be directly reachable from the public internet. Each tier should expose only the protocols and privileges it needs.

Single-page applications separate a browser-delivered front end from APIs. This can improve user experience but expands the importance of CORS, token handling, API authorisation, and content security policy. A backend-for-frontend pattern places a server under the organisation’s control between the browser and multiple internal services, reducing the amount of internal topology and credential handling exposed to the browser.

Microservices create additional internal boundaries. Service-to-service authentication, authorisation, secret management, timeout controls, and input validation remain necessary even when traffic is inside a private network. “Internal” is not equivalent to “trusted.” Service meshes can provide identity and encrypted transport, but they do not decide whether a business operation is authorised.

A zero-trust perspective treats each request as requiring explicit verification rather than assuming trust based solely on network location. This does not mean every request must use identical controls; it means that identity, device or workload context, resource, action, and policy are evaluated deliberately.

Applied Case: A Personalised Retail Portal Behind a CDN

Background

An illustrative retailer operates a portal at `shop.example`. Static assets and product pages are delivered through a CDN. The checkout API is routed through a reverse proxy to several application instances. Users authenticate with a cookie-based session.

Situation

Customers report that another customer’s delivery address occasionally appears after visiting the account page. The security team also observes that an external site can cause authenticated users to submit changes to their saved address.

Analysis

The account response contains personalised data but is being served with a cache policy intended for public product pages. The CDN cache key does not distinguish authenticated and unauthenticated requests, and the origin response lacks a private caching directive. Consequently, a response generated for one user may be reused for another.

The address-change endpoint accepts a state-changing `POST` and relies only on the session cookie. Browsers automatically attach that cookie when the request is initiated in a context allowed by the browser’s cookie rules. The absence of an anti-CSRF token or robust origin validation permits a cross-site request scenario.

Approach and Solution

The retailer takes four measures. First, account and checkout responses are marked `Cache-Control: no-store` or otherwise excluded from shared caching. Public product responses are separated by route and given explicit cache rules. Second, the CDN is configured to forward only necessary headers and to prevent direct origin access. Third, session cookies are set with `Secure`, `HttpOnly`, and an appropriate `SameSite` value, while the address-change operation requires a server-validated CSRF token and checks the `Origin` header where available. Fourth, automated tests verify cache behaviour with different users, authentication states, and request headers.

Outcome

The accidental disclosure is removed because personalised responses are no longer reused by shared caches. The cross-site action is rejected without the application’s synchronisation token. Logging is improved at the CDN, proxy, and application layers so that future discrepancies can be traced across the request path.

Learning Points

The case demonstrates that HTTPS cannot prevent a correctly encrypted but incorrectly cached response from being disclosed. It also shows that authentication is not the same as request intent: a valid session identifies the user, but an anti-CSRF control helps establish that the user intended the action. Finally, performance components such as CDNs must be treated as security components.

Challenges, Risks, and Common Mistakes

Several recurring mistakes reflect incomplete boundary analysis. Developers may trust client-side validation, assume that internal traffic is safe, expose databases for convenience, or accept forwarded headers from untrusted sources. They may use `GET` for destructive actions, place long-lived credentials in browser-readable storage, configure CORS with arbitrary origins, or believe that `no-cache` prevents storage.

Operational failures are equally significant. Expired certificates, stale DNS records, unmonitored registrar accounts, forgotten cloud resources, inconsistent TLS termination, and untested cache purges can undermine a technically sound design. Error messages, access logs, tracing systems, and analytics platforms may also become secondary destinations for credentials or personal data.

Security controls have trade-offs. Strict cookie policies can complicate legitimate federated login flows. Aggressive caching improves latency but increases confidentiality risk. TLS inspection may support enterprise monitoring but creates a powerful decryption boundary requiring governance and key protection. Security architecture must therefore document assumptions, select controls proportionately, and test actual behaviour rather than relying on configuration labels.

Governance, Ethics, and Professional Practice

Web architecture processes personal data across many parties. Organisations should minimise collection, define retention periods, restrict administrative access, and disclose relevant processing practices. CDN, hosting, monitoring, identity, and analytics providers may become data processors or subprocessors, creating contractual, jurisdictional, and breach-notification responsibilities.

Professional practice requires separation of duties for DNS, certificates, production deployment, and cache administration. Changes to security-sensitive infrastructure should be reviewed, logged, and reversible. Privacy-by-design principles favour reducing sensitive data in URLs, cookies, logs, and client-side storage. Security testing should be authorised, carefully scoped, and designed to avoid exposing real user data.

Current Developments

HTTP/2 and HTTP/3 improve multiplexing and latency but introduce additional implementation complexity and new intermediary compatibility questions. Encrypted DNS technologies can reduce some forms of query observation, although they do not replace endpoint authentication. Passkeys and other phishing-resistant authentication methods reduce dependence on reusable passwords, while still requiring careful session and recovery design.

Edge computing moves computation closer to users and may reduce latency, but it distributes code and data into more execution environments. Automated certificate management, infrastructure as code, software supply-chain controls, and continuous configuration testing are increasingly important because a small edge, DNS, or proxy change can affect the entire security boundary. AI-assisted development can accelerate configuration and code production, but generated rules must be reviewed for incorrect trust assumptions, unsafe defaults, and leakage of sensitive configuration.

Best Practices for Full-Stack Security Boundaries

A practical baseline includes the following:

• Draw the complete request path, including DNS, CDN, proxy, application, database, and third-party services.
• Define which component authenticates users, authorises actions, terminates TLS, and inserts trusted headers.
• Use HTTPS consistently, modern TLS configurations, HSTS where appropriate, and automated certificate renewal.
• Treat cookies and session identifiers as high-value credentials; use secure attributes, rotation, expiry, and server-side invalidation.
• Apply explicit cache policies and test personalised responses through every cache layer.
• Restrict CORS to known origins and required methods, headers, and credential behaviour.
• Keep databases and management interfaces off the public network and apply least privilege between tiers.
• Validate and normalise requests consistently across proxies and application servers.
• Monitor DNS, certificates, origin exposure, cache configuration, and administrative changes.
• Test both normal and adversarial flows, including redirects, cross-origin requests, stale sessions, malformed messages, and cache hits.

Chapter Summary

Web applications are distributed chains of protocols and intermediaries rather than isolated server programs. DNS discovers destinations; TLS protects and authenticates connections; HTTP defines requests and responses; browsers enforce origin-based restrictions; cookies and sessions maintain application continuity; caches and CDNs improve performance but can disclose data; and proxies and load balancers create additional interpretation and trust boundaries. The same-origin policy limits script-based data access, while CORS selectively permits controlled cross-origin reading.

Secure architecture depends on assigning responsibility explicitly. TLS does not replace application security, authentication does not establish user intent, and internal networks are not automatically trustworthy. Safe systems use layered controls: secure transport, carefully managed sessions, least privilege, explicit caching, constrained cross-origin access, consistent request parsing, protected infrastructure, and continuous testing. The most reliable method is to trace data and authority across the entire full-stack flow and examine every point at which a component can read, modify, store, or reinterpret it.

Key Terms

HTTP: Application-layer protocol defining web requests, responses, methods, headers, and status codes.

HTTPS: HTTP protected by TLS.

TLS: Cryptographic protocol providing confidentiality, integrity, and endpoint authentication in transit.

DNS: Distributed naming system that maps domain names to network and service records.

Origin: Combination of scheme, host, and port used by browser security rules.

Same-origin policy: Browser restriction limiting how scripts from one origin access data from another.

CORS: Server-controlled mechanism that permits specified cross-origin browser access.

Cookie: Browser-managed state value sent to matching requests.

Session: Server or client mechanism maintaining continuity across otherwise stateless requests.

Session fixation: Attack in which a victim authenticates using an identifier already known to an attacker.

CSRF: Unauthorised state-changing request made using a victim’s authenticated browser context.

Cache: Component that stores responses for possible reuse.

CDN: Distributed network of edge servers delivering content closer to users.

Reverse proxy: Intermediary that receives requests on behalf of origin servers.

Load balancer: Component distributing traffic among multiple service instances.

HSTS: HTTP response policy requiring future browser access through HTTPS.

Cache poisoning: Insertion or reuse of an attacker-influenced response for subsequent requests.

Request smuggling: Exploitation of inconsistent request-boundary parsing between intermediaries.

TLS termination: Point at which an intermediary decrypts and processes TLS traffic.

Security boundary: Architectural point where trust, authority, interpretation, or data exposure changes.

Review Questions

Short Answer Questions

1. What four properties should be traced across a web request path?

2. Why is DNS not an authorisation mechanism?

3. State the purpose of the `HttpOnly` cookie attribute.

4. How does `no-cache` differ from `no-store`?

5. What three elements define a web origin?

Long Answer Questions

1. Explain the complete security significance of a browser request from DNS resolution to application response.

2. Discuss how cookies, sessions, authentication, authorisation, and CSRF protections relate to one another.

3. Analyse the security advantages and risks of placing a CDN and reverse proxy before an application.

4. Explain the same-origin policy and evaluate the role and risks of CORS.

5. Compare security boundaries in a three-tier application, a single-page application, and a microservice architecture.

Analytical / Application Questions

1. A personalised dashboard is occasionally shown to the wrong user after a CDN migration. Identify the likely architectural causes and propose a testing and remediation plan.

2. An application trusts `X-Forwarded-Proto` to decide whether a request is secure. Under what deployment conditions is this unsafe, and how should the trust relationship be designed?

3. A team proposes storing a long-lived access token in browser-readable storage because it avoids CSRF. Evaluate the proposal against cross-site scripting, token theft, revocation, and operational requirements, and recommend a defensible alternative.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the security role of TLS?

A. It guarantees that application authorisation rules are correct.

B. It protects data in transit and authenticates the endpoint represented by the certificate.

C. It prevents all malicious JavaScript from executing in a browser.

D. It ensures that DNS records cannot be changed.

Correct Answer: B. It protects data in transit and authenticates the endpoint represented by the certificate.

Question 2

A response containing one user’s account details is served to another user from a shared CDN cache. Which control most directly addresses the problem?

A. Use a longer DNS time to live.

B. Set the response as publicly cacheable.

C. Use private or no-store caching directives and correct cache variation.

D. Move the database to a different subnet.

Correct Answer: C. Use private or no-store caching directives and correct cache variation.

Question 3

Which combination defines a browser origin?

A. Cookie, path, and query string

B. Scheme, host, and port

C. IP address, DNS resolver, and certificate issuer

D. Method, status code, and response body

Correct Answer: B. Scheme, host, and port

Question 4

Why should a session identifier normally be regenerated after successful authentication?

A. To increase CDN cacheability

B. To prevent DNS poisoning

C. To reduce the risk of session fixation

D. To permit cross-origin reading

Correct Answer: C. To reduce the risk of session fixation

Question 5

Which statement about the same-origin policy is most accurate?

A. It prevents every cross-origin network request.

B. It allows any origin to read responses if HTTPS is used.

C. It generally restricts script access to data from another origin, while selected cross-origin interactions may still occur.

D. It replaces server-side authorisation.

Correct Answer: C. It generally restricts script access to data from another origin, while selected cross-origin interactions may still occur.

Question 6

A reverse proxy and an application server interpret conflicting Content-Length and Transfer-Encoding headers differently. What class of attack may result?

A. Session fixation

B. Request smuggling

C. DNS subdomain takeover

D. Clickjacking only

Correct Answer: B. Request smuggling

Question 7

Which cookie attribute prevents ordinary client-side JavaScript from reading the cookie?

A. Secure

B. HttpOnly

C. Domain

D. Max-Age

Correct Answer: B. HttpOnly

Question 8

A server reflects any supplied Origin value and permits credentials in its CORS response. What is the principal risk?

A. Unauthorised cross-origin reading of protected responses

B. Automatic certificate renewal failure

C. Inability to resolve the server’s hostname

D. Prevention of all browser caching

Correct Answer: A. Unauthorised cross-origin reading of protected responses

Question 9

Which statement best distinguishes authentication from authorisation?

A. Authentication identifies a subject; authorisation determines permitted actions.

B. Authentication encrypts traffic; authorisation resolves DNS.

C. Authentication controls caching; authorisation creates certificates.

D. They are interchangeable terms.

Correct Answer: A. Authentication identifies a subject; authorisation determines permitted actions.

Question 10

An organisation encrypts traffic from users to a CDN but sends unencrypted traffic from the CDN to the origin across an untrusted network. What boundary has been introduced?

A. A TLS termination and internal transport boundary requiring its own risk assessment

B. A same-origin boundary that automatically protects the origin

C. A DNSSEC boundary that authenticates application users

D. A cache-control boundary that prevents data disclosure

Correct Answer: A. A TLS termination and internal transport boundary requiring its own risk assessment