WEB / WEB-01.01

The actors of a web application

A page displayed by a browser, a decision made by an application and a stored record are different things. Separate their roles using the Atlas Notları book screen.

What to follow on the first pass

When opening a book, follow what the browser, application and data source each do. Start by separating these three roles.

Cards represent responsibilities; each card need not be a separate computer. Follow who receives the request and who changes the screen.

Client / server: Roles that send a request and respond to it.
Resource / representation: The thing requested and its transmitted representation. A book record and a JSON response are different things.
Handler / store: The handler is code that processes the request; the store here holds the record in memory.
JSON / DOM: JSON represents data. The DOM is the browser’s representation of a page; receiving data alone does not change the view.

Where do the later details fit?

Serialization means converting data into its transmitted representation. On the first pass, separate the application selecting data from the browser displaying it; you need not memorize the code details.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

API representation

Separate roles from the target
The browser owns intent and presentation; the application makes the HTTP decision; the third card represents this resource’s local source. Separate boxes do not imply separate machines.
Browser · presentation
Selection: /api/book?case=found
Application · handler
No request yet
Resource · local source
Book record + private note
The request reached the application
The browser’s GET selection reached the handler over HTTP. The browser awaits a response; resource lookup and representation delivery have not been decided.
Browser · presentation
Waiting for response
Application · handler
GET /api/book?case=found received
Resource · local source
Book record + private note
The route selects local responsibility
This branch serves a book view as JSON. A URL need not map to a same-named disk file. An API is a request/response contract.
Browser · presentation
Waiting for response
Application · handler
Book API branch
Resource · local source
Book record + private note
The local source result was established
Source access is a local operation in this example’s process. No HTTP or driver packet is invented. The resource concept alone does not determine the storage type.
Browser · presentation
Waiting for response
Application · handler
Source result ready
Resource · local source
Book record + private note
The representation is not the source
The application selects only public id/title for the JSON representation. The private note stays at the source; it is omitted from the body rather than merely hidden in the frontend.
Browser · presentation
Response not received
Application · handler
JSON: id / title; no private note
Resource · local source
Book record + private note
The representation reached the browser
The model shows complete response receipt. The browser learns the status and body; the source record and server policy do not become browser-owned state.
Browser · presentation
200 body received; DOM unchanged
Application · handler
Response sent
Resource · local source
Book record + private note
Presentation is a separate operation
The frontend reads JSON and writes the book title to the DOM. The source’s private note is absent from this public response. Representation, stored record and DOM are distinct states.
Browser · presentation
UI: Atlas Notes
Application · handler
HTTP operation complete
Resource · local source
Book record + private note

Static document

Separate roles from the target
The browser owns intent and presentation; the application makes the HTTP decision; the third card represents this resource’s local source. Separate boxes do not imply separate machines.
Browser · presentation
Selection: /about.html
Application · handler
No request yet
Resource · local source
Prepared HTML document
The request reached the application
The browser’s GET selection reached the handler over HTTP. The browser awaits a response; resource lookup and representation delivery have not been decided.
Browser · presentation
Waiting for response
Application · handler
GET /about.html received
Resource · local source
Prepared HTML document
The route selects local responsibility
This branch serves a prepared document. Being a server does not require a database or a dynamic business handler.
Browser · presentation
Waiting for response
Application · handler
Static document branch
Resource · local source
Prepared HTML document
The local source result was established
Source access is a local operation in this example’s process. No HTTP or driver packet is invented. The resource concept alone does not determine the storage type.
Browser · presentation
Waiting for response
Application · handler
Source result ready
Resource · local source
Prepared HTML document
The representation is not the source
The prepared document is selected as the HTTP body; status and media type are server responsibilities. Static content still uses HTTP.
Browser · presentation
Response not received
Application · handler
HTML representation ready
Resource · local source
Prepared HTML document
The representation reached the browser
The model shows complete response receipt. The browser learns the status and body; the source record and server policy do not become browser-owned state.
Browser · presentation
200 body received; DOM unchanged
Application · handler
Response sent
Resource · local source
Prepared HTML document
Presentation is a separate operation
The browser processes the document and creates the presentation. Network evidence proves the delivered representation, not the server’s complete storage.
Browser · presentation
UI: document presentation
Application · handler
HTTP operation complete
Resource · local source
Prepared HTML document

Resource missing

Separate roles from the target
The browser owns intent and presentation; the application makes the HTTP decision; the third card represents this resource’s local source. Separate boxes do not imply separate machines.
Browser · presentation
Selection: /api/book?case=missing
Application · handler
No request yet
Resource · local source
Selected book absent
The request reached the application
The browser’s GET selection reached the handler over HTTP. The browser awaits a response; resource lookup and representation delivery have not been decided.
Browser · presentation
Waiting for response
Application · handler
GET /api/book?case=missing received
Resource · local source
Selected book absent
The route selects local responsibility
This branch serves a book view as JSON. A URL need not map to a same-named disk file. An API is a request/response contract.
Browser · presentation
Waiting for response
Application · handler
Book API branch
Resource · local source
Selected book absent
The local source result was established
Source access is a local operation in this example’s process. No HTTP or driver packet is invented. The resource concept alone does not determine the storage type.
Browser · presentation
Waiting for response
Application · handler
Source result ready
Resource · local source
Selected book absent
The representation is not the source
The source has no selected record. The application chooses 404 and explanatory JSON. This result does not establish private-field disclosure.
Browser · presentation
Response not received
Application · handler
404 + not-found JSON
Resource · local source
Selected book absent
The representation reached the browser
The model shows complete response receipt. The browser learns the status and body; the source record and server policy do not become browser-owned state.
Browser · presentation
404 body received; DOM unchanged
Application · handler
Response sent
Resource · local source
Selected book absent
Presentation is a separate operation
The frontend presents a not-found state. A 404 is an application outcome; the actor map alone does not classify it as compromise.
Browser · presentation
UI: book missing
Application · handler
HTTP operation complete
Resource · local source
Selected book absent

ACTORS · STATE · DATA FLOW

What does the Web provide; what does the Internet carry?

The Internet provides communication between interconnected networks. The Web offers URL-identified resources, documents and application interactions over HTTP on that infrastructure. Email can also use the Internet; its browser interface may be a web application while mail transport need not use HTTP. Calling every Internet interaction “the Web” obscures the layer being observed.

Public Internet access is not required for web mechanics. HTTP works on a private intranet or at 127.0.0.1. Opening a book from our synthetic Atlas Notları application in a local browser is therefore a web interaction. Running locally does not remove the protocol; it changes the network path and the scope of trust assumptions.

Client and server are roles

The browser is the client sending a request in an HTTP interaction; a handler executes on the server side receiving it. These are not permanent device labels: when the handler calls another HTTP service, it becomes the client for that interaction. One machine may run both a browser and a local server.

The “Show book” button expresses user intent. Frontend JavaScript turns it into a request, the backend handler decides what to return, the storage adapter finds the record, and the browser updates its DOM. These responsibilities differ. Separate diagram boxes do not necessarily represent separate machines or network connections.

A resource is not a copy of a stored row

A resource is the target of HTTP: it may be a file, book information or a computed search result. Its URL identifies it. A representation is a view of that resource at a particular time and in a particular format. JSON and an HTML page can represent related book information. A URL need not map to a same-named disk file.

The stored book might have id, title and price, while the API returns only id and title. The handler selects fields. Receiving JSON does not imply receiving a database row unchanged: serialization selects form and fields; parsing produces usable data from text. Those transformations do not automatically change ownership or permission.

How website, application and API fit together

A website is a collection of related pages and resources. A web application provides functions through that surface, such as viewing, searching or listing books. A web API provides a request/response interface for programs. One product may expose HTML pages, a JavaScript application and a JSON API; these are overlapping descriptions.

A static page may use HTML/CSS and optional JavaScript files without a database. Dynamic products may add routing, validation, policy, storage, jobs and telemetry. Those pieces need not be separate deployments. Our lab storage adapter calls in-memory data locally; production drivers may use different protocols or embedded access. A database icon does not justify drawing an HTTP packet to it.

Separate the screen from authority

The browser provides presentation and controls; a trusted server or service makes the final permission decision for protected data. A browser label saying “owner” does not prove server policy ran. The handler’s storage access does not imply every client may read every record.

This actor map is not a full DNS, TLS or deployment explanation. Reverse proxies and CDNs may sit between browser and origin; intermediary lessons expand them. For each arrow, first identify producer, consumer, and whether the interaction is HTTP or a local call.

Read every scenario without motion

Public projection

The card has a target
Atlas book-view requests only a public book’s id/title. A browser view does not justify access to all storage fields.
Browser
GET book-view / id,title prepared
Handler
No request
Public projection
Field contract unread
The client selection is at the handler
The HTTP request reached the handler. Operation by application-service does not make a user-device selection authoritative metadata.
Browser
GET book-view / id,title prepared
Handler
book selection received
Public projection
Field contract unread
The storage call is local
The inventory gives handler and store the same application-service owner. Seeded lookup is local-call/local-return; separate boxes do not establish network isolation.
Browser
GET book-view / id,title prepared
Handler
Seeded record read
Public projection
Field contract unread
The private-field boundary is visible
publicFields=[id, title] and excludedFields=[editorialPrivateNote] are separate classes. Projection selects the public contract rather than relying on later frontend hiding.
Browser
GET book-view / id,title prepared
Handler
Seeded record read
Public projection
Projection: id,title
The output gate belongs to the application
The handler prepares the id/title projection as a JSON representation. Storage schema does not automatically determine response schema.
Browser
GET book-view / id,title prepared
Handler
Public JSON prepared; editorialPrivateNote excluded
Public projection
Projection: id,title
The browser received public fields only
The HTTP JSON representation reached the browser. id/title can be displayed; editorialPrivateNote is not sent. This release decision concerns only the confidentiality of the displayed fields; it does not measure record mutation or service availability.
Browser
id,title / private note absent
Handler
Public JSON prepared; editorialPrivateNote excluded
Public projection
Projection: id,title

Output difference

The card has a target
Atlas book-view requests only a public book’s id/title. A browser view does not justify access to all storage fields.
Browser
GET book-view / id,title prepared
Handler
No request
Public projection
Field contract unread
The client selection is at the handler
The HTTP request reached the handler. Operation by application-service does not make a user-device selection authoritative metadata.
Browser
GET book-view / id,title prepared
Handler
book selection received
Public projection
Field contract unread
The storage call is local
The inventory gives handler and store the same application-service owner. Seeded lookup is local-call/local-return; separate boxes do not establish network isolation.
Browser
GET book-view / id,title prepared
Handler
Seeded record read
Public projection
Field contract unread
The private-field boundary is visible
publicFields=[id, title] and excludedFields=[editorialPrivateNote] are separate classes. A supplied comparison list includes the note; it is not a claim that the current server disclosed it.
Browser
GET book-view / id,title prepared
Handler
Seeded record read
Public projection
Comparison: id,title,editorialPrivateNote
The output gate belongs to the application
The comparison list differs from publicFields. editorialPrivateNote output is stopped before the public response; UI hiding is not an alternative.
Browser
GET book-view / id,title prepared
Handler
Public JSON prepared; editorialPrivateNote excluded
Public projection
Comparison: id,title,editorialPrivateNote
The browser received public fields only
The HTTP JSON representation reached the browser. id/title can be displayed; editorialPrivateNote is not sent. This release decision concerns only the confidentiality of the displayed fields; it does not measure record mutation or service availability.
Browser
id,title / private note absent
Handler
Public JSON prepared; editorialPrivateNote excluded
Public projection
Comparison: id,title,editorialPrivateNote

ASSUMPTION · BOUNDARY · CONTROL

Mistaking a role for an entitlement

The normal handler receives a client selection and evaluates its business rules. Arrival at the backend does not permit disclosure of every stored field. Reachability is not permission; confusing them may expose excessive fields or private resources.

Returning the public book title is intended, but editorialPrivateNote is a different data class. Excluding it from the public representation is an output-policy decision. Hiding it in the frontend cannot restore confidentiality after delivery. Assess impact from the data that actually leaves the boundary.

Trust changes between boxes

A client request is external input to the handler; the handler owns the storage selection it creates. Treating a submitted object or role label as authoritative server metadata crosses the wrong trust boundary. The issue is assigning different sources the same authority.

Keep data provenance visible, validate the required format, and evaluate permissions in a trusted tier. HTTPS protects the transport channel; it does not make every client input correct or authorized. Transport security and business authority answer different questions.

Not every error is compromise

A 404 for a missing book, unavailable storage and an empty UI are different outcomes. An actor map alone cannot identify which is a security-policy violation. A failed book screen may be an availability problem; disclosure of a private field is a confidentiality violation.

This distinction determines the evidence to collect. A failed UI does not prove all server data was lost. Inspect each actor’s state change and the data delivered separately.

Read every scenario without motion

Owners mapped

Separate the operating owner
actors[].owner is user-device or application-service. Component ownership is not ownership of a book record; evidence scope belongs to that component.
Actor inventory
browser / handler / store
Observation mapping
Evidence unassigned
Coverage review
No result
HTTP observation has limits
Browser Network records are produced by the browser; their target and response cover only the browser’s HTTP boundary. Evidence of server lookup requires a separate handler or store record for the same read operation.
Actor inventory
browser / handler / store
Observation mapping
Browser → HTTP receipt
Coverage review
No result
Local-call evidence stays separate
flows[].kind is local-call/local-return. Store evidence supports seeded lookup only, not remote database transport.
Actor inventory
browser / handler / store
Observation mapping
Store → local lookup
Coverage review
No result
The public output contract was read
resources[].publicFields contains id/title and excludedFields names editorialPrivateNote. These names define expected output; inventory is not a delivery measurement.
Actor inventory
id,title / exclude note
Observation mapping
Store → local lookup
Coverage review
No result
Separate disclosure from an empty view
An explained empty view for a missing book can be an ordinary negative control. Private-field disclosure needs separate evidence; a UI error or response size alone is not a confidentiality finding.
Actor inventory
id,title / exclude note
Observation mapping
Store → local lookup
Coverage review
Output class must be compared
Inventory scope was preserved
Component owners and HTTP/local relationships are separated. The map proves neither actual network delivery nor persistent durability.
Actor inventory
id,title / exclude note
Observation mapping
Store → local lookup
Coverage review
Owner and HTTP/local mapping consistent

Store view absent

Separate the operating owner
actors[].owner is user-device or application-service. Component ownership is not ownership of a book record; evidence scope belongs to that component.
Actor inventory
browser / handler / store
Observation mapping
Evidence unassigned
Coverage review
No result
HTTP observation has limits
Browser Network records are produced by the browser; their target and response cover only the browser’s HTTP boundary. Evidence of server lookup requires a separate handler or store record for the same read operation.
Actor inventory
browser / handler / store
Observation mapping
Browser → HTTP receipt
Coverage review
No result
Local-call evidence stays separate
flows[].kind is local-call/local-return. This review copy lacks store evidence; absent packets do not establish that lookup never happened.
Actor inventory
browser / handler / store
Observation mapping
Store evidence missing
Coverage review
No result
The public output contract was read
resources[].publicFields contains id/title and excludedFields names editorialPrivateNote. These names define expected output; inventory is not a delivery measurement.
Actor inventory
id,title / exclude note
Observation mapping
Store evidence missing
Coverage review
No result
Separate disclosure from an empty view
An explained empty view for a missing book can be an ordinary negative control. Private-field disclosure needs separate evidence; a UI error or response size alone is not a confidentiality finding.
Actor inventory
id,title / exclude note
Observation mapping
Store evidence missing
Coverage review
Output class must be compared
Inventory scope was preserved
The HTTP boundary is known; store processing remains UNKNOWN. Further review requests local evidence of the same operation from the store owner.
Actor inventory
id,title / exclude note
Observation mapping
Store evidence missing
Coverage review
UNKNOWN: local lookup

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Which observation shows which actor?

Browser Network records reveal the HTTP target, status and response visible to the browser. Handler traces may show the selected application branch. Storage-adapter observations explain record lookup. The response alone does not prove the storage schema or every query.

In the Atlas inventory, actors[].owner identifies the operating party and flows[].kind identifies HTTP or same-process local call/return relationships. The inventory describes expected topology, not runtime evidence. Review a read by correlating the browser target/response with the handler branch and storage-adapter lookup for the same operation. Without a store record, lookup remains unobserved rather than proven absent.

Separate normal from unexpected output

The positive baseline shows the public book with id/title. A benign negative case uses the supplied missing scenario and produces 404 with an explainable empty view. A private field outside the public output contract requires review; an error status alone does not express that issue.

Inspect the JSON inventory by field and boundary relationship. Comparing delivered fields with public representation fields is an explainable initial check. Without that contract, a “large response” alarm provides little evidence of a security problem.

Use the map during maintenance

When adding storage, a proxy or an export job, record its owner, input source and enforcement point. More actors do not automatically provide isolation; identify the control protecting each boundary. Design logging per component and keep credential values out of the inventory.

Initial checks ask whether only public fields reach the browser, handler branches correlate with the right trace, and local/remote storage labels match the implementation. Verify with found and missing cases and record telemetry gaps separately.

NOW APPLY IT TO THE CASE

Who releases a storage field to the browser, and why?

The Atlas book screen displays id and title. editorialPrivateNote stays outside the public representation. Even when the handler and memory store share a process, the application owns the release decision.

In the linked case the application produces the HTTP response and the browser produces the visible card. Identify those roles, then explain why a 200 response does not establish a new screen.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas actor and resource inventory

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "system": "atlas-book-screen",
  "actors": [
    {
      "id": "browser",
      "owner": "user-device",
      "role": "HTTP client",
      "state": "DOM and JS memory"
    },
    {
      "id": "handler",
      "owner": "application-service",
      "role": "HTTP server route handler",
      "state": "request-local processing"
    },
    {
      "id": "store",
      "owner": "application-service",
      "role": "in-memory storage adapter",
      "state": "seeded book records"
    }
  ],
  "flows": [
    {
      "from": "browser",
      "to": "handler",
      "kind": "HTTP",
      "data": "book selection"
    },
    {
      "from": "handler",
      "to": "store",
      "kind": "local-call",
      "data": "record lookup"
    },
    {
      "from": "store",
      "to": "handler",
      "kind": "local-return",
      "data": "record or missing"
    },
    {
      "from": "handler",
      "to": "browser",
      "kind": "HTTP",
      "data": "JSON representation"
    }
  ],
  "resources": [
    {
      "id": "book-view",
      "url": "/api/book?case=found",
      "representation": "application/json",
      "publicFields": [
        "id",
        "title"
      ],
      "excludedFields": [
        "editorialPrivateNote"
      ]
    }
  ],
  "deployment": "Synthetic roles; handler and store may share one process."
}

actors[].owner: Authority operating a component, distinct from record ownership.
flows[].kind: Distinguishes HTTP from local function calls and returns.
resources[].representation: The form served over HTTP, not a disk file or storage schema.
publicFields / excludedFields: Public output contract and an example private field excluded from it.

Inert synthetic inventory, not service discovery or packet capture. It does not model DNS/TLS/deployment details or prove persistent storage.

Two reality checks

The Internet and the Web are two names for the same system.

The Internet is network infrastructure; the Web is a service system that can use it. Web applications also work on private or local networks.

Every web application has a separate database server.

Static resources may need no database, and storage can be local, embedded or remote. Separate diagram roles need not be separate hosts.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The handler and store share one process. Is a separate database network hop required to read the book?

No separate database network hop is required.
At least one database hop is required because there is a store card.

Read the explained answer

No separate database network hop is required. — The fixture uses local-call/local-return; storage responsibility does not require a separate host.

Which fields is the JSON representation defined to carry?

Selected lesson artifact fields; teaching example

resources[0].publicFields: ["id","title"]
resources[0].excludedFields: ["editorialPrivateNote"]

id/title are public; editorialPrivateNote is excluded from this representation.
Every resource field is sent to the browser.

Read the explained answer

id/title are public; editorialPrivateNote is excluded from this representation. — publicFields and excludedFields specify the visible data contract; they do not imply the whole storage row is sent.

The Internet works, but the book endpoint returns the wrong representation. Why is this a Web application issue?

Read the explained answer

The Internet supplies connectivity; the Web involves HTTP resources and representations. The handler determines which fields of which book are exposed as JSON. Network reachability does not make that application decision correct.

□ I distinguished HTTP client/server roles.

□ I did not equate resource with representation.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

MDN — How does the Internet work?Internet and the web
MDN — How the web worksClients and servers · The other parts of the toolbox · So what happens, exactly?
RFC 9110 — HTTP Semantics3.1 Resources · 3.2 Representations · 3.3 Connections, Clients, and Servers · 3.7 Intermediaries · 8.6 Content-Length · 15.5.5 404 Not Found
OWASP Authorization Cheat SheetIntroduction · Validate the Permissions on Every Request · Verify that Authorization Checks are Performed in the Right Location
OWASP Logging Cheat SheetEvent data sources · Event attributes · Data to exclude · Verification
RFC 8446 — TLS 1.31 Introduction

YOUR NOTES / THIS BROWSER

The actors of a web application

What to follow on the first pass

1. Core · Mechanism

API representation

Static document

Resource missing

What does the Web provide; what does the Internet carry?

Client and server are roles

A resource is not a copy of a stored row

How website, application and API fit together

Separate the screen from authority

2. Red · Trust & Impact

Public projection

Output difference

Mistaking a role for an entitlement

Trust changes between boxes

Not every error is compromise

3. Blue · Secure development & defense

Owners mapped

Store view absent

Which observation shows which actor?

Separate normal from unexpected output

Use the map during maintenance

Who releases a storage field to the browser, and why?

Two reality checks

The handler and store share one process. Is a separate database network hop required to read the book?

Which fields is the JSON representation defined to carry?

The Internet works, but the book endpoint returns the wrong representation. Why is this a Web application issue?

Sources and scope