Web development has many terms.

Frontend. Backend. API. Database. Server. Cookie. Session. JWT. OAuth. CORS. CSRF. XSS. REST. GraphQL. WebSocket. Cache. Load balancer. Reverse proxy. CDN. Deployment. Environment variable. Container. Queue.

These terms can feel unrelated when learned one by one.

They are not unrelated.

Most of them exist because web applications must solve the same core engineering problems:

How does a user reach the application?
How does the browser communicate with the server?
How does the server process a request?
How does the application store and retrieve data?
How does the system know who the user is?
How does the system decide what the user may access?
How does the application stay fast?
How does it stay secure?
How does it scale when traffic grows?
How does it recover when something fails?
How does it get deployed safely?

This post explains modern web development using one analogy:

A web application is like a large office building.

The analogy is not perfect. No analogy is.

But it is useful because many web systems are about addresses, entrances, routing, identity, permissions, documents, departments, queues, records, monitoring, and controlled access.

Those ideas map well to an office building.

This guide is also intentionally comparative. It does not only explain what each component is. It explains why one approach may be used instead of another.

The Big Picture

Imagine you are visiting a large company office.

You want to access a confidential document.

You do not walk directly into the archive room.

A realistic journey looks like this:

You find the building address.
You arrive at the front gate.
Reception receives your request.
Security checks your identity.
Your badge determines which rooms you may access.
The correct department processes your request.
Records are fetched from storage.
Frequently used records may already be available nearby.
Slow work may be placed into a work queue.
Updates may be delivered later.
If the office is busy, visitors may be routed to different buildings.
Activity is logged and monitored.
The office must recover if something breaks.

A simplified web request is similar:

User
  |
  v
Browser
  |
  v
URL / Domain Name
  |
  v
DNS
  |
  v
Internet
  |
  v
CDN / Load Balancer / Reverse Proxy
  |
  v
Application Server
  |
  v
API / Route Handler
  |
  v
Application Logic
  |
  +-------------------+
  |                   |
  v                   v
Database             Cache
  |
  v
Response

For slow or background work, the flow may continue:

Application Logic
  |
  v
Queue
  |
  v
Worker
  |
  v
Database / Object Storage / External Service

This is the main structure.

The rest of web development is mostly detail around this flow.

Core Mapping

Web Concept	Office Building Analogy
User	Visitor
Browser	Visitor’s assistant
Domain name	Street address
DNS	Address lookup service
IP address	Actual network location
URL	Full instruction to a specific room or document
Server	Office building or department machine
Frontend	Reception desk and visitor interface
Backend	Employees and departments behind reception
API	Standard request form
Database	Filing room / records archive
Cache	Frequently used documents on a nearby desk
Authentication	Security guard checking identity
Authorization	Badge permissions
Session	Visitor record at the security desk
Cookie	Small note carried by the visitor’s assistant
JWT	Signed visitor badge
OAuth	Trusted external identity and access flow
HTTPS	Sealed communication envelope
CORS	Browser policy for approved cross-origin callers
CSRF	Forged request using a valid visitor identity
XSS	Malicious instruction inserted into trusted documents
REST	Standard forms for standard records
GraphQL	Custom report request
RPC	Direct task request
Polling	Repeatedly asking if something is ready
Server-Sent Events	One-way office announcement channel
WebSocket	Permanent two-way phone line
Load balancer	Traffic director
Reverse proxy	Front gate and request router
CDN	Regional document kiosk
Queue	Work inbox
Worker	Back-office employee processing queued work
Container	Portable office room
Environment	Branch office: local, dev, staging, production
Deployment	Opening a new office version
Logs	Office activity journal
Metrics	Operations dashboard
Tracing	Tracking slip across departments
Alerting	Alarm system
Backup	Duplicate archive

Finding the Building: Domain, DNS, IP, and URL

Before a user can use your application, the browser must find where the application lives.

This requires several layers:

Human-friendly name -> Machine address -> Specific resource

Domain Name

A domain name is the human-readable name of a website.

Examples:

example.com
github.com
docs.company.com
app.company.com

Office analogy:

Domain name = Street address

Humans prefer names.

Machines use network addresses.

The domain is not the application itself. It is a name that points traffic toward where the application can be reached.

Why use a domain name instead of an IP address?

Use a domain name because it is stable and human-friendly.

An IP address may change when infrastructure changes. A domain can remain the same while the underlying server, load balancer, CDN, or cloud region changes.

Option	Good For	Problems
Raw IP address	Internal testing, debugging	Hard to remember, may change, poor user experience
Domain name	Public applications, stable access	Requires DNS configuration

Use domains for real applications.

Use raw IP addresses mainly for debugging and internal infrastructure work.

DNS

DNS stands for Domain Name System.

DNS translates a domain name into an IP address or another DNS record.

Office analogy:

DNS = Address lookup service

The browser asks:

Where is app.company.com?

DNS answers:

Send traffic to this IP address or target.

Simplified flow:

Browser
  |
  v
DNS Resolver
  |
  v
DNS Record
  |
  v
IP Address / Target

Common DNS record types:

Record	Meaning
A	Maps a domain to an IPv4 address
AAAA	Maps a domain to an IPv6 address
CNAME	Maps one name to another name
MX	Mail server record
TXT	Text record, often used for verification and email security
NS	Nameserver record

Why use CNAME instead of A record?

A record points directly to an IP address.

CNAME points to another hostname.

Use an A record when you control the IP address directly.

Use a CNAME when another service controls the final target.

Example:

www.example.com -> example-hosting-provider.net

This lets the hosting provider change IP addresses without requiring you to update your DNS every time.

IP Address

An IP address identifies a network location.

Office analogy:

IP address = Actual physical location

A domain is the name humans use.

An IP address is closer to what machines route traffic toward.

Example:

example.com -> 93.184.216.34

In modern infrastructure, an IP may point to:

One server
A load balancer
A CDN edge location
A cloud-managed endpoint
A reverse proxy

The IP is rarely the whole application.

It is an entry point.

URL

A URL is the full address of a resource.

Example:

https://example.com/users/123?tab=settings

Parts:

Part	Example	Meaning
Scheme	`https`	Protocol
Host	`example.com`	Domain
Path	`/users/123`	Resource path
Query string	`?tab=settings`	Extra parameters

Office analogy:

URL = Full instruction for reaching a specific office, desk, or document

The domain gets you to the building.

The path tells the application what you want inside the building.

URL vs URI

In everyday web development, people often say URL for web addresses.

URI is a broader concept.

For practical work:

URL = Address you can use to locate something.
URI = Identifier, sometimes locatable, sometimes not.

Most beginners can safely focus on URLs first.

Browser, HTTP Requests, and HTTP Responses

The browser is not just a screen.

It is an application runtime, security boundary, network client, storage layer, and rendering engine.

Browser

Examples:

Chrome
Safari
Firefox
Edge

Office analogy:

Browser = Visitor's assistant

The browser:

Resolves domains through DNS
Sends HTTP requests
Receives HTTP responses
Renders HTML and CSS
Executes JavaScript
Stores cookies and browser storage
Enforces browser security rules
Caches resources
Manages tabs, history, downloads, and permissions

The browser is powerful.

It is also untrusted from the server’s point of view.

Users can inspect frontend code, modify requests, disable JavaScript, edit local storage, and call APIs directly.

Important rule:

The browser may improve user experience, but it must not be the only place where security rules are enforced.

HTTP Request

An HTTP request is a message from client to server.

Example:

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=abc123

Office analogy:

HTTP request = Visitor asking the office for something

A request may include:

Method
Path
Headers
Cookies
Query parameters
Request body
Authentication token
Content type

Example JSON request body:

{
  "email": "alice@example.com",
  "password": "example-password"
}

HTTP Response

An HTTP response is the server’s reply.

Example:

HTTP/1.1 200 OK
Content-Type: application/json

Body:

{
  "id": 123,
  "name": "Alice"
}

Office analogy:

HTTP response = Office giving something back to the visitor

The response may contain:

HTML
CSS
JavaScript
JSON
Images
Files
Redirects
Error messages
Security headers
Cache headers

The web is mostly request and response:

Browser -> Request -> Server
Browser <- Response <- Server

HTTP Methods

HTTP methods describe the intended action.

Method	Common Meaning	Office Analogy
GET	Read data	Ask to view a document
POST	Create or submit data	Submit a new form
PUT	Replace a full resource	Replace an entire record
PATCH	Update part of a resource	Correct one field
DELETE	Delete a resource	Remove a record

Examples:

GET /users/123
POST /users
PUT /users/123
PATCH /users/123
DELETE /users/123

Why use GET instead of POST for reading data?

Use GET for safe read operations.

GET requests are easier to cache, bookmark, log, and debug.

Use POST when the request creates data, changes state, submits sensitive payloads, or has a complex body.

Use Case	Better Method	Why
View product page	GET	Safe, cacheable, shareable URL
Search with simple query	GET	Query visible and bookmarkable
Submit login form	POST	Sends body, changes auth state
Create order	POST	Creates new resource
Update profile name	PATCH	Partial update
Replace entire settings object	PUT	Full replacement

Do not use GET for destructive actions.

Bad:

GET /delete-account

Better:

DELETE /account

or for HTML forms that cannot send DELETE directly:

POST /account/delete

HTTP Status Codes

Status codes summarize what happened.

Status Code	Meaning
200	OK
201	Created
204	Success, no response body
301	Moved permanently
302	Temporary redirect
304	Not modified
400	Bad request
401	Not authenticated
403	Authenticated but not authorized
404	Not found
409	Conflict
422	Valid format, invalid business input
429	Too many requests
500	Server error
502	Bad gateway
503	Service unavailable
504	Gateway timeout

Office analogy:

Status	Office Meaning
200	Request completed
201	New record created
204	Done, nothing else to hand back
401	Security does not know who you are
403	Security knows you, but you lack access
404	Requested document does not exist
409	Request conflicts with current records
429	Too many forms submitted
500	Something broke inside the office
503	Office is temporarily unavailable

Important distinction:

401 = Who are you?
403 = You are known, but not allowed.

Why use specific status codes instead of always returning 200?

Because clients, browsers, proxies, monitoring systems, and developers rely on status codes to understand behavior.

Bad:

HTTP/1.1 200 OK

{
  "error": "not authorized"
}

Better:

HTTP/1.1 403 Forbidden

{
  "error": "not authorized"
}

Returning correct status codes improves debugging, monitoring, retry logic, caching behavior, and API correctness.

Headers

HTTP headers carry metadata.

Examples:

Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
Cache-Control: no-store
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

Office analogy:

Headers = Labels and instructions attached to an office form

Headers may describe:

Content type
Authentication
Caching
Cookies
Compression
Security policy
Client details
Accepted response formats

Headers are not the main document.

They are instructions about the document and request.

Frontend, Backend, and Database

A typical application has three major parts:

Frontend -> Backend -> Database

Office analogy:

Reception -> Departments -> Filing room

Frontend

The frontend is what users see and interact with.

Examples:

Pages
Buttons
Forms
Menus
Search bars
Dashboards
Charts
Navigation
Error messages

Office analogy:

Frontend = Reception desk and visitor interface

Frontend technologies:

HTML
CSS
JavaScript
TypeScript
React
Vue
Angular
Svelte
Next.js
Nuxt
Astro

The frontend is responsible for:

Displaying information
Collecting user input
Calling APIs
Managing UI state
Handling client-side validation
Rendering dynamic components
Providing good user experience

The frontend should not be trusted for security.

Frontend checks can be bypassed.

Example:

Hiding an Admin button does not protect the Admin API.

The backend must enforce permissions.

Why use frontend validation if backend validation is still required?

Frontend validation improves usability.

Backend validation protects the system.

Validation Place	Purpose
Frontend	Fast feedback to user
Backend	Security and correctness

Use both.

Do not choose only one.

HTML

HTML defines page structure and meaning.

Office analogy:

HTML = Layout and labels in the reception area

Example:

<h1>Account Settings</h1>
<form>
  <label>Email</label>
  <input type="email" />
  <button>Save</button>
</form>

HTML tells the browser what things are.

It does not control complex behavior by itself.

CSS

CSS controls presentation.

Office analogy:

CSS = Interior design and visual layout

CSS controls:

Color
Font
Spacing
Layout
Animation
Responsiveness
Media queries

Example:

button {
  padding: 8px 12px;
  border-radius: 6px;
}

HTML gives structure.

CSS gives appearance.

JavaScript

JavaScript adds behavior.

Office analogy:

JavaScript = Reception desk procedures

JavaScript can:

React to button clicks
Submit forms
Fetch data from APIs
Render dynamic lists
Manage client-side state
Update pages without full reloads
Handle real-time updates

Example:

async function loadUser() {
  const response = await fetch('/api/user');
  const user = await response.json();
  console.log(user);
}

JavaScript makes modern web applications interactive.

It also increases complexity.

Why use TypeScript instead of JavaScript?

TypeScript adds static typing on top of JavaScript.

Use TypeScript when the codebase is large, multiple developers work on it, or API contracts are complex.

JavaScript	TypeScript
Less setup	More setup
Flexible	Safer refactoring
Good for small scripts	Better for larger applications
Errors often found at runtime	Many errors found before runtime

TypeScript does not remove all bugs.

It helps catch a class of mistakes earlier.

Backend

The backend handles application logic and data operations.

Office analogy:

Backend = Employees and departments behind reception

The backend handles:

Authentication
Authorization
Business rules
Database access
Payments
File handling
Email sending
Input validation
Logging
Integrations
Background job creation

Common backend languages:

Python
JavaScript / TypeScript with Node.js
Go
Java
C#
Ruby
PHP
Rust

Common backend frameworks:

Django
FastAPI
Flask
Express
NestJS
Spring Boot
Rails
Laravel
ASP.NET

The backend is where important rules should live.

The frontend may request an action.

The backend decides if the action is valid and allowed.

Why use a backend instead of calling the database directly from the frontend?

Because the database must not be exposed directly to untrusted browsers.

The backend provides:

Security boundary
Validation layer
Permission checks
Business logic
Audit logging
Rate limiting
Data shaping
Protection of secrets

Bad design:

Browser -> Database

Better design:

Browser -> API -> Backend -> Database

The browser is not trusted.

The backend is the controlled gatekeeper.

Database

The database stores persistent data.

Office analogy:

Database = Filing room / records archive

A database may store:

Users
Orders
Messages
Products
Invoices
Permissions
Audit logs
Application settings
Relationships between records

Common databases:

Database	Type	Common Use
PostgreSQL	Relational	General application data
MySQL	Relational	General application data
SQLite	Relational	Local apps, small apps, embedded use
MongoDB	Document	Flexible document-shaped data
Redis	Key-value	Cache, sessions, queues
Elasticsearch	Search index	Full-text search and analytics
DynamoDB	Key-value/document	Managed high-scale workloads
Cassandra	Wide-column	Large distributed writes

The database is usually the source of truth.

If an application server crashes, it can restart.

If the database is corrupted or lost, the business may be in serious trouble.

Relational Database

A relational database stores data in tables with relationships.

Example:

users
-----
id
name
email

orders
------
id
user_id
amount
created_at

Office analogy:

Relational database = Organized filing cabinets with strict forms

Relational databases are good when:

Data has clear structure
Relationships matter
Consistency matters
Reporting matters
Transactions are important

Example relationship:

One user can have many orders.
One order belongs to one user.

PostgreSQL is a strong default for many applications.

Why use PostgreSQL instead of MongoDB?

Use PostgreSQL when your data has strong relationships, you need transactions, and you want reliable querying.

Use MongoDB when your data is naturally document-shaped, changes frequently, and does not require many relational joins.

Question	PostgreSQL	MongoDB
Strong relationships?	Good	Possible, but less natural
Transactions?	Strong	Supported, but not the core model
Flexible schema?	Less flexible	More flexible
Reporting queries?	Strong SQL support	Depends on design
Default app database?	Often a good choice	Good for document-heavy use cases

Do not choose NoSQL only because it sounds more scalable.

Choose based on data shape and consistency needs.

NoSQL Database

NoSQL is a broad category.

It often means the database does not primarily use relational tables.

Types:

Type	Example	Good For
Document	MongoDB	JSON-like documents
Key-value	Redis, DynamoDB	Fast lookup by key
Wide-column	Cassandra	Large distributed writes
Graph	Neo4j	Relationship-heavy graph traversal
Search	Elasticsearch	Full-text search

Office analogy:

NoSQL database = Specialized storage rooms for different document shapes

NoSQL is useful when the access pattern matches the database model.

It is not automatically better than SQL.

Database Index

A database index makes lookups faster.

Office analogy:

Index = Catalog card

Without an index, the database may scan many rows.

With an index, it can jump closer to the target.

Example:

CREATE INDEX idx_users_email ON users(email);

Indexes improve reads.

They add cost to writes.

Trade-off:

Faster lookup
Slower inserts/updates/deletes
More storage

Why not index every column?

Because every index must be stored and maintained.

When data changes, indexes must also change.

Too many indexes can slow writes and increase storage cost.

Index columns that are frequently used for:

Filtering
Joining
Sorting
Uniqueness checks

Do not index blindly.

Measure query behavior.

Transactions

A transaction groups database operations into one unit.

Office analogy:

Transaction = A records update that must fully complete or fully fail

Example:

Transfer $100 from Alice to Bob.

This requires two operations:

Subtract $100 from Alice.
Add $100 to Bob.

Bad outcome:

Alice is charged, but Bob is not credited.

A transaction prevents partial completion.

Simplified SQL:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE user_id = 'bob';
COMMIT;

If something fails:

ROLLBACK;

Why use transactions?

Use transactions when partial updates would corrupt business state.

Examples:

Payments
Orders
Inventory
Account balance changes
Permission updates
Multi-table writes

Transactions protect correctness.

APIs: REST, GraphQL, RPC, and Versioning

The frontend and backend need a communication contract.

That contract is usually an API.

API

API stands for Application Programming Interface.

An API defines how one system talks to another.

Office analogy:

API = Standard request form

The API defines:

Available operations
Required inputs
Response format
Error behavior
Authentication requirements
Authorization requirements
Versioning strategy

Example request:

GET /users/123

Example response:

{
  "id": 123,
  "name": "Alice",
  "role": "admin"
}

Good APIs are predictable.

Bad APIs require guessing.

JSON

JSON is a common data format for APIs.

Example:

{
  "id": 123,
  "name": "Alice",
  "active": true,
  "roles": ["admin", "billing"]
}

Office analogy:

JSON = Standard paper form

JSON is popular because it is:

Human-readable
Supported by most languages
Easy to transmit over HTTP
Natural for browser applications

Why use JSON instead of XML?

JSON is lighter and maps naturally to JavaScript objects.

XML supports schemas, namespaces, and document-style structures, but it is more verbose.

JSON	XML
Common in modern web APIs	Common in older systems and enterprise integrations
Less verbose	More verbose
Natural for JavaScript	Strong document markup features
Easy to read for simple data	Better for complex document formats

Use JSON for most modern web APIs unless you have a specific XML integration requirement.

REST API

REST is an API style centered around resources.

A resource is a thing.

Examples:

User
Order
Product
Invoice
Message

REST uses URLs and HTTP methods.

Examples:

GET /users
GET /users/123
POST /users
PATCH /users/123
DELETE /users/123

Office analogy:

REST = Standard forms for standard records

REST is popular because it is:

Simple
Familiar
Cache-friendly
Easy to debug
Easy to expose publicly
Compatible with basic HTTP tooling

Why use REST instead of GraphQL?

Use REST when:

Resources are clear
API shape is stable
Caching matters
Simplicity matters
Public API usability matters
Most clients need similar data

REST is often the better default for straightforward applications.

GraphQL

GraphQL lets the client request exactly the fields it needs.

Example:

{
  user(id: 123) {
    name
    email
    department
  }
}

Office analogy:

GraphQL = Custom report request

Instead of asking for a fixed report, the client says:

Give me these exact fields.

Advantages:

Flexible data fetching
Avoids over-fetching
Avoids under-fetching
Useful for complex frontends
Useful when one page needs data from many resources

Disadvantages:

More complex server implementation
Harder caching
More complex authorization
Query cost must be controlled
Can hide expensive database behavior

Why use GraphQL instead of REST?

Use GraphQL when clients have complex and varied data needs.

Example:

Mobile app needs 5 fields.
Admin dashboard needs 30 fields.
Partner integration needs a different shape.

GraphQL can let each client request its needed shape.

Do not use GraphQL only because it is modern.

Use it when the flexibility is worth the operational complexity.

RPC

RPC stands for Remote Procedure Call.

RPC thinks in actions instead of resources.

Examples:

POST /sendInvoice
POST /calculateTax
POST /startWorkflow
POST /approveApplication

Office analogy:

RPC = Ask a department to perform a specific task

REST often says:

Operate on this resource.

RPC often says:

Run this action.

Why use RPC instead of REST?

Use RPC when the operation is naturally an action and does not map cleanly to a resource.

Examples:

Start workflow
Generate report
Recalculate invoice
Send password reset
Approve application

REST can still model these, but sometimes the result becomes awkward.

Bad forced REST:

POST /reports/123/start-generation-command-request

Clear RPC-style endpoint:

POST /generateReport

Practical rule:

Use REST for resources.
Use RPC-style actions when the business operation is naturally a command.

API Versioning

APIs change over time.

Old clients may still depend on old behavior.

Versioning helps manage change.

Examples:

/api/v1/users
/api/v2/users

Office analogy:

API version = Updated form template

If the office changes a form, old departments may still need the old form for a while.

Versioning prevents breaking everyone at once.

Why version APIs?

Because breaking clients without warning is expensive.

API versioning helps with:

Backward compatibility
Migration planning
Deprecation
Public API stability
Client support

Versioning strategies:

Strategy	Example	Notes
URL version	`/api/v1/users`	Simple and visible
Header version	`Accept: application/vnd.app.v2+json`	Cleaner URLs, more hidden
Date version	`2025-05-25`	Common in some SaaS APIs
No explicit version	Stable internal APIs	Works only with strong compatibility discipline

For beginners, URL versioning is easiest to understand and operate.

Identity and Access: Auth, Sessions, Tokens, OAuth, and SSO

Identity and access are often confusing because many terms overlap.

The key distinction:

Authentication = Who are you?
Authorization = What are you allowed to do?

Authentication

Authentication proves identity.

Office analogy:

Authentication = Security guard checking ID

Examples:

Password login
One-time code
Passkey
Google login
GitHub login
Microsoft login
Hardware security key

Authentication succeeds when the system knows the user is who they claim to be.

Authentication alone does not grant full access.

Authorization

Authorization decides what an authenticated user may do.

Office analogy:

Authorization = Badge permissions

Example:

Alice logs in successfully.

The system checks:

Resource	Alice’s Access
Dashboard	Allowed
Billing page	Allowed
Admin panel	Denied
Payroll records	Denied

Authentication says:

This is Alice.

Authorization says:

Alice may access billing, but not payroll.

A common security bug is checking authentication but forgetting authorization.

Bad:

User is logged in, so allow access to /admin.

Better:

User is logged in.
Now check whether user has admin permission.

Roles and Permissions

A role is a permission group.

Examples:

Admin
Editor
Viewer
Billing manager
Support agent

Office analogy:

Role = Job title on badge

A permission is a specific allowed action.

Examples:

read:users
write:users
delete:orders
view:billing
export:data

Office analogy:

Permission = Specific room access on badge

Roles group permissions.

Example:

Role: Billing Manager
Permissions:
- view invoices
- create invoices
- refund payments

Why use permissions instead of only roles?

Roles are simple but can become too broad.

Permissions are more precise.

Design	Good For	Problem
Role-only	Small apps	Roles become too powerful
Permission-only	Fine-grained control	Harder to manage manually
Roles + permissions	Most serious apps	Requires design discipline

A good design often uses both:

Users receive roles.
Roles contain permissions.
Backend checks permissions.

Session

A session is a server-side login record.

Office analogy:

Session = Visitor record at security desk

Example server-side session record:

Session ID: abc123
User ID: user_42
Expires: 2025-05-25 17:00

The browser stores the session ID, often in a cookie.

When the browser sends a request, the server looks up the session ID.

If the session exists and is valid, the user is logged in.

Advantages:

Easy logout
Easy revocation
Centralized control
Server can update session state
Good for traditional web apps

Disadvantages:

Server must store session state
Scaling may require shared session storage
Requires coordination across servers

Sessions are stateful.

The server remembers users.

A cookie is a small piece of data stored by the browser and sent automatically with matching requests.

Office analogy:

Cookie = Small note carried by the visitor's assistant

A cookie may store:

Session ID
Refresh token
Preferences
Tracking identifier
Shopping cart ID

A cookie is not authentication by itself.

It is a storage and transport mechanism.

Important cookie flags:

Flag	Meaning
`HttpOnly`	JavaScript cannot read it
`Secure`	Sent only over HTTPS
`SameSite`	Controls cross-site sending
`Max-Age` / `Expires`	Controls lifetime
`Path`	Limits where cookie is sent
`Domain`	Controls which domain receives it

A safer authentication cookie commonly uses:

HttpOnly
Secure
SameSite=Lax or Strict

Access Token

An access token proves that a request is allowed.

Office analogy:

Access token = Temporary access badge

Example:

Authorization: Bearer eyJhbGciOi...

Access tokens are usually short-lived.

Why?

Because if they are stolen, the damage window is limited.

Common lifetimes:

5 minutes
15 minutes
30 minutes
1 hour

The correct lifetime depends on risk, user experience, and system design.

Refresh Token

A refresh token is used to obtain a new access token.

Office analogy:

Refresh token = Secure locker key used to get a new temporary badge

Common flow:

Access token expires
  |
  v
Client uses refresh token
  |
  v
Server issues new access token

Refresh tokens are powerful.

They should be protected carefully.

Common safer pattern:

Access token: short-lived
Refresh token: HttpOnly Secure cookie

JWT

JWT stands for JSON Web Token.

A JWT is a signed token format.

Office analogy:

JWT = Signed visitor badge

A JWT may contain claims:

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1735689600
}

Important:

JWT is a format.

It is not automatically secure.

It is not storage.

It is not OAuth.

The signature proves the token has not been modified.

Advantages:

Self-contained
Fast verification
Useful across distributed systems
No database lookup required for every request

Disadvantages:

Harder immediate revocation
Can become too large
Sensitive claims may be exposed if included carelessly
Must be short-lived when used as an access token

A common mistake:

We use JWT, so authentication is stateless and secure.

Not necessarily.

JWT solves signed claims.

It does not solve all authentication, authorization, storage, revocation, or session management problems.

Opaque Token

An opaque token is a random-looking token whose content is not meaningful to the client.

Example:

a8f9d2c7e1b4...

Office analogy:

Opaque token = Random badge number

The server must look it up.

Advantages:

Easy revocation
No exposed claims
Centralized control
Good for high-control systems

Disadvantages:

Requires lookup
Less self-contained
More dependency on token storage service

JWT vs opaque token

Question	JWT	Opaque Token
Contains readable claims?	Yes	No
Requires lookup?	Usually no	Yes
Easy to revoke immediately?	Harder	Easier
Good for distributed services?	Often	Also possible, but lookup required
Risk if logged accidentally?	Claims may leak	Less information leaks

Use JWTs when distributed verification matters.

Use opaque tokens when centralized control and revocation matter more.

Stateful vs Stateless Authentication

Stateful authentication means the server stores login state.

Example:

Session ID -> Server lookup -> User

Stateless authentication means the token carries enough signed information to verify the user.

Example:

JWT -> Verify signature -> Read claims

Office analogy:

Stateful:

Security desk keeps visitor records.

Stateless:

Visitor badge contains signed information.

Comparison:

Stateful Sessions	Stateless Tokens
Easy revocation	Easier horizontal scaling
Server stores session	Server verifies token
Central control	Less central lookup
Good for traditional web apps	Good for APIs and distributed systems
Requires shared session storage at scale	Requires careful expiration and key management

Neither is always better.

Choose based on operational needs.

OAuth

OAuth is delegated authorization.

Simple version:

OAuth lets one system grant another system limited access.

Office analogy:

OAuth = Trusted external office issues proof that another office accepts

Example:

You click:

Sign in with Google

The application does not directly handle your Google password.

Flow:

You go to Google.
Google verifies you.
Google sends proof back to the application.
The application trusts that proof.

OAuth is often used in login flows.

Strictly speaking, OAuth is about delegated access.

OpenID Connect

OpenID Connect, or OIDC, adds identity on top of OAuth.

Simple version:

OAuth = Delegated access
OIDC = Login identity layer

Office analogy:

OAuth = This visitor may access a department.
OIDC = This is who the visitor is.

If a site says:

Sign in with Google

it is often using OIDC.

SSO

SSO stands for Single Sign-On.

It lets one login work across multiple applications.

Office analogy:

SSO = One company badge works across many office buildings

Examples:

Google Workspace
Microsoft Entra ID
Okta
Auth0

SSO is common in organizations because users should not manage separate passwords for every internal tool.

Why use SSO instead of separate app passwords?

SSO improves centralized control.

Benefits:

One place to disable access
Easier onboarding and offboarding
Stronger MFA enforcement
Better auditability
Fewer passwords for users

Trade-off:

More dependency on identity provider
More setup complexity
Misconfiguration can affect many apps

For business applications, SSO is usually preferred.

MFA

MFA stands for Multi-Factor Authentication.

It requires more than one proof of identity.

Examples:

Password + authenticator app
Password + hardware security key
Password + phone code
Passkey + device verification

Office analogy:

MFA = ID card plus fingerprint check

MFA reduces risk when passwords are stolen.

For sensitive systems, MFA should be standard.

Browser Storage: Cookies, localStorage, and sessionStorage

The browser can store data in different places.

These options have different security properties.

Storage	Lifetime	Sent Automatically?	JavaScript Access?	Common Use
Cookie	Configurable	Yes	Depends on `HttpOnly`	Sessions, refresh tokens, preferences
localStorage	Until cleared	No	Yes	Non-sensitive persistent client state
sessionStorage	Tab lifetime	No	Yes	Temporary per-tab state

Office analogy:

Storage	Analogy
Cookie	Note automatically shown at the right office
localStorage	Notebook kept by assistant
sessionStorage	Temporary notepad for one visit

Important security point:

If malicious JavaScript runs on your page, it can read localStorage and sessionStorage.

It cannot read an HttpOnly cookie.

Why localStorage Can Be Risky for Tokens

Common beginner pattern:

localStorage.setItem("token", token);

This is convenient.

But if the page has an XSS vulnerability, malicious JavaScript can read the token.

Office analogy:

You placed your access badge in an unlocked notebook at reception.
Anyone who can reach the notebook can copy it.

A safer common pattern:

Short-lived access token: memory
Refresh token: HttpOnly Secure cookie

This does not make the application automatically secure.

It reduces one common exposure path.

Why use cookies for auth instead of localStorage?

Cookies with HttpOnly, Secure, and SameSite can reduce token theft through XSS.

However, cookies are automatically sent by the browser, so CSRF must be considered.

Option	Main Risk	Main Defense
localStorage token	XSS token theft	Prevent XSS, avoid storing sensitive tokens
Cookie token	CSRF and cookie misuse	SameSite, CSRF tokens, origin checks, HttpOnly, Secure

There is no perfect storage choice.

Choose based on threat model.

Security Concepts: HTTPS, CORS, CSRF, XSS, CSP, and Injection

Security is not one feature.

It is a set of layers.

HTTPS

HTTPS encrypts communication between browser and server.

Office analogy:

HTTPS = Sealed envelope

Without HTTPS, attackers may read or modify traffic.

Risks without HTTPS:

Password theft
Token theft
Session hijacking
Data leakage
Content tampering

Modern rule:

No HTTPS = no real web security.

TLS

TLS is the cryptographic protocol behind HTTPS.

Office analogy:

HTTPS = Using sealed envelopes
TLS = The sealing method

Most developers say HTTPS when discussing secure websites.

TLS is the underlying protocol.

Same-Origin Policy

The same-origin policy is a browser security rule.

It prevents one website from freely reading data from another website.

An origin is:

Scheme + Host + Port

Example origin:

https://example.com

Different origins:

http://example.com
https://example.com
https://api.example.com
https://example.com:8443

Office analogy:

Different branch offices cannot freely read each other's internal documents.

CORS is a controlled exception to this rule.

CORS

CORS stands for Cross-Origin Resource Sharing.

It controls which browser-based pages are allowed to read responses from another origin.

Office analogy:

CORS = Policy saying which outside reception desks may read responses from this office through browsers

Important:

CORS is enforced by browsers.

CORS does not stop:

curl
Postman
Server-to-server requests
Attackers directly calling your API

CORS is not authentication.

Bad assumption:

We configured CORS, so our API is secure.

Better understanding:

CORS controls browser response access.
Authentication and authorization control real access.

Why use CORS if it is not real API security?

Because browsers need a safe way to allow approved cross-origin frontend applications.

Example:

Frontend: https://app.example.com
API: https://api.example.com

These are different origins.

CORS allows the browser to read API responses only when the API permits it.

Use CORS for browser boundary control.

Use authentication and authorization for access control.

CSRF

CSRF stands for Cross-Site Request Forgery.

It tricks a user’s browser into sending an unwanted request to a site where the user is already logged in.

Office analogy:

Someone slips a form into your outgoing mail pile.
The form has your valid identity attached, but you did not intend the action.

Example:

You are logged into bank.com.
An attacker tricks your browser into submitting a transfer request.
Your browser includes your bank cookies automatically.

CSRF is especially relevant when authentication depends on automatically sent cookies.

Defenses:

SameSite cookies
CSRF tokens
Double-submit cookies
Origin header checks
Re-authentication for sensitive actions

XSS

XSS stands for Cross-Site Scripting.

It happens when an attacker gets malicious JavaScript to run in another user’s browser.

Example:

<script>stealTokens()</script>

Office analogy:

An attacker inserts fake instructions into official office documents.
Employees follow the instructions because they appear inside trusted documents.

XSS can allow attackers to:

Steal data
Perform actions as the user
Read localStorage
Modify the page
Capture input
Bypass some UI assumptions

Defenses:

Escape output
Sanitize user-provided HTML
Use safe templating
Avoid dangerous HTML injection
Use Content Security Policy
Validate and encode output
Use frontend frameworks correctly

XSS vs CSRF

Attack	What Happens	Main Risk
XSS	Malicious script runs inside trusted site	Attacker controls browser behavior inside app
CSRF	Browser sends unintended request with valid credentials	Attacker causes unwanted action

XSS is often more dangerous because it can perform actions directly from inside the trusted site.

Content Security Policy

Content Security Policy, or CSP, helps reduce XSS impact.

It tells the browser what scripts, styles, images, and other resources are allowed.

Office analogy:

CSP = Rulebook saying which instruction sources employees may trust

Example:

Content-Security-Policy: default-src 'self'; script-src 'self'

CSP is not a replacement for secure coding.

It is an additional layer.

Why use CSP if the app already escapes input?

Because security should be layered.

Escaping prevents many injection paths.

CSP reduces damage if a script injection bug still appears.

Use both.

SQL Injection

SQL injection happens when user input is treated as database code.

Unsafe example:

SELECT * FROM users WHERE email = '$email';

If $email contains malicious SQL, the query may behave dangerously.

Office analogy:

A visitor writes instructions on a form, and the filing room blindly follows them as official commands.

Defenses:

Parameterized queries
ORM query parameters
Input validation
Least-privilege database users
Avoid string-building SQL with untrusted input

Safer example:

cursor.execute("SELECT * FROM users WHERE email = %s", [email])

The input is treated as data, not code.

Input Validation

Input validation checks whether data is acceptable.

Office analogy:

Reception checks whether a form is complete and valid before sending it to a department.

Examples:

Email must look like an email.
Age must be a number.
File size must be below a limit.
Date must be valid.
Role must be one of the allowed roles.

Frontend validation improves user experience.

Backend validation protects the system.

Rate Limiting

Rate limiting restricts how many requests a client can make.

Office analogy:

A visitor may submit only 100 forms per minute.

Rate limiting helps reduce:

Brute force attacks
API abuse
Scraping
Accidental overload
Denial-of-service amplification

Example response:

429 Too Many Requests

Why rate limit if users are authenticated?

Because authenticated users can still abuse the system.

Examples:

Compromised account
Buggy client
Expensive endpoint spam
Credential stuffing
Scraper with valid account

Authentication identifies the user.

Rate limiting controls request volume.

Principle of Least Privilege

A user or service should have only the access it needs.

Office analogy:

Do not give every employee a master key.

Examples:

Frontend should not access the database directly.
Read-only service should not have write access.
Billing worker should not access admin settings.
Database user should not have unnecessary admin privileges.

Least privilege limits damage when something goes wrong.

Performance and Scaling

A small application can run on one server.

A larger application usually needs more careful design.

Performance and scaling are related but different.

Performance = How fast one request feels.
Scaling = How well the system handles more work.

Latency

Latency is the time it takes to get a response.

Office analogy:

How long a visitor waits before getting an answer.

Common causes of high latency:

Long database queries
Network distance
Large files
Slow backend logic
Too many API calls
Cold starts
Overloaded servers
External service delays

Reducing latency requires measurement.

Guessing is unreliable.

Throughput

Throughput is how much work the system can handle over time.

Office analogy:

How many visitors the office can serve per hour.

Latency is about one request.

Throughput is about many requests.

A system needs both:

Fast enough for one user.
Strong enough for many users.

Cache

A cache stores frequently used data closer to where it is needed.

Office analogy:

Instead of walking to the filing room every time, employees keep frequently used documents on a nearby desk.

Examples:

Browser cache
CDN cache
Application cache
Database query cache
Redis cache

Caching improves performance by avoiding repeated expensive work.

Common cached data:

Images
CSS
JavaScript
API responses
User sessions
Database query results

Main trade-off:

Faster reads vs stale data risk

Why not cache everything?

Because cached data can become wrong.

Before caching, ask:

What is cached?
Who can see it?
How long is it valid?
How is it invalidated?
What happens if stale data is shown?
Is the cached data user-specific?

Caching user-specific or permission-sensitive data requires care.

Browser Cache

The browser can store files locally.

Examples:

Images
CSS
JavaScript
Fonts

Office analogy:

The visitor keeps a copy of common brochures instead of asking reception every time.

Browser caching makes repeat visits faster.

Cache headers control behavior:

Cache-Control: public, max-age=31536000, immutable

For versioned static assets, long caching is safe.

For sensitive user data, avoid unsafe caching.

CDN

CDN stands for Content Delivery Network.

A CDN stores content in many geographic locations.

Office analogy:

Instead of making everyone visit headquarters, the company places document kiosks in many cities.

CDNs are useful for:

Images
Videos
CSS
JavaScript
Downloads
Static pages

Benefits:

Lower latency
Reduced server load
Better global performance
DDoS protection in some cases

Examples:

Cloudflare
Fastly
Akamai
Amazon CloudFront

Why use a CDN instead of only the application server?

Use a CDN when users are geographically distributed or static content is large.

Without CDN:

Every user downloads assets from the origin server.

With CDN:

Users download nearby cached copies.

This reduces latency and origin load.

Load Balancer

A load balancer distributes traffic across multiple servers.

Office analogy:

A traffic director sends visitors to different buildings so no single building becomes overloaded.

Example:

Request 1 -> Server A
Request 2 -> Server B
Request 3 -> Server C

Load balancers improve:

Scalability
Availability
Fault tolerance

If one server fails, the load balancer can stop sending traffic to it.

Why use a load balancer instead of one large server?

One large server is simpler.

Multiple smaller servers behind a load balancer can improve availability and scaling.

One Large Server	Load Balanced Servers
Simpler	More resilient
Easier debugging	More operational complexity
Single point of failure	Can survive one server failure
Limited vertical growth	Easier horizontal growth

Start simple.

Add load balancing when availability and traffic require it.

Reverse Proxy

A reverse proxy sits in front of application servers and routes requests.

Office analogy:

A front gate receives all visitors and sends them to the correct department.

Reverse proxies can handle:

Routing
TLS termination
Compression
Caching
Rate limiting
Security headers
Static file serving

Examples:

Nginx
HAProxy
Traefik
Envoy
Cloudflare

Simple flow:

Browser
  |
  v
Reverse Proxy
  |
  v
Application Server

Reverse proxy vs load balancer

They overlap in practice.

Reverse Proxy	Load Balancer
Routes requests to backend services	Distributes traffic across instances
Often handles TLS and headers	Often handles health checks and distribution
Can serve static files	Can remove unhealthy servers

Many tools do both.

Nginx, HAProxy, Envoy, and cloud load balancers can combine these roles.

Horizontal Scaling

Horizontal scaling means adding more machines.

Office analogy:

Open more office buildings.

Example:

1 server -> 3 servers -> 10 servers

Usually requires:

Load balancing
Shared database
Shared cache
Stateless application servers
Centralized logging
Consistent configuration

Horizontal scaling is common for web applications.

Vertical Scaling

Vertical scaling means making one machine bigger.

Office analogy:

Make the existing building larger.

Example:

2 CPUs -> 8 CPUs
8 GB RAM -> 64 GB RAM

Vertical scaling is simpler.

It has limits.

At some point, one machine cannot keep growing.

Horizontal vs vertical scaling

Question	Vertical Scaling	Horizontal Scaling
Simpler?	Yes	No
Handles one-server limit?	No	Yes
Improves availability?	Limited	Yes
Requires load balancer?	Usually no	Usually yes
Good first step?	Often	When traffic or availability requires it

A practical path:

Start with vertical scaling.
Move to horizontal scaling when needed.

Availability

Availability means the system is usable when people need it.

Office analogy:

The office is open and functioning.

High availability may require:

Multiple servers
Redundant databases
Health checks
Failover
Monitoring
Backups
Incident response

A system can be fast but not highly available.

A system can be highly available but slow.

They are related, but not identical.

Real-Time and Asynchronous Communication

Not every task should happen immediately inside a request.

Some work should happen later.

Some updates should be delivered live.

Polling

Polling means repeatedly asking for updates.

Example:

Is the report ready?
Is the report ready?
Is the report ready?

Office analogy:

A visitor keeps returning to reception every few seconds.

Advantages:

Simple
Works almost everywhere
Easy to reason about

Disadvantages:

Inefficient
Adds unnecessary load
Updates are not truly instant

Use polling for simple or low-frequency updates.

Long Polling

Long polling is a smarter form of polling.

The client asks for updates.

The server waits until something happens or a timeout occurs.

Office analogy:

The visitor asks reception to hold the request open until the report is ready.

Long polling reduces repeated requests.

It is still less suitable than streaming for frequent updates.

Server-Sent Events

Server-Sent Events, or SSE, allow the server to send one-way updates to the browser.

Office analogy:

The office announcement speaker broadcasts updates to visitors.

Good for:

Notifications
Job progress
Status updates
Monitoring dashboards
News feeds

SSE is simpler than WebSockets when communication only needs to go from server to client.

Why use SSE instead of WebSockets?

Use SSE when updates are one-way from server to client.

SSE	WebSocket
One-way server to client	Two-way communication
Simpler	More complex
Uses HTTP	Uses WebSocket protocol
Good for progress/status feeds	Good for chat/collaboration/games

If the browser only needs to receive updates, SSE is often enough.

WebSockets

WebSockets create a persistent two-way connection.

Office analogy:

A permanent phone line between visitor and office.

Useful for:

Chat
Multiplayer games
Collaborative editing
Live dashboards
Trading apps
Real-time notifications

Flow:

Client <-------> Server

Trade-offs:

More complex infrastructure
More complex scaling
Harder debugging
Long-lived connections must be managed carefully

Use WebSockets when two-way real-time communication is truly needed.

Do not use them just because they sound advanced.

Queue

A queue stores work to be processed later.

Office analogy:

A stack of work forms waiting in an inbox.

Instead of doing slow work during the user’s request, the backend can add a job to a queue.

Example:

User uploads video
  |
  v
Backend stores file
  |
  v
Backend adds "process video" job to queue
  |
  v
Worker processes job later

Queues are useful for:

Email sending
Video processing
Report generation
Data imports
Background cleanup
Notifications
Long-running jobs

Common queue systems:

RabbitMQ
Redis queues
Amazon SQS
Kafka
Google Pub/Sub
Celery
Sidekiq

Why use a queue instead of doing the work immediately?

Use a queue when work is slow, unreliable, or not required before responding to the user.

Without queue:

User waits 60 seconds.
Request may timeout.
Retry may duplicate work.

With queue:

User gets quick confirmation.
Worker processes job safely.
System can retry failed jobs.

Queues improve responsiveness and reliability.

They add operational complexity.

Worker

A worker processes background jobs.

Office analogy:

Back-office employee who handles tasks from the inbox

Workers allow the main application to respond quickly.

Example:

Without queue:

User waits 60 seconds for report.

With queue:

User submits request.
System says: Report is being generated.
Worker creates report in background.
User gets notified later.

Message Broker

A message broker moves messages between systems.

Office analogy:

Internal mailroom that routes envelopes between departments.

Examples:

RabbitMQ
Kafka
NATS
Redis Streams
Google Pub/Sub
Amazon SNS/SQS

Message brokers help decouple systems.

Instead of Service A directly calling Service B, Service A publishes a message.

Service B consumes it when ready.

Event-Driven Architecture

In event-driven systems, services react to events.

Examples:

UserSignedUp
PaymentCompleted
OrderShipped
PasswordChanged

Office analogy:

Departments listen for company announcements and act when relevant.

Example:

UserSignedUp event
  |
  +--> Send welcome email
  +--> Create billing profile
  +--> Initialize user settings
  +--> Notify analytics

Benefits:

Decoupled services
Flexible workflows
Easier async processing
Better isolation of slow work

Trade-offs:

Harder debugging
Event ordering issues
Duplicate events
Eventual consistency
More monitoring required

Why not make everything event-driven?

Because event-driven systems are harder to reason about.

A direct request is easier to follow:

A calls B and receives response.

Event-driven flow is less direct:

A publishes event.
B, C, and D may react later.

Use events when decoupling and async processing are worth the complexity.

Deployment, Environments, Containers, and Infrastructure

Code on a laptop is not the same as code running in production.

Production needs controlled configuration, repeatable deployment, monitoring, and rollback.

Environment

An environment is a place where the application runs.

Common environments:

Environment	Purpose
Local	Developer machine
Development	Shared test area
Staging	Production-like testing
Production	Real users

Office analogy:

Environment = Different branch office

Local:

Your personal desk.

Development:

Practice office.

Staging:

Dress rehearsal office.

Production:

Real office with real customers.

Production deserves special care.

Environment Variables

Environment variables are configuration values provided outside the code.

Examples:

DATABASE_URL
API_KEY
SECRET_KEY
NODE_ENV
DEBUG

Office analogy:

Environment variables = Branch-specific instruction sheet

The same code may run in staging and production with different configuration.

Example:

Staging database URL != Production database URL

Never hardcode secrets directly into source code.

Why use environment variables instead of config hardcoded in code?

Because code should be reusable across environments.

Bad:

DATABASE_URL = "postgres://prod-db.example.com"

Better:

DATABASE_URL = os.environ["DATABASE_URL"]

This allows the same application build to run in different places.

Build

A build prepares code for running or deployment.

Frontend build may:

Bundle JavaScript
Minify files
Compile TypeScript
Optimize images
Generate static pages

Backend build may:

Compile code
Install dependencies
Package files
Build a container image

Office analogy:

Build = Preparing all documents, tools, and furniture before opening the office.

Deploy

Deployment means releasing the application to an environment.

Office analogy:

Deploy = Open the new office version for use.

Deployment may involve:

Uploading files
Restarting services
Running database migrations
Updating containers
Changing traffic routing
Invalidating caches
Running smoke tests
Monitoring errors after release

A deployment is successful only if the application works after release.

The command finishing does not prove success.

CI/CD

CI/CD stands for Continuous Integration and Continuous Delivery or Deployment.

CI checks code automatically.

CD releases code automatically or semi-automatically.

Office analogy:

CI = Inspect every office change before approval.
CD = Roll out approved changes to branch offices.

CI may run:

Tests
Linters
Type checks
Security scans
Build checks

CD may:

Deploy to staging
Deploy to production
Run migrations
Roll back on failure

CI/CD reduces manual mistakes.

Why use CI/CD instead of manual deployment?

Manual deployment can work for small projects.

But it is easy to forget steps.

CI/CD improves:

Repeatability
Auditability
Speed
Confidence
Rollback discipline
Team collaboration

Manual steps should become automated when they are repeated and risky.

Container

A container packages an application with its dependencies.

Office analogy:

Container = Portable office room with everything needed inside

A container includes:

Application code
Runtime
System libraries
Configuration defaults

Docker is the most common container tool.

Containers help solve:

It works on my machine.

Because the application runs in a more consistent environment.

Image

A container image is the blueprint for creating containers.

Office analogy:

Image = Blueprint for portable office room
Container = Running room built from that blueprint

Example:

docker build -t myapp .
docker run myapp

The image is static.

The container is running.

Kubernetes

Kubernetes manages containers across many machines.

Office analogy:

Kubernetes = Facilities manager for many portable office rooms

It handles:

Starting containers
Restarting failed containers
Scaling replicas
Networking
Service discovery
Rolling updates
Configuration
Secrets
Health checks

Kubernetes is powerful.

It is also complex.

Why use Kubernetes instead of simple Docker or a PaaS?

Use Kubernetes when you need orchestration across many services and machines.

Do not use it only because it is popular.

Option	Good For	Trade-Off
Simple VM	Small apps, direct control	Manual operations
Docker Compose	Small multi-service deployments	Not ideal for large production scale
PaaS	Fast deployment, less ops	Less control, platform limits
Kubernetes	Large service orchestration	High complexity

For small applications, Kubernetes may be unnecessary.

Serverless

Serverless means you deploy functions or services without managing servers directly.

Examples:

AWS Lambda
Google Cloud Functions
Azure Functions
Cloudflare Workers
Vercel functions

Office analogy:

Serverless = On-demand contractor who appears when a task arrives

Benefits:

Less server management
Automatic scaling
Pay per use
Good for event-driven work

Trade-offs:

Cold starts
Execution time limits
Vendor-specific behavior
Harder debugging in some cases
Not always cheaper for steady high traffic

Serverless does not mean there are no servers.

It means you do not manage them directly.

Serverless vs containers

Question	Serverless	Containers
Need to manage servers?	Less	More
Good for bursty workloads?	Yes	Depends
Long-running tasks?	Often limited	Better
Portability?	Lower	Higher
Operational control?	Lower	Higher

Use serverless for event-driven, bursty, and small independent tasks.

Use containers when you need more control over runtime and long-running services.

Monitoring, Logging, and Reliability

A real production system needs visibility.

If you cannot observe the system, you cannot operate it reliably.

Logging

Logs are records of what happened.

Office analogy:

Logs = Office activity journal

Examples:

User logged in
Payment failed
Database query timed out
API returned 500
Email sent

Good logs help answer:

What happened?
When did it happen?
Who was affected?
Which request failed?
Which service caused the problem?

Bad logs either say too little or leak too much.

Avoid logging:

Passwords
Tokens
Full credit card numbers
Private health data
Secrets
Sensitive personal information

Why not log everything?

Because logs can become expensive, noisy, and dangerous.

Too much logging can:

Hide important events
Increase storage cost
Leak sensitive data
Slow applications
Make incident review harder

Log useful facts.

Do not log secrets.

Metrics

Metrics are numeric measurements over time.

Office analogy:

Metrics = Office dashboard

Examples:

Requests per second
Error rate
Latency
CPU usage
Memory usage
Queue length
Database connections
Cache hit rate

Metrics show system health.

Logs explain individual events.

You usually need both.

Tracing

Tracing follows a request across multiple services.

Office analogy:

A tracking slip follows a visitor request through every department.

Example:

Frontend
  |
  v
API Gateway
  |
  v
User Service
  |
  v
Billing Service
  |
  v
Database

Tracing helps answer:

Where did this request become slow?

Tracing matters more as systems become distributed.

Alerting

Alerting notifies people when something is wrong.

Office analogy:

Fire alarm or operations phone call

Examples:

Error rate above threshold
API latency above threshold
Database unavailable
Disk almost full
Payment failures increasing
Queue length growing too fast

Good alerts are actionable.

Bad alerts create noise.

If every small issue pages someone, people stop trusting alerts.

Health Check

A health check tells whether a service is working.

Office analogy:

A front gate asks each department: Are you open and ready?

Example:

GET /health

Response:

{
  "status": "ok"
}

Load balancers and orchestration systems use health checks to route traffic safely.

Liveness vs readiness

Check	Meaning
Liveness	Is the process alive?
Readiness	Is it ready to receive traffic?

A service may be alive but not ready.

Example:

App process is running, but database connection is not ready.

Readiness checks prevent traffic from reaching services too early.

Backup

A backup is a copy of important data.

Office analogy:

Duplicate archive stored safely elsewhere

Backups protect against:

Accidental deletion
Database corruption
Ransomware
Failed migrations
Hardware failure
Human error

A backup that has never been tested is only a hope.

You need restore tests.

Disaster Recovery

Disaster recovery is the plan for major failure.

Office analogy:

If headquarters burns down, how does the company continue operating?

Disaster recovery considers:

Backups
Restore time
Alternate regions
Failover
Data loss tolerance
Communication plans

Important terms:

Term	Meaning
RTO	Recovery Time Objective: how long until service returns
RPO	Recovery Point Objective: how much data loss is acceptable

Backup vs disaster recovery

Backup is a copy of data.

Disaster recovery is the plan to restore service.

You need both.

Common Architecture Patterns

Now that the pieces are clear, we can describe common system shapes.

Static Website

A static website serves pre-built files.

Examples:

HTML
CSS
JavaScript
Images

Office analogy:

A brochure stand

No employee has to generate a custom answer for every visitor.

Good for:

Blogs
Documentation
Marketing pages
Portfolios

Tools:

Jekyll
Hugo
Astro
Eleventy
Next.js static export
GitHub Pages

Benefits:

Fast
Cheap
Secure
Easy to host
CDN-friendly

Limitations:

Limited dynamic behavior unless using APIs
No server-side user-specific logic by default

Why use a static site instead of a full backend?

Use static sites when content does not need to be generated per user.

A blog does not need a database for every page view.

Static output is simpler, faster, and safer.

Server-Rendered App

A server-rendered app generates HTML on the server.

Office analogy:

Reception asks employees to prepare a custom document before handing it to the visitor.

Examples:

Rails
Django templates
Laravel Blade
Next.js server rendering
Nuxt server rendering

Benefits:

Good initial load
Good SEO
Centralized logic
Less client-side complexity

Trade-offs:

Server does more work
Scaling may require more backend capacity
Interactions may need additional JavaScript

Why use server rendering instead of SPA?

Use server rendering when SEO, initial page load, and simpler client behavior matter.

Examples:

Content sites
E-commerce pages
Documentation
Public dashboards
Traditional business applications

Single Page Application

A Single Page Application, or SPA, loads JavaScript once and updates the page dynamically.

Office analogy:

Reception gives the visitor an interactive kiosk that talks to departments through APIs.

Examples:

React SPA
Vue SPA
Angular app

Benefits:

Smooth interactions
App-like feel
Clear frontend/backend separation
Good for complex dashboards

Trade-offs:

More JavaScript
SEO complexity
Frontend state complexity
Authentication handling complexity
More client-side error modes

Why use an SPA instead of server-rendered pages?

Use an SPA when the user experience is highly interactive and app-like.

Examples:

Project management boards
Analytics dashboards
Design tools
Collaborative tools
Internal admin consoles

Do not use an SPA just because it is popular.

For content-heavy websites, server-rendered or static approaches may be better.

Full-Stack Framework

A full-stack framework combines frontend and backend patterns.

Examples:

Next.js
Nuxt
Remix
SvelteKit
Rails
Django
Laravel

Office analogy:

A company with a standard blueprint for reception, departments, forms, and records.

Benefits:

Faster development
Conventions
Integrated routing
Data loading patterns
Deployment patterns
Shared project structure

Trade-offs:

Framework rules
Less flexibility in some areas
Migration cost if framework direction changes
Hidden complexity behind abstractions

Why use a framework instead of assembling libraries manually?

Use a framework when conventions help the team move faster.

Use smaller libraries when you need more control or the project is simple.

Framework	Libraries
More structure	More flexibility
Faster standard development	More decisions required
Easier onboarding if common	Less lock-in
Hidden framework complexity	More visible architecture

Frameworks are useful when their defaults match your application.

Monolith

A monolith is one application containing many features.

Office analogy:

One large building with all departments inside.

Benefits:

Easier development at first
Simple deployment
Easier debugging
Strong consistency
Fewer network calls
Simpler local development

Trade-offs:

Can become large
Teams may step on each other
Scaling parts independently is harder
Poor structure can become painful

A monolith is not bad.

A well-structured monolith is often better than premature microservices.

Why start with a monolith?

Because most applications do not begin with enough scale or team complexity to justify microservices.

A modular monolith can provide clean internal boundaries without distributed system overhead.

Good path:

Start with a modular monolith.
Extract services only when there is a real reason.

Microservices

Microservices split a system into smaller independent services.

Office analogy:

Many specialized buildings connected by internal mail and phone lines.

Example services:

User service
Billing service
Search service
Notification service
Reporting service

Benefits:

Independent scaling
Independent deployment
Team ownership
Technology flexibility
Fault isolation if designed well

Trade-offs:

Network complexity
Harder debugging
Distributed failures
Data consistency problems
More operational overhead
More monitoring required

Microservices solve organizational and scaling problems.

They also create new problems.

Why use microservices instead of a monolith?

Use microservices when the organization or system has real independent domains that need separate deployment, scaling, or ownership.

Do not use microservices to make a small app look modern.

Monolith	Microservices
Simpler	More scalable organizationally
Easier debugging	Independent deployment
Stronger consistency	Independent scaling
Harder to scale parts separately	Harder distributed operations

Microservices require mature operations.

Without observability, automation, and clear ownership, they can become expensive chaos.

API Gateway

An API gateway sits in front of APIs and routes requests.

Office analogy:

Central reception for many departments and buildings

It may handle:

Routing
Authentication
Rate limiting
Request transformation
Logging
API versioning

API gateways are common in microservice architectures.

Why use an API gateway?

Use an API gateway when many backend services should appear as one entry point to clients.

Without gateway:

Client must know every service address.

With gateway:

Client calls one entry point.
Gateway routes internally.

This simplifies clients but adds gateway dependency.

Data Flow Examples

The concepts become clearer when shown as flows.

Example 1: User Opens Dashboard

User opens /dashboard
  |
  v
Browser sends request
  |
  v
Reverse proxy routes request
  |
  v
Backend checks session or token
  |
  v
Backend verifies user
  |
  v
Backend loads dashboard data
  |
  v
Database returns records
  |
  v
Server responds
  |
  v
Browser renders dashboard

Office version:

Visitor asks reception for dashboard.
Security checks badge.
Employee fetches records.
Reception presents result.

Example 2: User Logs In

User submits email and password
  |
  v
Backend validates credentials
  |
  v
Backend creates session or token
  |
  v
Browser stores cookie or token
  |
  v
Future requests include proof of login

Office version:

Visitor shows ID.
Security verifies it.
Security issues visitor record or badge.
Visitor uses it for future access.

Example 3: User Places an Order

Frontend sends POST /orders
  |
  v
Backend validates input
  |
  v
Backend checks authorization
  |
  v
Backend starts transaction
  |
  v
Backend writes order to database
  |
  v
Backend updates inventory
  |
  v
Backend commits transaction
  |
  v
Backend sends confirmation

Office version:

Reception receives order form.
Department checks form.
Records office stores it.
Inventory is updated.
Reception returns confirmation.

Example 4: User Uploads a File

User uploads file
  |
  v
Backend checks size and type
  |
  v
File stored in object storage
  |
  v
Database stores file metadata
  |
  v
Background worker scans or processes file

Office version:

Visitor submits a package.
Reception checks it.
Archive stores it.
Back-office worker processes it later.

Example 5: Long Report Generation

Bad design:

User requests report
  |
  v
Server spends 2 minutes generating it
  |
  v
User waits

Better design:

User requests report
  |
  v
Backend creates report job
  |
  v
Worker processes job
  |
  v
User receives notification

Office version:

Visitor requests a long report.
Reception gives a ticket.
Back office prepares report.
Visitor is notified when ready.

Example 6: API Behind CDN and Cache

Browser requests static file
  |
  v
CDN checks cache
  |
  +--> Cache hit: return file immediately
  |
  +--> Cache miss: fetch from origin
                    |
                    v
                 Origin server

Office version:

Visitor asks regional kiosk for a document.
If the kiosk has it, the visitor gets it immediately.
If not, the kiosk asks headquarters.

Common Beginner Confusions

This section summarizes concepts that are often mixed up.

Frontend vs Backend

Frontend:

What the user interacts with.

Backend:

Where the application rules and data processing happen.

Frontend can validate a form.

Backend must validate it again.

Frontend can hide a button.

Backend must still enforce permissions.

API vs Backend

The backend is the system doing the work.

The API is the interface used to request that work.

Office analogy:

Backend = Department
API = Request form

Server vs Database

The server runs application code.

The database stores data.

Office analogy:

Server = Office building or employees
Database = Filing room

They are often separate systems.

Cookie:

Small data stored by the browser.

Session:

Server-side record of a logged-in user.

A session ID is often stored inside a cookie.

That does not mean cookie and session are the same thing.

JWT:

Token format.

Cookie:

Browser storage and transport mechanism.

A JWT can be stored in a cookie.

A JWT can also be sent in an Authorization header.

They are different layers.

Authentication vs Authorization

Authentication:

Who are you?

Authorization:

What are you allowed to do?

A user can be authenticated but not authorized.

Example:

You are Alice.
Alice cannot access the admin page.

OAuth vs JWT

OAuth:

Authorization protocol / delegated access flow.

JWT:

Token format.

OAuth systems may use JWTs.

OAuth and JWT are not the same thing.

CORS vs Authentication

CORS controls browser cross-origin behavior.

Authentication controls who can access the API.

CORS is not access control.

Bad:

Only our frontend can call the API because CORS blocks others.

Wrong.

Better:

CORS helps browsers enforce origin policy.
The API still needs authentication and authorization.

XSS vs CSRF

XSS:

Attacker runs malicious JavaScript inside your site.

CSRF:

Attacker tricks the browser into sending an unwanted request using existing credentials.

XSS is usually more dangerous because it can defeat many CSRF protections.

PUT vs PATCH

PUT usually replaces an entire resource.

PATCH updates part of a resource.

Example:

PUT /users/123

means:

Replace user 123 with this full representation.

Example:

PATCH /users/123

means:

Change only these fields.

Library vs Framework

Library:

Tool you call.

Framework:

Structure that calls your code.

Office analogy:

Library = Optional tool in a department.
Framework = Company operating manual.

React is often described as a library.

Next.js is a framework built around React.

Build Time vs Runtime

Build time:

When the application is prepared.

Runtime:

When the application is running.

Office analogy:

Build time = preparing the office before opening.
Runtime = serving visitors after opening.

Some bugs happen because developers expect runtime values to be available at build time, or build-time variables to change at runtime.

Decision Tables

These tables help choose between common options.

REST vs GraphQL vs RPC

Need	Better Fit
Simple resource CRUD	REST
Public API with predictable resources	REST
Complex client-specific data shapes	GraphQL
Many frontend views with different field needs	GraphQL
Command-like operation	RPC
Internal service action	RPC
Easy HTTP caching	REST
Strong schema and typed queries	GraphQL

Practical default:

Start with REST.
Use GraphQL when client data shape complexity justifies it.
Use RPC for clear command-style operations.

Session vs JWT vs Opaque Token

Need	Better Fit
Traditional web app login	Session
Easy logout and revocation	Session or opaque token
Distributed API verification	JWT
Minimize token information leakage	Opaque token
Centralized access control	Session or opaque token
Stateless verification	JWT

Practical default:

Use sessions for normal server-rendered web apps.
Use short-lived tokens for APIs.
Use opaque tokens when revocation matters.
Use JWTs when distributed verification matters.

Need	Better Fit
Automatically send credential to same site	Cookie
Protect token from JavaScript access	HttpOnly cookie
Store non-sensitive UI preference	localStorage
Store per-tab temporary state	sessionStorage
Reduce CSRF risk	Authorization header or SameSite cookie design

Practical default:

Do not store long-lived sensitive tokens in localStorage unless you understand the XSS risk.

Static vs Server-Rendered vs SPA

Need	Better Fit
Blog, docs, portfolio	Static site
SEO-heavy dynamic pages	Server-rendered app
Traditional business app	Server-rendered app or full-stack framework
Highly interactive dashboard	SPA or full-stack framework
Low cost and high speed	Static site
User-specific server logic	Server-rendered app or backend API

Practical default:

Use the simplest rendering model that satisfies the user experience.

Monolith vs Microservices

Need	Better Fit
Small team	Monolith
Early product	Monolith
Strong consistency	Monolith
Independent team ownership	Microservices
Independent scaling per domain	Microservices
Many mature platform practices	Microservices

Practical default:

Start with a modular monolith.
Extract services when there is a clear operational or organizational reason.

Polling vs SSE vs WebSocket

Need	Better Fit
Simple occasional status check	Polling
Server-to-client updates	SSE
Two-way real-time communication	WebSocket
Chat or multiplayer	WebSocket
Job progress updates	SSE or polling
Maximum simplicity	Polling

Practical default:

Use polling first if update frequency is low.
Use SSE for one-way live updates.
Use WebSockets for true two-way real-time features.

Practical Rules of Thumb

These are not universal laws.

They are useful starting points.

Rule 1: Never Trust the Frontend

Anything in the browser can be inspected or modified.

Always enforce important rules on the backend.

Bad:

Hide admin button in frontend and assume user cannot access admin API.

Good:

Hide admin button for UX.
Also check admin permission on backend.

Rule 2: Validate Input Twice

Validate in the frontend for user experience.

Validate in the backend for security and correctness.

Frontend validation:

This field is required.

Backend validation:

This request is allowed, valid, and safe.

Rule 3: Use HTTPS Everywhere

Do not send passwords, tokens, cookies, or private data over plain HTTP.

Use HTTPS in production.

Always.

Rule 4: Keep Access Tokens Short-Lived

If an access token leaks, expiration limits damage.

Short-lived tokens are safer than long-lived ones.

Rule 5: Be Careful With localStorage

localStorage is convenient.

It is also readable by JavaScript.

If your page has XSS, localStorage tokens may be stolen.

Rule 6: Do Not Put Secrets in Frontend Code

Frontend code is public to users.

Never put these in frontend code:

Private API keys
Database passwords
Signing secrets
Admin tokens
Service credentials

If the browser can read it, users can read it.

Rule 7: Use the Database as the Source of Truth

Caches are copies.

Search indexes are copies.

Frontend state is a copy.

The database is usually the source of truth.

When copies disagree, know which one wins.

Rule 8: Add Caching Only When You Understand Staleness

Caching can make apps faster.

It can also make apps confusing.

Before caching, ask:

What data is cached?
How long is it valid?
Who can see it?
How is it invalidated?
What happens if it is stale?

Rule 9: Use Queues for Slow Work

If something takes a long time, consider a background job.

Examples:

Sending email
Generating reports
Processing videos
Importing large files
Running data analysis

Do not make users wait unnecessarily.

Rule 10: Logs Should Help, Not Leak

Good logs help debug.

Bad logs expose secrets.

Never log:

Passwords
Tokens
Secret keys
Sensitive personal data
Full payment details

Rule 11: Prefer Boring Technology Until You Have a Reason Not To

Boring technology is not bad.

It is easier to hire for, debug, secure, and operate.

Examples of boring good defaults:

PostgreSQL for relational data
REST for simple APIs
Server-rendered pages for content-heavy apps
Sessions for traditional web login
Static hosting for blogs and documentation

Use advanced tools when they solve a real problem.

Do not use them only because they sound impressive.

Rule 12: Measure Before Optimizing

Do not guess where the bottleneck is.

Measure:

Latency
Error rate
Query time
Cache hit rate
CPU
Memory
Queue length
External service time

Optimization without measurement often improves the wrong thing.

Extended Reference Table

Term	Plain Meaning	Office Analogy
User	Person using the app	Visitor
Browser	Software that accesses websites	Visitor’s assistant
Domain	Human-readable website name	Street address
DNS	Converts domain to address	Address lookup
IP Address	Network location	Physical location
URL	Full web address	Full office instruction
HTTP	Request/response protocol	Office communication protocol
HTTPS	Encrypted HTTP	Sealed envelopes
Header	Request/response metadata	Form label/instruction
Body	Main request/response content	Main form contents
Frontend	User interface	Reception desk
Backend	Application logic	Employees and departments
Server	Computer running software	Office building
Database	Persistent data storage	Filing room
Transaction	All-or-nothing database unit	Complete records update
Index	Faster lookup structure	Catalog card
API	Interface for communication	Request form
JSON	Data format	Standard paper form
REST	Resource-based API style	Standard office forms
GraphQL	Query-based API style	Custom report request
RPC	Action-based API style	Task request
Authentication	Prove identity	Security guard checks ID
Authorization	Check permissions	Badge access
Role	Permission group	Job title
Permission	Specific allowed action	Room access
Session	Server-side login record	Visitor record
Cookie	Browser-stored data	Note in pocket
Access Token	Short-lived credential	Temporary badge
Refresh Token	Token for renewal	Locker key
JWT	Signed token format	Signed badge
Opaque Token	Random server-checked token	Badge number
OAuth	Delegated access	Trusted external badge flow
OIDC	Identity layer on OAuth	Verified identity badge
SSO	One login for many apps	Company-wide badge
MFA	Multiple identity proofs	ID plus fingerprint
XSS	Malicious script injection	Fake instructions in trusted docs
CSRF	Forged request	Form slipped into outgoing mail
CORS	Browser origin policy exception	Approved caller policy
CSP	Script/source restrictions	Trusted instruction rulebook
Rate Limit	Request limit	Forms per minute limit
Cache	Faster copy of data	Documents on nearby desk
CDN	Global content cache	Regional document kiosk
Load Balancer	Traffic distributor	Visitor traffic director
Reverse Proxy	Front-facing router	Front gate
Queue	Stored background work	Work inbox
Worker	Background processor	Back-office employee
Message Broker	Routes messages	Internal mailroom
Event	Something that happened	Company announcement
Container	Packaged runtime	Portable office room
Image	Container blueprint	Office room blueprint
Kubernetes	Container orchestrator	Facilities manager
Serverless	Managed execution	On-demand contractor
CI/CD	Automated test and release	Inspection and rollout pipeline
Logging	Event records	Office activity journal
Metrics	Numeric measurements	Operations dashboard
Tracing	Request path tracking	Tracking slip
Alerting	Notifications on failure	Alarm system
Health Check	Service readiness check	Department open check
Backup	Data copy	Duplicate archive
Disaster Recovery	Failure recovery plan	Emergency relocation plan

Final Mental Model

A modern web application is not one thing.

It is a chain of cooperating parts.

User
  |
  v
Browser
  |
  v
Domain / DNS
  |
  v
Internet
  |
  v
CDN / Load Balancer / Reverse Proxy
  |
  v
Frontend or Server-Rendered Page
  |
  v
API
  |
  v
Backend
  |
  +-------------------+
  |                   |
  v                   v
Database             Cache
  |
  v
Background Jobs / Queues / Workers
  |
  v
External Services

The browser does not usually talk directly to the database.

The frontend does not own security rules.

The API is not the same as the backend.

Cookies are not the same as sessions.

JWTs are not the same as OAuth.

CORS is not authentication.

A cache is not the source of truth.

A queue is not instant work.

A deployment is not successful just because the command finished.

These distinctions matter.

Once the flow is clear, the jargon becomes easier to understand.

Final Thoughts

Web development feels complicated when it is taught as a pile of disconnected terms.

But most concepts exist to answer practical engineering questions:

How does the user reach us?
How do we show information?
How do we process requests?
How do we store data?
How do we know who the user is?
How do we decide what they can access?
How do we stay secure?
How do we stay fast?
How do we handle more traffic?
How do we release changes safely?
How do we recover when something breaks?

The office-building model gives a stable map.

Start with the journey:

Visitor -> Address -> Front Gate -> Reception -> Security -> Department -> Filing Room -> Response

Then map each technical term onto that journey.

That is the simplest way to understand full-stack web development without memorizing jargon.

The Big Picture

Core Mapping

Finding the Building: Domain, DNS, IP, and URL

Domain Name

Why use a domain name instead of an IP address?

DNS

Why use CNAME instead of A record?

IP Address

URL

URL vs URI

Browser, HTTP Requests, and HTTP Responses

Browser

HTTP Request

HTTP Response

HTTP Methods

Why use GET instead of POST for reading data?

HTTP Status Codes

Why use specific status codes instead of always returning 200?

Headers

Frontend, Backend, and Database

Frontend

Why use frontend validation if backend validation is still required?

HTML

CSS

JavaScript

Why use TypeScript instead of JavaScript?

Backend

Why use a backend instead of calling the database directly from the frontend?

Database

Relational Database

Why use PostgreSQL instead of MongoDB?

NoSQL Database

Database Index

Why not index every column?

Transactions

Why use transactions?

APIs: REST, GraphQL, RPC, and Versioning

API

JSON

Why use JSON instead of XML?

REST API

Why use REST instead of GraphQL?

GraphQL

Why use GraphQL instead of REST?

RPC

Why use RPC instead of REST?

API Versioning

Why version APIs?

Identity and Access: Auth, Sessions, Tokens, OAuth, and SSO

Authentication

Authorization

Roles and Permissions

Why use permissions instead of only roles?

Session

Cookie

Access Token

Refresh Token

JWT

Opaque Token

JWT vs opaque token

Stateful vs Stateless Authentication

OAuth

OpenID Connect

SSO

Why use SSO instead of separate app passwords?

MFA

Browser Storage: Cookies, localStorage, and sessionStorage

Cookie vs localStorage vs sessionStorage

Why localStorage Can Be Risky for Tokens

Why use cookies for auth instead of localStorage?

Security Concepts: HTTPS, CORS, CSRF, XSS, CSP, and Injection

HTTPS

TLS

Same-Origin Policy

CORS

Why use CORS if it is not real API security?

CSRF

XSS

XSS vs CSRF

Content Security Policy