Cyber Security Basics
📂 Foundation
· 7 of 15
75 min read
Building the Web — A Cybersecurity Perspective
A 24-section cybersecurity walkthrough of how Tim Berners-Lee's three inventions at CERN (URL, HTTP, HTML) became the modern Web — and how we defend it. Covers DNS, TLS 1.3, OWASP Top 10, XSS/SQLi/CSRF, WAF, API security, bot management, Web3 — with real cases: Equifax, MyEtherWallet, British Airways Magecart, Heartbleed, Bybit's $1.5B theft, and the 31.4 Tbps Aisuru DDoS.
Section 01
The Web by the Numbers — Scale Equals Attack Surface
The World Wide Web is the largest software artefact humans have ever built. Every
number below also represents a defensive challenge — each website is a potential
victim, each user is a potential phishing target, each cookie is a potential
session-hijack opportunity.
🌐
Websites Worldwide
~1.1 Billion
Roughly one website per five humans alive. Many run on outdated CMS installs, abandoned plugins, and forgotten subdomains — the long tail of the Web is where most breaches start.
👥
Active Internet Users
5.5 Billion
Roughly two-thirds of humanity. Each is a potential credential reuse victim — the average person has 100+ online accounts protected by a handful of repeated passwords.
🚨
Sites Hacked Daily
30,000+
Mostly through known, patchable vulnerabilities. The defenders' problem is almost never "this attack was too sophisticated" — it is "we didn't patch in time."
💰
Avg. Data Breach Cost
$4.88 Million
2024 IBM Cost of a Data Breach report. Health and financial sectors run significantly higher — Change Healthcare's 2024 breach is estimated above $2.4 billion in total cost.
⚠️
The Core Insight
Every line of HTML, every API endpoint, every cookie, every header is a
potential entry point. Security must be built into the Web — not
bolted on later. Most of the Web's vulnerability classes exist
because the original protocols (HTTP, DNS, SMTP) trusted everyone, and we
have been retrofitting security ever since.
Section 02
Origins of the World Wide Web — From a Physics Lab to Civilisation
📖 Origin Story
Sir Tim Berners-Lee, CERN, 1989–1991
In 1989, a young British software engineer at the European Organisation
for Nuclear Research (CERN) in Switzerland circulated a proposal titled
"Information Management: A Proposal." His name was Tim Berners-Lee.
His goal was modest: help physicists share research papers between incompatible
computers.
To do it, he invented three things at once on a NeXT computer
that still sits in the CERN museum: the URL (so any document
could be uniquely named), HTTP (so a client could ask for a
document by name), and HTML (so the document could link to
other documents). The first website went live on
info.cern.ch in August 1991.
Thirty-six years later, those three inventions carry the entire global economy.
📅 Five Years That Built the Web
💡
The Decision That Shaped the Web
On 30 April 1993, CERN released the Web's source code into
the public domain — no royalties, no patents. That single decision is the
reason the Web grew explosively, but it is also why nobody owns
Web security. Every browser, every server, every protocol must reach
consensus through the W3C and IETF, which is slow and political — and which
is why retrofitting security takes decades.
Section 03
The Three Foundational Pillars — URL, HTTP, HTML
The entire Web — every Google search, every banking app, every YouTube video —
still rests on the three primitives Berners-Lee invented at CERN. Each of them
is also the entry point for a distinct family of attacks.
🔗
URL
Uniform Resource Locator
A globally unique address scheme to identify any document or resource:
https://example.com/page. Defined by RFC 3986. Every URL has
a scheme, host, port, path, query, and fragment.
Security: URL parsing flaws lead to SSRF, open redirects,
and host-header attacks. Unicode lookalikes ("раура1.com" vs "paypal.com")
enable IDN homograph phishing.
📤
HTTP
Hypertext Transfer Protocol
A stateless request-response protocol for transferring documents between
client and server: GET /index.html HTTP/1.1. Versions evolved
from HTTP/0.9 (1991) through HTTP/3 (2022, over QUIC).
Security: Plain-text by default. Security depends on TLS
(HTTPS) and on response headers. Smuggling, request splitting, and header
injection target the protocol itself.
📝
HTML
Hypertext Markup Language
A markup language for structuring documents with semantic tags and
hyperlinks: <a href='...'>link</a>. Now at HTML5,
supporting embedded scripting, multimedia, and forms.
Security: Improperly escaped HTML leads to
Cross-Site Scripting (XSS) and content injection — still
the single most common Web vulnerability class four decades after invention.
Section 04
Client-Server Architecture — The Pattern Behind Every Web Interaction
Every Web interaction follows the same fundamental pattern: a client
sends a request, a server processes it and sends back a response.
Each component along the path is also an attack surface.
📧 The Universal Web Communication Pattern
📐
The Defender's Mantra
Trust nothing. Validate everything. Every arrow in the
diagram crosses a trust boundary; every component is a potential point of
compromise. A breach can come from a malicious client, a tampered request
mid-flight, a vulnerable web server, application logic that mishandles
input, or a database that leaks more than it should.
Section 05
Anatomy of a Web Request — Eight Stages, Eight Attack Surfaces
When you type https://example.com and press Enter, your browser
silently performs eight distinct operations in sequence. Each
one is exploitable. Memorise the eight; you will see them in every Web breach
post-mortem you ever read.
1
URL Parse
Browser parses https://example.com/page?id=1 into scheme + host + port + path + query. Attacks: URL injection, IDN homograph (Unicode lookalikes), open redirects, host-header confusion.
2
DNS Resolution
Hostname is resolved to an IP via recursive lookup (Root → TLD → Authoritative). Attacks: DNS spoofing, cache poisoning, DNS hijacking. The MyEtherWallet incident of April 2018 combined BGP and DNS hijacking to steal $160K in crypto in a single afternoon.
3
TCP Handshake
Three-way SYN/SYN-ACK/ACK exchange establishes a reliable connection. Attacks: SYN flood (Layer 4 DDoS), man-in-the-middle interception, sequence-number prediction.
4
TLS Handshake
Client and server agree on cipher, exchange keys, validate certificates. Attacks: Certificate spoofing (rogue CAs), protocol downgrade attacks (forcing TLS 1.0), Heartbleed-class memory disclosure (2014).
Application code reads input, queries database, performs logic. Attacks: SQL injection, command injection, Server-Side Request Forgery (SSRF), insecure deserialisation. Equifax 2017 was an unpatched Apache Struts vulnerability at this stage that leaked 147 million records.
7
HTTP Response
Server sends status code + headers + body. Attacks: missing security headers (no HSTS, no CSP), information disclosure via verbose error pages, cache-poisoning through cacheable secrets.
8
Browser Render
Browser parses HTML, downloads scripts, builds DOM, executes JavaScript. Attacks: Cross-Site Scripting (XSS), DOM clobbering, malicious script execution, supply-chain attacks via tampered CDN scripts (as in British Airways Magecart 2018).
Section 06
HTTP Methods — The Verbs of the Web
HTTP defines a small set of methods (or "verbs") that express
what the client wants to do with a resource. Knowing them is essential because
each carries different security expectations.
Method
Purpose
Properties
Security Notes
GET
Retrieve a resource
Safe, idempotent, cacheable
Never use for state changes; URL params get logged everywhere
POST
Submit data, create resource
Not safe, not idempotent
The main target of CSRF; needs CSRF token + SameSite cookies
PUT
Replace resource entirely
Not safe, idempotent
Beware mass-assignment vulnerabilities
DELETE
Remove a resource
Not safe, idempotent
Authorisation check is critical — broken access control = data loss
PATCH
Partial update
Not safe, not idempotent
Validate only allowed fields can be patched
HEAD
Like GET, headers only
Safe, idempotent
Often used by attackers for reconnaissance
OPTIONS
Discover allowed methods (CORS preflight)
Safe, idempotent
Misconfigured CORS responses leak attack surface
💡
"Safe" vs "Idempotent" — The Distinction That Matters
A method is safe if it does not modify state on the server.
It is idempotent if calling it ten times has the same effect
as calling it once. GET is both. DELETE is idempotent but not safe (the
resource gets deleted, but doing it twice doesn't delete it more).
POST is neither — that is why it triggers most security concerns.
Section 07
HTTP Status Codes — What the Server Is Telling You
Every HTTP response carries a three-digit status code. The first digit groups
them into five families; the second and third refine the meaning. Knowing the
families saves you debugging time and prevents subtle security mistakes.
✅
2xx — Success
it worked
200 OK — standard success. 201 Created —
resource newly created. 204 No Content — success but no body.
Security: Never return 200 from a failed login. Use 401 instead.
Confusing success/failure semantics breaks audit logs.
🔄
3xx — Redirection
go look elsewhere
301 moved permanently, 302 temporary,
304 not modified (cache hit).
Security: Open redirects (where the redirect target is user-controlled)
are a classic phishing aid. Always validate redirect targets against an allow-list.
❌
4xx — Client Error
your fault
400 bad request, 401 unauthorised (not authenticated),
403 forbidden (authenticated but not allowed),
404 not found, 429 rate limited.
Security: Don't leak whether a username exists by returning different errors.
🔥
5xx — Server Error
our fault
500 generic, 502 bad gateway,
503 service unavailable, 504 gateway timeout.
Security: Never leak stack traces, file paths, or framework versions
in 5xx responses. Generic error pages only.
Section 08
The Critical HTTP Security Headers
HTTP headers are how the server tells the browser what it should and should not
do. The right combination of security headers can stop entire classes of attacks
before they reach your application logic. The wrong (or absent) combination
leaves you wide open.
Header
What It Does
Attacks It Blocks
Strict-Transport-Security (HSTS)
Forces HTTPS for the domain for a specified duration
Protocol downgrade, SSL-strip
Content-Security-Policy (CSP)
Whitelist allowed sources for scripts, styles, frames, images
XSS (the strongest defence)
X-Frame-Options
Prevents the page from being embedded in an iframe
Clickjacking
X-Content-Type-Options
Disables MIME-type sniffing (nosniff)
Drive-by execution of user-uploaded files
Referrer-Policy
Controls how much of the referring URL is sent to third parties
Information leakage to ad networks
Permissions-Policy
Restricts powerful browser features (camera, mic, geolocation)
Privacy abuse, surveillance
Cross-Origin-Opener-Policy
Isolates the document from cross-origin window references
Spectre-class cross-origin leaks
🛡️
The Minimum Viable Header Stack for 2025
Every modern Web service should send: HSTS (with at least
one year max-age), CSP (with no unsafe-inline),
X-Frame-Options DENY or CSP frame-ancestors,
X-Content-Type-Options nosniff, and Referrer-Policy
strict-origin-when-cross-origin. You can verify yours at
securityheaders.com — failing this baseline is malpractice.
Section 09
The Evolution of the Web — Three Eras, Three Threat Models
The Web didn't arrive in one piece. It evolved through three distinct eras, each
introducing new capabilities — and each opening entirely new attack surfaces.
An attacker today must defend against all three layers simultaneously.
📅 Web 1.0 → 2.0 → 3.0
Section 10
DNS — The Internet's Phonebook (and a Favourite Target)
📲 The System That Translates Names to Numbers
Why DNS Is the Most Attacked Internet Protocol
Humans remember names; computers route by numbers. The Domain Name System
(DNS), defined by RFCs 1034/1035 in 1987, bridges the two. When you type
example.com, four cooperating servers turn it into an IP like
93.184.216.34 — usually in tens of milliseconds.
Because every Web request begins with a DNS lookup, compromising DNS
compromises everything downstream. Nation-state actors prize DNS
attacks because they can silently redirect users to attacker-controlled
servers without touching the target's actual systems.
🔎 How a DNS Lookup Works
Step 1
Browser asks the recursive resolver (usually your ISP's, or 1.1.1.1, 8.8.8.8). The resolver checks its cache first.
Step 2
If not cached, the resolver queries the Root servers (".") → TLD servers (".com") → Authoritative name server for the specific domain (example.com NS).
Step 3
The authoritative server returns the IP record (A for IPv4, AAAA for IPv6, CNAME for aliases).
Step 4
Resolver caches the answer (honouring its TTL) and returns it to the client. Subsequent queries for the same name within the TTL window use the cache.
⚠️
Cache Poisoning
forged responses
Attacker injects forged DNS responses into a resolver's cache, redirecting
users to a malicious server. Dan Kaminsky's 2008 disclosure of the
"Kaminsky bug" forced an emergency global patching effort.
🔒
DNS Hijacking
registrar compromise
Attacker takes over the registrar account or compromises the upstream
authoritative server. Once the NS records are theirs, every visitor goes
to the attacker's IP. The 2018 MyEtherWallet attack drained ~$160K
via combined BGP and DNS hijacking.
🛡️
DNSSEC
cryptographic signing
DNS Security Extensions (RFC 4033) sign every record with public-key
cryptography. A poisoned response without a valid signature is rejected.
Adoption is still patchy — roughly 30% of .com domains as of 2025.
🔐
DoH / DoT
encrypted queries
DNS-over-HTTPS (RFC 8484) and DNS-over-TLS (RFC 7858) encrypt the query
itself, so eavesdroppers and ISPs cannot see which sites you are visiting.
Now standard in Firefox, Chrome, Android, and iOS.
Section 11
HTTPS & TLS — Encryption at the Transport Layer
🔐 The "S" in HTTPS
From Optional Luxury to Mandatory Default
Until roughly 2014, HTTPS was reserved for banking, e-commerce, and login
pages. The rest of the Web ran over cleartext HTTP — eavesdroppable from
any cafe Wi-Fi, any ISP, any government tap.
The turning point came in 2015–2016 when Let's Encrypt
(run by the non-profit ISRG) made TLS certificates free and automatically
renewed. Combined with Google's "Not Secure" warnings in Chrome (2017+),
HTTPS adoption exploded from ~40% to over 95% of the Web
today. Encryption became the default, not the exception.
👁️
Confidentiality
no one can read it
Traffic is encrypted with symmetric ciphers (AES-GCM, ChaCha20-Poly1305)
using session keys derived during the handshake. Eavesdroppers on the
wire — your ISP, the airport Wi-Fi, the carrier backbone — see only
meaningless ciphertext.
🛡️
Integrity
no one can tamper with it
Authenticated Encryption with Associated Data (AEAD) modes attach a
cryptographic tag to every record. Any modification — even a single bit
flip — invalidates the tag and the receiver rejects the packet.
📝
Authenticity
you know who you're talking to
X.509 certificates issued by trusted Certificate Authorities (CAs) cryptographically
prove the server is who it claims to be. The browser maintains a list of
trusted root CAs; certificates not chaining back to one are rejected.
Even when the protocol is sound, implementation bugs can ruin everything.
Heartbleed (CVE-2014-0160) was a memory-disclosure bug in
OpenSSL that let any attacker dump up to 64 KB of server memory per query —
potentially including private keys, passwords, and session tokens. It
affected an estimated 17% of all secure web servers worldwide.
The incident directly led Google to launch Project Zero a
few months later.
Section 12
The TLS 1.3 Handshake — Five Steps to a Secure Channel
TLS 1.3 (RFC 8446) completed in 2018 dramatically simplified the handshake.
Previous versions needed two round trips and supported a vast menu of insecure
ciphers. TLS 1.3 reduced it to one round trip and removed
every option that was not provably secure. The result: faster and more
secure simultaneously.
🔐 TLS 1.3 Sequence Diagram
Section 13
Cookies, Sessions & Authentication
🍪 The Stateless Protocol That Pretends to Remember You
Why HTTP Cookies Were Invented at Netscape in 1994
HTTP is fundamentally stateless: each request stands alone,
with no memory of any prior request. That was fine when the Web was just
static documents — but useless the moment shopping carts and logins arrived.
In 1994, Netscape engineer Lou Montulli invented the
HTTP cookie: a small key-value pair that the server sets
once and the browser obediently sends back on every subsequent request to
that domain. With cookies, the server can recognise you across requests —
"logged in as Alice, cart has 3 items, language: en-US."
Three decades later, cookies still power almost every login on the Web, and
every Web vulnerability touching authentication eventually touches cookies.
Critical Cookie Attributes
🔐
Secure
HTTPS-only flag
The cookie is sent only over HTTPS connections. Without it, an attacker on
the same network can sniff the cookie in cleartext over HTTP. Should be set
on every authentication cookie, always.
🕔
HttpOnly
no JavaScript access
The cookie cannot be read by document.cookie in JavaScript.
Even if an XSS attack succeeds in injecting a script, the session cookie
stays out of reach. A simple checkbox that defeats most session-stealing XSS.
🚫
SameSite
CSRF defence
Controls when the cookie is sent on cross-site requests. Strict
blocks all cross-site sending. Lax (the modern default in Chrome)
blocks most. None (requires Secure) allows cross-site. SameSite is
the strongest single defence against CSRF.
🎯
Domain / Path
scope of sending
Controls which subdomains and paths receive the cookie. Set as narrowly
as possible. A cookie scoped to app.example.com won't leak to
blog.example.com.
The Four Modern Authentication Approaches
🔑
Session Cookies
The server stores the session state (logged-in user, cart, preferences) in
its own memory or Redis; the cookie contains only a random session ID. Simple,
secure, easy to revoke (just delete the server-side record). Still the default
for most Web apps.
classic and reliable
📝
JWT (JSON Web Tokens)
A self-contained, cryptographically-signed token carrying claims (user ID,
roles, expiry). Stateless — the server need not store anything. Great for
APIs and microservices. The trade-off: revocation is hard — once issued,
a JWT is valid until it expires.
stateless, popular for APIs
🤝
OAuth 2.0 / OIDC
Delegated authorisation: "Let me sign in with Google / GitHub / Microsoft."
The third party verifies the user and returns an access token. The standard
for Single Sign-On (SSO). OAuth 2.0 is the framework; OpenID Connect adds
authentication on top.
the SSO standard
🔒
MFA / Passkeys
Adds something-you-have (a phone, a hardware key, a passkey) to
something-you-know (a password). Passkeys (WebAuthn)
eliminate passwords entirely using public-key cryptography stored in the device
Secure Enclave / TPM. Phishing-resistant by design — the standard for 2025+.
the password's eventual replacement
Section 14
The Browser Security Model — Isolating Untrusted Code
Your browser runs untrusted code (JavaScript from every website you visit) on
your personal device, with access to your camera, microphone, location, and
saved passwords. The fact that this does not end in immediate disaster
is thanks to six interlocking security mechanisms in the modern browser.
⚖️
Same-Origin Policy (SOP)
the bedrock
Scripts loaded from one origin (scheme + host + port) cannot
read data from a different origin. https://bank.com JavaScript
cannot read https://gmail.com's DOM, cookies, or responses.
Without SOP, every site you visit could pillage every other site you are logged in to.
🔄
CORS
controlled relaxation
Cross-Origin Resource Sharing lets a server opt-in to specific
origins reading its responses via Access-Control-Allow-Origin
headers. Misconfigured CORS (wildcards on authenticated endpoints) is a
common API breach pattern.
📦
Process Sandboxing
OS-level isolation
Each tab runs in its own operating-system process with severely restricted
privileges — no file-system access, no arbitrary syscalls. A renderer
compromise stays inside the sandbox rather than spreading to the OS.
🏘️
Site Isolation
post-Spectre defence
Different sites get different OS processes. Introduced by Chrome in 2018
after the Spectre/Meltdown CPU bugs showed that one
process could leak another process's memory through speculative execution.
Still the most expensive single security feature browsers carry.
🚫
Mixed-Content Blocking
HTTPS purity
HTTPS pages can no longer load scripts, stylesheets, or iframes over plain
HTTP. Without this, a single insecure script on a secure page hands the
attacker control of the whole page over Wi-Fi.
🎧
Permissions Prompts
explicit user consent
Camera, microphone, geolocation, notifications, USB, MIDI, clipboard — all
require explicit per-origin user consent. Permissions are scoped, revocable,
and visible in the browser UI. The "ask first" model has prevented countless
surveillance attacks.
Section 15
OWASP Top 10 (2021) — The Industry Consensus on the Worst Risks
The Open Worldwide Application Security Project (OWASP)
publishes a list every few years of the ten most critical Web application
security risks. The 2021 edition is the current reference. Every Web defender
knows these by their codes (A01–A10) — they appear in compliance audits,
bug-bounty reports, and breach post-mortems worldwide.
Breaches detected months later because logs were missing
SolarWinds: attackers undetected for 9 months
A10
Server-Side Request Forgery (SSRF)
Server makes requests to attacker-chosen URLs
Capital One 2019 (SSRF → AWS IMDS → 100M records)
Section 16
The Big Three Web Vulnerabilities — XSS, SQLi, CSRF
If you understand only three Web attack patterns, make them these. Together
they account for the vast majority of historical Web breaches, and they share
one root cause: untrusted input being treated as trusted code.
</>
XSS — Cross-Site Scripting
What: Attacker injects JavaScript that runs in another user's
browser, in the victim site's origin. The script can steal cookies, perform
actions as the user, deface the page, or keylog.
Example payload:<script>steal(document.cookie)</script>
Types: Stored (saved in DB), Reflected (in URL), DOM-based (client-side).
Mitigation: Output-encode all user data; deploy a strict
Content-Security-Policy; never use innerHTML with untrusted input.
the most common Web bug
📋
SQLi — SQL Injection
What: Malicious input alters the SQL query the server
executes. Can extract the entire database, modify records, or in some cases
execute OS commands.
Example payload:' OR '1'='1' -- turns
WHERE user='alice' AND pwd='X' into a query that always returns true.
Real case: TalkTalk UK 2015 — teenage attackers extracted 157,000
customer records via SQLi. The CEO admitted on BBC the company "could have done more."
Mitigation: Parameterised queries (prepared statements). Never
concatenate user input into SQL strings. Use ORMs that parameterise by default.
avoidable yet still devastating
🎯
CSRF — Cross-Site Request Forgery
What: Attacker tricks a logged-in user's browser into
making an unwanted state-changing request to a target site. The user's
cookies travel with the request automatically.
Example payload:<img src='https://bank.com/transfer?to=evil&amount=1000'>
embedded in any page the victim visits while logged into the bank.
Mitigation: SameSite=Lax (or Strict) cookies; CSRF tokens
on every state-changing form; check the Origin header on
sensitive endpoints.
defeated by SameSite, but legacy apps stay vulnerable
🛡️
British Airways Magecart, September 2018
Attackers compromised a third-party JavaScript file loaded on the
British Airways payment page and inserted skimming code
that exfiltrated card details of ~380,000 transactions to
attacker-controlled servers. This is XSS via the supply chain — the same
vulnerability pattern, just delivered through a trusted CDN script rather
than a direct injection. The UK ICO initially fined BA £183 million (later
reduced to £20M). The defence: Subresource Integrity (SRI)
hashes on external scripts plus strict CSP.
Section 17
Security Headers & Modern Defences — Defence-in-Depth, One Header at a Time
Six HTTP response headers, when set correctly, can deflect most common
client-side attacks before they reach your application logic. They cost
nothing, they break nothing when configured properly, and most Web services
still don't deploy them.
🔐
HSTS
Strict-Transport-Security
Forces HTTPS for all subsequent requests to your domain, even if the user
types http://. Prevents protocol-downgrade attacks (SSL-strip).
Example:max-age=31536000; includeSubDomains; preload
The preload directive submits your domain to a browser-shipped list — HSTS even on first visit.
🛡️
CSP
Content-Security-Policy
Whitelist of allowed sources for scripts, styles, frames, images, fonts.
The single strongest defence against XSS.
Example:default-src 'self'; script-src 'self' 'nonce-r4nd0m'
Modern CSP uses nonces or hashes to allow only specific inline scripts.
🚫
X-Frame-Options
clickjacking defence
Prevents your site from being embedded in an iframe on another origin —
blocking clickjacking, where an invisible iframe over a button hijacks the
click.
Example:DENY or SAMEORIGIN
CSP's frame-ancestors directive supersedes this for modern browsers.
🔢
SRI
Subresource Integrity
Validates a cryptographic hash on external scripts and stylesheets. If the
file is tampered with on the CDN, the browser refuses to load it. Would
have stopped the British Airways Magecart attack outright.
Controls how much of the referring URL is leaked to third-party sites in
the Referer header.
Recommended:strict-origin-when-cross-origin — send only the origin (no path or query) to other sites.
🎧
Permissions-Policy
restrict powerful features
Restricts which browser features (camera, microphone, geolocation, payment,
USB) the page can use — and which third-party iframes can use them either.
Example:geolocation=(), camera=(), microphone=() — disable all three completely.
Section 18
Web Application Firewalls (WAF) — Inspecting HTTP at the Edge
A Web Application Firewall is an HTTP-aware filter that sits
in front of your application, inspecting every request and blocking known
attack patterns. Unlike a network firewall (which sees only IPs and ports),
a WAF understands SQL syntax, JavaScript injection patterns, and OWASP attack
signatures.
Cloud WAF — Cloudflare, AWS WAF, Akamai. Reverse-proxy
WAF — Nginx + ModSecurity in front of your servers. Out-of-band
— detection only, no blocking. WAF + RASP — runtime
application self-protection built into the app itself.
⚠️
WAF Limitations
not a silver bullet
Encrypted threats need TLS termination at the WAF. False positives block
legitimate users (a common operational pain). Zero-days slip through until
signatures are written. A WAF is not a substitute for secure code
— it is one more layer in defence-in-depth.
Section 19
API Security — The New Frontline
Modern apps are mostly APIs underneath. The browser fetches data via fetch/AJAX;
mobile apps speak directly to JSON endpoints; microservices call each other
over gRPC. As of 2024, the OWASP API Security Top 10 exists
separately from the regular OWASP Top 10 — because the threat model is genuinely
different.
The default for most public APIs (Stripe, Twilio, GitHub)
GraphQL
Single endpoint, client-defined queries, schema-driven
Facebook, GitHub, Shopify — clients fetch exactly what they need
gRPC
Binary over HTTP/2, Protocol Buffers, strongly typed
Internal microservices at Google, Netflix, Square
WebSocket
Persistent bidirectional channel over a single TCP connection
Real-time chat, live trading, gaming, collaborative editing
The Essential API Security Controls
🔑
Strong Authentication
prove who is calling
OAuth 2.0 + OIDC for user-facing APIs.
mTLS (mutual TLS) for service-to-service. Avoid long-lived
static API keys where possible — they leak in git repos and never get rotated.
🔒
Per-Object Authorisation
"can THIS user see THIS record?"
The most common API vulnerability is BOLA (Broken Object
Level Authorisation) — also called IDOR. The user is authenticated, but the
app fails to verify they own the record they are requesting. Every
/users/<id>-style endpoint needs a per-record check.
⏱️
Rate Limiting & Quotas
stop the firehose
Per-user, per-IP, per-token throttling. Stops credential stuffing, account
enumeration, and data scraping. Optus Australia 2022 leaked ~10
million customer records when an unauthenticated API had no rate limit.
✅
Input Validation
schema enforcement
Define your API in OpenAPI or JSON Schema; reject anything that does not
match. Mass-assignment attacks (sending extra fields the developer didn't
expect, like {"isAdmin": true}) die at the schema layer.
📊
Logging & Anomaly Detection
see the abuse
Log every authentication attempt, every authorisation decision, every
response code. Feed into SIEM. Watch for credential stuffing patterns,
sudden geographic shifts, and unusual API call volumes per user.
📣
API Gateway
centralised enforcement
One place to enforce authentication, throttling, observability, and
versioning for all your APIs. Kong, AWS API Gateway, Apigee, Tyk. Stops
teams from rolling their own auth in every microservice.
Section 20
Bot Management & DDoS Defence
More than half of all Web traffic is no longer human. Telling humans from bots —
and good bots (Googlebot, monitoring) from bad bots (credential stuffers,
scrapers, DDoS botnets) — has become a primary defensive activity.
Bot Traffic Share
~49.6%
Roughly half of all Web requests come from automation.
Malicious Share
~32%
Of bots, about one in three is actively malicious.
Largest 2024 DDoS
3.8 Tbps
Cloudflare-mitigated, October 2024 — at the time, a record.
Largest 2025 DDoS
31.4 Tbps
Aisuru botnet, December 2025 — eight times larger than 2024.
🤖 Bot Defences
Technique
What It Does
CAPTCHA / hCaptcha
Challenge suspected automation
Device fingerprinting
Detect headless browsers, emulators
Behavioural analytics
Mouse, keyboard, navigation patterns
Edge rate limiting
Per-IP and per-fingerprint throttling
Proof-of-Work challenges
Tiny CPU cost per request — invisible to humans, costly at scale
⚡ DDoS Defences
Technique
What It Does
Anycast scrubbing
Distribute load across global POPs
SYN cookies / TCP hardening
Defeat L3/L4 floods
WAF + rate-limit at L7
Block application-layer abuse
BGP RTBH / FlowSpec
Drop attack traffic upstream
Anycast DNS
Spread DNS load globally
Section 21
CDN & Edge Security — The Delivery Layer Doubles As the Defence Layer
A Content Delivery Network places servers (POPs, Points of
Presence) in hundreds of cities worldwide. The original purpose was speed —
static assets cached close to the user. The modern purpose is also defence:
the CDN is the first thing an attacker hits, and it never reaches your origin.
🌐 The Edge-First Architecture
🧹
WAF & Bot Management
L7 filtering at the edge
L7 inspection, JavaScript challenges, ML-based bot scoring — all at the
edge before traffic ever reaches your origin.
⚡
DDoS Mitigation
Tbps-scale absorption
Aggregate global capacity across major CDNs now exceeds 100 Tbps.
Cloudflare, Akamai, AWS Shield Advanced can absorb the largest known attacks.
🔐
TLS Termination
modern ciphers everywhere
The CDN handles TLS — modern ciphers, automatic certificate rotation via
Let's Encrypt or its own ACME service. Your origin needn't speak TLS itself
(though it should anyway).
📍
Smart Routing
optimal path, instant failover
Anycast steers users to the nearest healthy POP. If one POP fails, traffic
automatically reroutes to the next nearest. No DNS changes required.
⚙️
Edge Compute
code at the POP
Cloudflare Workers, AWS Lambda@Edge, Fastly Compute. Run authentication,
A/B testing, request rewriting, even full applications — at every POP, sub-millisecond
latency from users.
🔎
Observability
real-time intel
The CDN sees aggregate traffic patterns across millions of sites — anomaly
detection, attack-trend reports, threat intelligence feeds that no single
site could generate alone.
⚠️
The Concentration Trade-off
The edge is also a concentration point. The Fastly outage of 8 June 2021
took down the BBC, the New York Times, Reddit, GitHub, Amazon, Twitch, and the
UK government's gov.uk for roughly an hour worldwide — caused by a single
buggy customer configuration. The CrowdStrike-Microsoft outage of
19 July 2024 grounded airlines, hospitals, and banks across dozens of
countries. The CDN/edge model gives you world-class defence for free — and
hands the world's resilience to a handful of vendors.
Section 22
Web3 & the Decentralised Web — A New Architecture, A New Threat Model
🌿 The Promise of Web3
Applications That Run Without a Central Server
Web3 is shorthand for applications built on blockchain networks
rather than centralised servers. Ownership is encoded in cryptographic keys
held by the user. Transactions are executed by smart contracts
— code that lives on the chain itself and runs whenever the conditions are met.
The philosophical pitch is that no single company controls the user's data,
money, or identity. The engineering reality is that every Web2 security
flaw still exists, plus an entirely new family of blockchain-specific
attacks layered on top.
Key Components of a Web3 Application
Component
What It Does
Examples
Blockchain
Distributed transaction ledger; consensus across nodes
Ethereum, Solana, Polygon, Bitcoin
Smart Contract
Executable code stored on-chain; runs on every node
Written in Solidity (Ethereum) or Rust (Solana)
Wallet
Key-pair manager; signs transactions on behalf of the user
Decentralised Autonomous Organisation — token holders vote on decisions
MakerDAO, Uniswap DAO
The New Attack Surfaces
🧹
Smart-Contract Exploits
Re-entrancy, integer over/underflow, logic bugs — once deployed,
smart-contract code is largely immutable. A bug can cost hundreds of
millions. The DAO hack of 2016 drained $50M and forked Ethereum.
Audits and formal verification are essential.
no patches, no rollbacks
🔐
Wallet Drainers
Phishing dApps trick users into signing malicious transactions that move
all tokens to the attacker. There is no password reset on-chain — once
signed, the funds are gone. Wallet drainers have become professionalised
"drainer-as-a-service" kits.
social engineering at billion-dollar scale
🔗
Bridge Hacks
Cross-chain bridges hold pooled tokens — and have been the single largest
source of crypto theft. The Ronin bridge (March 2022) lost $625M
to North Korea's Lazarus Group. Wormhole (Feb 2022) lost $325M.
Bybit (Feb 2025) lost $1.5 billion — the largest crypto theft
ever recorded.
over $3B stolen across major bridge hacks
📣
Governance Attacks
Buying enough governance tokens to vote in a malicious proposal that drains
the DAO's treasury. Beanstalk DAO (April 2022) lost $182M in a
single block when an attacker flash-loaned voting power, passed a
"donation" proposal, and walked away.
decentralisation has its own attack class
👁️
On-Chain Privacy
Every transaction is public forever. Wallet addresses are pseudonymous,
not anonymous — chain analytics firms (Chainalysis, Elliptic) routinely
de-anonymise wallets by following transaction graphs. Privacy mixers
(Tornado Cash) have been sanctioned in the US since 2022.
forever-public ledgers
🤖
Prompt Injection (Web3 + AI)
A growing class of attacks where AI agents controlling on-chain assets are
tricked into executing harmful transactions via crafted natural-language
input. As autonomous AI agents proliferate in DeFi (2024+), this is the
new wallet-drainer.
AI agents = new attack surface
Section 23
Secure Web Development — A Pragmatic Best-Practices Checklist
Every engineering team building for the Web should be able to answer "yes" to
the six practices below. None of them require exotic tools or large budgets.
All of them prevent more breaches than any product you can buy.
✅ The Six Best Practices
01
Threat-Model Early. Before writing code, identify what you're protecting (data, money, reputation), who you're protecting it from (criminals, insiders, competitors), and how they might attack. Use STRIDE or LINDDUN as a framework. Threat models in a wiki, not a slide.
02
Validate Every Input. Use allow-lists, schema validation (JSON Schema, OpenAPI), and parameterised queries. Never trust client data — including your own mobile app, which an attacker can rewrite. Reject before you process.
03
Encrypt by Default. HTTPS everywhere with modern TLS (1.2+). mTLS between services. Encryption at rest for sensitive data (AES-256-GCM). Use AWS KMS, GCP KMS, or HashiCorp Vault — never hard-code keys in code or config.
04
Least Privilege. MFA on every user account. Scoped tokens for services (no service should have "admin" access). Just-in-time elevation for sysadmins (Privileged Access Management). Annual access reviews — most over-privileged accounts are forgotten, not malicious.
05
Patch & Pin Dependencies. Use SCA tools (Snyk, Dependabot, GitHub Advanced Security). Maintain an SBOM (Software Bill of Materials). Pin versions in lockfiles. The supply chain is part of your app — log4shell, XZ Utils, and event-stream all came in through it.
06
Log, Monitor, Alert. Structured logs (JSON, with trace IDs). Anomaly detection in your SIEM. SOC playbooks rehearsed quarterly. Assume breach and detect fast — the goal is no longer prevention alone but minimum dwell time.
Section 24
Key Takeaways — Six Ideas to Carry Home
🎯 The Distilled Lessons
01
Simple Origins, Vast Consequences. HTTP, HTML, and URLs —
three modest inventions by one engineer at CERN in 1989–1991 — now carry
the global economy. Understanding their original simplicity is the key
to understanding why their security has been hard to retrofit.
02
Every Layer Is an Attack Surface. URL parse, DNS, TCP,
TLS, HTTP, server, response, browser render — eight stages, eight attack
classes. Securing every hop matters; one weak link breaks the chain.
03
HTTPS Is Table Stakes. TLS 1.3 + HSTS + modern certificates
(free from Let's Encrypt) is the absolute minimum for any credible Web
service in 2025. Plain HTTP is malpractice.
04
OWASP Top 10 Still Wins. Injection, broken access control,
security misconfiguration — these same patterns drive the majority of
breaches year after year. Most attackers are not novel; they are
opportunistic. Fix the basics first.
05
Defence at the Edge. WAF, CDN, and bot management at the
edge stops attacks before they ever touch your application. Cloudflare's
mitigation of 31.4 Tbps in December 2025 shows what edge defence makes possible
— but the concentration risk (Fastly 2021, CrowdStrike 2024) is real and growing.
06
Security Is a Process, Not a Product. Threat-model,
code securely, monitor relentlessly. The Web rewards continuous vigilance.
Anyone who tells you a single tool fixes Web security is selling you
something — what actually works is discipline applied every day.
🎯
You Now See the Web the Way Defenders Do
Three primitives became a planetary nervous system. Three vulnerability
classes still drive most breaches. Three eras of evolution layered new
attack surfaces on top of old ones. And six daily practices separate the
teams who ship secure software from the ones whose breach you read about
next week. The Web is — and remains — a beautiful, terrifying, and ultimately
defensible thing.