BI-TWA.21 – Základy webových technologií

Okruh 1 · BI-WI.21-17

Obsluha a struktura HTTP požadavku a odpovědi ve webové aplikaci. Stav webové aplikace.

Principy fungování HTTP protokolu, struktura požadavku a odpovědi, přehled verzí, a způsoby udržování stavu v bezestavové webové aplikaci (URL, cookies, sessions).

🔗 URL, URI, URN – identifikace zdrojů

URL (Uniform Resource Locator) – identifikuje lokaci zdroje na webu. Je podmnožinou URI.
URI (Uniform Resource Identifier) – obecný identifikátor zdroje (může identifikovat i bez lokace).
URN (Uniform Resource Name) – trvalé jméno zdroje bez lokace (např. ISBN).

Formát URL dle RFC 1738:

scheme:[//authority]path[?query][#fragment]
scheme – protokol (https, http, ftp, …)
authority – doménové jméno nebo IP adresa (např. usermap.cvut.cz)
path – cesta ke zdroji (např. /search)
query – parametry dotazu za ? (např. query=Novák)
fragment – kotva v rámci stránky za # (např. profile)

Příklad: https://usermap.cvut.cz/search?query=Novák#profile

Proč rozlišujeme URL a URI?

Jeden uživatel Jan Novák může mít UUID jako trvalé URI (uuid:0d34f3bd-…), ale také URL profilu, URL fotky, URL QR kódu – různé lokace pro stejný zdroj. URI je nadřazený pojem, URL je konkrétní adresa.

🌍 DNS – Domain Name System

DNS – hierarchický distribuovaný systém, který překládá doménová jména na IP adresy a poskytuje další metadata.

Hierarchie: 13 logických kořenových (root) DNS serverů (A-M) → TLD servery (.cz, .com) → autoritativní servery domény
Správce TLD: ICANN (Internet Corporation for Assigned Names and Numbers), autorita TLD: IANA, autorita .cz: CZ.NIC
Efektivní cachování – změny se projeví až po vypršení TTL (Time To Live)

Průběh DNS dotazu (zjednodušeně):

Prohlížeč se zeptá lokálního DNS serveru na IP pro username.cvut.cz.
Lokální DNS nezná → ptá se kořenového serveru → získá adresu DNS pro .cz.
DNS pro .cz nezná plnou adresu → odkáže na DNS pro .cvut.cz.
DNS pro .cvut.cz zná a vrátí IP adresu.
Lokální DNS si odpověď uloží do cache a vrátí ji prohlížeči.

Důsledek cachování

Pokud se změní IP adresa serveru (DNS záznam), uživatelé s platnou cache budou stále směrováni na starou adresu. Změna se projeví až po vypršení TTL záznamu.

🔀 Forward Proxy vs. Reverse Proxy

Proxy – prostředník (meziserver) mezi klientem a serverem.

Typ	Kde stojí	Slouží komu	Typické využití
Forward Proxy	Na straně klienta (ve firmě, ISP)	Klientům	Nedostatek IP adres (NAT), monitorování provozu, bezpečnost, izolace sítě
Reverse Proxy	Na straně serveru (před farmou serverů)	Serverům	Zabezpečení, vyvažování zátěže (load balancing), cachování, stabilita

Proč je to důležité? V REST architektuře klient neví, s čím komunikuje – může to být load balancer, cache server nebo skutečný server. Toto je princip vrstvené architektury.

📡 HTTP – HyperText Transfer Protocol

HTTP – protokol aplikační vrstvy (nad TCP/IP), textový, bezestavový, funguje na principu požadavek → odpověď. Šifrovaná varianta je HTTPS (port 443).

Porty: HTTP → 80 (nebo 8080), HTTPS → 443 (nebo 8443)
Bezestavový = každý požadavek je nezávislý, server si nepamatuje předchozí komunikaci
Verze: 0.9, 1.0, 1.1, 2, 3

Verze	Klíčová vlastnost
HTTP/0.9	Pouze GET, žádné hlavičky, vrací přímo HTML
HTTP/1.0	Hlavičky, stavové kódy, Content-Type
HTTP/1.1	Povinná hlavička `Host`, Keep-Alive, chunked přenos, pokročilé cachování
HTTP/2	Binární, multiplexované (více požadavků přes 1 spojení), komprese hlaviček, server-push
HTTP/3	Funguje nad UDP (QUIC), zdokonaluje paralelní zpracování, jednodušší přechod mezi sítěmi

📤 Struktura HTTP požadavku (Request)

Request – zpráva odeslaná klientem serveru, popisuje požadovanou akci.

Formální gramatika:

Request ::= RequestLine (Header CRLF)* CRLF [body]
RequestLine ::= Method RequestUri HTTPVersion CRLF

Příklad požadavku:

GET /profile/140f269cb240 HTTP/1.1
Host: usermap.cvut.cz
Accept: text/html

Základní HTTP metody:

GET – získání dat (stavu), zobrazení stránky, vyhledávání. Idempotentní i safe.
POST – změna dat (vytváření, úprava, mazání). Není idempotentní ani safe.
PUT – náhrada/vytvoření zdroje. Idempotentní.
DELETE – smazání zdroje. Idempotentní.
PATCH – částečná úprava. Není idempotentní ani safe.
HEAD – jako GET, ale bez těla odpovědi (jen hlavičky).

Safe vs. Idempotentní

Safe (bezpečná) metoda nemění stav serveru – lze bezpečně cachovat. Idempotentní metoda má vždy stejný efekt i při opakování (nastav na 10 = stále 10, ale inkrementuj o 1 ≠ idempotentní).

📥 Struktura HTTP odpovědi (Response) a stavové kódy

Response – zpráva zaslaná serverem klientovi jako výsledek zpracování požadavku.

Formální gramatika:

Response ::= StatusLine (Header CRLF)* CRLF [body]
StatusLine ::= HTTPVersion Status CRLF

Příklad odpovědi:

HTTP/1.1 200 OK
Date: Sun, 5 Jul 2020 16:46:06 GMT
Content-Length: 39
Content-Type: text/html

<html><body>Ahoj svete!</body></html>

Skupiny stavových kódů:

Rozsah	Kategorie	Příklady
1xx	Informační – požadavek přijat, zpracování pokračuje	100 Continue
2xx	Úspěch	200 OK, 201 Created, 204 No Content
3xx	Přesměrování – nutná další akce	301 Moved Permanently, 302 Found, 304 Not Modified
4xx	Chyba klienta	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed
5xx	Chyba serveru	500 Internal Server Error, 503 Service Unavailable

401 vs 403 – častá záměna!

401 Unauthorized = uživatel není autentizován (nepřihlášen). 403 Forbidden = uživatel je přihlášen, ale nemá oprávnění (neautorizován).

📋 HTTP Hlavičky (Headers)

Hlavičky přenášejí metadata o požadavku nebo odpovědi.

Hlavička (Request)	Hlavička (Response)	Popis
`Host`	–	Doménové jméno cílového serveru (povinné v HTTP/1.1)
`Accept`	`Content-Type`	Typ obsahu (MIME type), např. `text/html`, `application/json`
`Accept-Language`	`Content-Language`	Jazyk obsahu
`Referer`	–	Předchozí adresa (pozn: překlep ve standardu!)
`Origin`	–	Předchozí doména (pro CORS)
`Cookie`	`Set-Cookie`	Přenos cookies
–	`Location`	Cílová URL při přesměrování
`Authorization`	`WWW-Authenticate`	Autentizační údaje

🔄 Stav webové aplikace – proč a jak

HTTP je bezestavový protokol – každý požadavek je izolovaný, server si nepamatuje předchozí komunikaci. Stav musí být reprezentován explicitně.

Tři základní mechanismy udržování stavu:

1. Stav v URL

Typicky pro vyhledávání a filtrování: /search?user=Svobo*&page=2
Výhoda: Stav je sdílitelný (záložka, odkaz v e-mailu)
Nevýhoda: Nehodí se pro důvěrné informace (hesla, tokeny)
Stav je řízen výhradně HTML hypertextovými odkazy <a href="...">

2. Cookies

Úložiště dat na straně klienta (v prohlížeči)
Server nastaví cookie přes hlavičku Set-Cookie, klient ji automaticky odesílá v každém dalším požadavku v hlavičce Cookie
Vhodné pro relativně malá data (klíč–hodnota)
Nelze se spolehnout na autenticitu – uživatel může cookie upravit nebo smazat

Parametry cookies:

Expires / Max-Age – životnost cookie (bez toho platí jen do zavření prohlížeče)
Secure – cookie se posílá pouze přes HTTPS
HttpOnly – cookie není přístupná přes JavaScript (ochrana před XSS)
SameSite – omezení cross-site zasílání (ochrana před CSRF)

HTTP/1.1 200 OK
Set-Cookie: CID=46872; Max-Age=3600; Secure; HttpOnly

3. Sessions (relace)

Data jsou uložena na serveru, klient dostane pouze unikátní identifikátor session (Session ID)
Data nejsou přístupná klientovi → nejsou volně modifikovatelná
Provázání klienta se session: přes cookie (preferováno) nebo query parametr v URL
Úložiště session: soubor, relační DB, key-value DB (Redis), paměť

Session přes URL – bezpečnostní riziko

Pokud je Session ID součástí URL (/index.php?PHPSESSID=8291747127241), může být sdíleno jako záložka nebo odkaz – příjemce pak převezme identitu odesílatele. Preferujte vždy cookie.

Cookie vs. Session – klíčový rozdíl

Cookie = data uložena u klienta, posílají se vždy. Session = data uložena na serveru, u klienta je jen ID. Session je bezpečnější (data nelze snadno podvrhnout), ale vytváří zátěž na serveru a vyžaduje sdílené úložiště při škálování.

📝 Shrnutí okruhu 1

HTTP je textový, bezestavový, request-response protokol nad TCP/IP. Verze 2 je binární a multiplexovaná, verze 3 funguje nad UDP.
Request má strukturu: Request Line (metoda, URL, verze) + hlavičky + tělo. Response: Status Line + hlavičky + tělo.
Stavové kódy 2xx = úspěch, 3xx = přesměrování, 4xx = chyba klienta (401 = nepřihlášen, 403 = neautorizován), 5xx = chyba serveru.
Stav aplikace se udržuje přes URL (sdílitelné, vhodné pro vyhledávání), cookies (data u klienta, může upravit) nebo sessions (data na serveru, bezpečnější).
Cookie parametry Secure, HttpOnly a SameSite jsou klíčové pro bezpečnost.

Kontrolní otázky pro státnice
Jaká je struktura HTTP požadavku a odpovědi? Request Line / Status Line + hlavičky (odděleny CRLF) + prázdný řádek + volitelné tělo.
Jaký je rozdíl mezi GET a POST? GET je idempotentní a safe (data v URL, pro získání dat), POST není safe ani idempotentní (data v těle, pro změny stavu).
Co znamená bezestavovost HTTP a jak ji obcházíme? Každý požadavek je izolovaný. Stav udržujeme přes URL parametry, cookies nebo sessions.
Jaký je rozdíl mezi cookies a sessions? Cookie = data u klienta, session = data na serveru (u klienta jen ID). Session je bezpečnější.
Co dělá HttpOnly a Secure atribut cookie? HttpOnly = JavaScript nemůže číst cookie (ochrana před XSS). Secure = cookie se přenáší jen přes HTTPS.
Jaké jsou rozdíly mezi verzemi HTTP? 1.1 přidal Keep-Alive a povinný Host. HTTP/2 je binární, multiplexovaný, komprimuje hlavičky. HTTP/3 funguje nad UDP (QUIC).

Okruh 2 · BI-WI.21-18

Základní postupy, technologie a standardy na straně serveru. Architektura webové aplikace a související návrhové vzory. REST.

Architektura klient-server, vícevrstvé architektury, MVC a příbuzné vzory, návrhové vzory GoF, webové služby (REST, SOAP, GraphQL), databázové vzory a hosting.

🏗️ Architektury webových aplikací

Architektura popisuje návrh celé aplikace z vysoké úrovně. Různé architektury reprezentují různou úroveň pohledu a vzájemně se nevylučují.

2-vrstvá architektura:

Thin-client / Smart-server – tradiční přístup; veškerá logika na serveru, klient jen zobrazuje HTML
Thick-client / Dumb-server – moderní přístup (SPA); server poskytuje jen API, logika je v prohlížeči

Vícevrstvá architektura (N-tier):

Separace odpovědností, abstrakce, snížení závislostí
Komunikace probíhá mezi sousedními vrstvami (nebo v rozvolněné variantě přes více vrstev)
3-vrstvá: Prezentační vrstva → Logická (business) vrstva → Datová vrstva

Monolitická architektura:

Celá aplikace je jeden nasaditelný celek
Jednoduché testování, ale špatně se škáluje (musí se škálovat jako celek) a je hůře udržovatelná

Microservices (mikroslužby):

Dekompozice na malé nezávislé služby – jedna funkcionalita = jedna služba
Výborná škálovatelnost, nezávislé nasazení každé služby
Složitější orchestrace a komunikace mezi službami

Enterprise Service Bus (ESB):

Centrální moderátor komunikace mezi službami
Zajišťuje: vyhledání služby, zasílání zpráv, kontrolu stavu, mediaci, zabezpečení

🧩 MVC, MVP a architektonické vzory

MVC (Model-View-Controller) – návrhový vzor oddělující logiku aplikace, data a prezentaci.

Model – business logika a data (přístup k databázi, pravidla, validace)
View – prezentační vrstva (HTML šablony, zobrazení dat)
Controller – řídí tok aplikace, přijímá požadavky, volá model, vybírá view

MVP (Model-View-Presenter):

Presenter přebírá veškerou logiku z View
View je pasivní – jen zobrazuje a předává uživatelské vstupy presenteru
Lepší testovatelnost (Presenter lze testovat bez UI)

Front Controller:

Řídí běh celé aplikace – vstupní bod každého HTTP požadavku (typicky index.php)
Provádí routing, autentizaci, autorizaci a předává řízení konkrétnímu controlleru

Template View:

Spravuje šablony s zástupnými symboly ({{ $name }})
Implementuje návrhový vzor Interpreter
Příklady: Latte (Nette), Twig (Symfony), Blade (Laravel)

📐 Návrhové vzory GoF (Gang of Four)

Návrhový vzor – obecné, standardizované, opakovaně použitelné řešení typického problému při návrhu softwaru. Musí mít jméno, řešit problém za určitých podmínek a být srozumitelně vysvětlitelný.

Creational (Kreační) – řeší vytváření objektů:

Singleton – existuje jediná instance (konfigurace, DB spojení). Označován za anti-pattern (globální stav, ztěžuje testování).
Factory / Factory Method / Abstract Factory – správný výběr třídy pro vytvoření objektu bez přímé závislosti na konkrétní třídě
Builder – usnadňuje sestavování komplikovaných objektů (e.g. SQL dotaz, HTTP požadavek)
Prototype – vytváří kopie existujících objektů (metoda clone())

Structural (Strukturální) – uspořádání tříd a komponent:

Proxy – druhotný přístup k objektu (lazy-loading, cachování)
Adapter – interoperabilita rozhraní (dvě různé knihovny pro zpracování obrázků)
Facade – zastiňuje detaily implementace, sdružuje celý package do jedné přístupné třídy
Decorator – obohacuje základní třídy, obaluje původní objekty (podobný proxy, ale jiný účel)
Composite – stromová struktura vztahu část-celek (adresáře, menu)
Bridge – odděluje abstrakci od implementace (modulární struktura)
Flyweight – sdílení instancí se stejnými vlastnostmi (šetří paměť; 100× stejné tlačítko s jiným textem)

Behavioral (Behaviorální) – chování a interakce objektů:

Observer – „nevolejte nás, zavoláme vás"; pozorovatelé se registrují k observable a jsou notifikováni při změně stavu
Command – zapouzdřuje akci jako objekt (lze volat hned, later, nebo odvolat)
Strategy – zaměnitelné algoritmy (výpočet ceny pro různé zákazníky)
State – chování objektu závisí na jeho vnitřním stavu (definování HTTP hlaviček před a po vykreslení)
Chain of Responsibility – posílání požadavku přes řetěz objektů (autentizace → autorizace → cache → zpracování)
Template Method – definuje obecný postup, konkrétní kroky implementují potomci
Visitor – přidává novou funkcionalitu do hierarchie tříd bez úpravy původních tříd
Mediator – organizuje interakci mezi objekty (controller, presenter)
Interpreter – reprezentace virtuálního jazyka (BBcode, Markdown)
Iterator – procházení kolekcí bez znalosti její struktury

Vzory pro IoC (Inversion of Control):

Dependency Injection – závislosti jsou předány zvenčí (přes konstruktor, setter nebo rozhraní), ne vytvářeny uvnitř
Service Locator – globální služba, která zná a vrací všechny ostatní služby

🌐 REST – Representational State Transfer

REST – softwarová architektura pro distribuované hypermediální systémy, definovaná R. Fieldingem v dizertační práci. Popisuje principy fungování webu (HTTP/1.0 → HTTP/1.1).

6 REST omezení (constraints):

Klient–server – separace zodpovědností; klient a server se vyvíjejí nezávisle
Bezestavovost – každý požadavek obsahuje všechny potřebné informace; server neuchovává stav klienta
Cachovatelnost – odpovědi musí být označeny jako cacheable/non-cacheable
Vrstvená architektura – klient neví, zda komunikuje přímo se serverem nebo s proxy; snadná rozšiřitelnost
Uniformní rozhraní – klíčový princip: identifikace zdrojů (resources), manipulace přes reprezentaci, samopopisné zprávy, HATEOAS
Code on Demand (volitelné) – server může posílat klientovi spustitelný kód (JavaScript)

Klíčové elementy REST:

Element	Popis	Příklad
Zdroj (Resource)	Konceptuální entita nebo skupina entit	Uživatel, článek, kolekce knih
Resource Identifier	Jedinečná identifikace zdroje	URL, URN
Reprezentace	Forma, ve které je zdroj přenášen	JSON, XML, HTML, JPEG
Metadata reprezentace	Informace o reprezentaci	Media type, čas poslední úpravy

Identifikace zdrojů – pravidla URL:

Výstižný, unikátní název
Hierarchická struktura: /books/{id}/authors
Singulár (/book/{id}) nebo plurál (/books/{id}) – zvolte jedno a dodržujte konzistentně
URL pouze identifikuje zdroj, HTTP metoda popisuje akci

REST rozhraní – metody na kolekcích a instancích:

Metoda	Kolekce `/books`	Instance `/books/{id}`
GET	200 OK – seznam knih	200 OK – detail knihy, 404 Not Found
POST	201 Created – vytvoří novou knihu	405 Method Not Allowed
PUT	405 nebo nahradí celou kolekci	200 OK / 201 Created / 204 No Content – nahradí nebo vytvoří
DELETE	405 nebo smaže celou kolekci	200 OK / 204 No Content – smaže
PATCH	Není standardizováno	200 OK / 204 No Content – částečná úprava

Cachování v REST:

Cache-Control: no-store – bez cachování
Cache-Control: max-age=3600 – platnost 1 hodinu
Cache-Control: private – jen v prohlížeči (ne proxy)
ETag + If-None-Match – validace pomocí hash obsahu (304 Not Modified = použij cache)
Last-Modified + If-Modified-Since – validace časovým razítkem

HATEOAS – Hypermedia as the Engine of Application State

Odpověď REST API by měla obsahovat hypertextové odkazy na další možné akce. Klient tak nepotřebuje dopředu znát strukturu API – naviguje ji dynamicky. Příklad: odpověď na GET /books/42 obsahuje linky na /books/42/authors a DELETE /books/42.

🔌 Webové služby – REST, SOAP, GraphQL, RPC

Webová služba – standardizované API umožňující komunikaci dvou nebo více aplikací přes síť.

Standard	Princip	Výhody / Nevýhody
RPC	Vzdálené volání procedur (XML-RPC, gRPC)	Jednoduchý model, gRPC je binární a vhodný pro microservices
SOAP + WSDL	Komplexní model webové služby v XML; WSDL popisuje rozhraní	Silně typovaný, enterprise-ready; ale verbózní a složitý
REST	CRUD operace nad zdroji přes HTTP; JSON/XML	Jednoduché, cachovatelné; ale méně expressivní pro komplexní dotazy
GraphQL	Dotazovací jazyk; klient specifikuje přesně jaká data chce	Flexibilní pro klienty; ale složité cachování a verzování

GraphQL specifika:

Architektura i dotazovací jazyk v jednom; silně typované schéma
Query – získávání dat
Mutation – modifikace dat
Subscription – real-time notifikace (WebSocket)
Problémy: obtížné cachování (jeden endpoint /graphql), složité verzování, vlastní formát dotazů

🗄️ Databázové návrhové vzory a persistence dat

Typy úložišť:

Memory storage – rychlé, ale po restartu ztraceno. Vhodné pro cache, krátkodobou session (Redis, SQLite in-memory).
Souborový systém – problém s konkurenčním přístupem (zamykání), pomalý zápis. Vhodné pro session, statická data (DokuWiki).
Relační DB – ACID transakce, správa zámků, distribuovatelné. (MySQL, PostgreSQL, MSSQL)
Nerelační (NoSQL) DB – klíč-hodnota, dokumentová, grafová. (Redis, MongoDB, Neo4J)

Vzory přístupu k databázi:

Vzor	Princip	Příklad
Active Record	Objekt = řádek v DB; objekt obsahuje i metody pro práci s DB (load, save, delete)	`$article = Article::load(42); $article->save();`
Data Mapper	Oddělená business data a logika ukládání; Mapper (Repository) řeší persistenci; lze snadno vyměnit za jiný druh úložiště	`$article = $mapper->load(42); $mapper->save($article);`
Unit of Work	Fronta změn; změny se provedou najednou v jedné transakci při `flush()`	`$manager->persist($a); $manager->remove($b); $manager->flush();`

📝 Shrnutí okruhu 2

REST je architektura (ne protokol ani standard) definovaná 6 omezeními: klient-server, bezestavovost, cachovatelnost, vrstvená architektura, uniformní rozhraní, code on demand.
V REST URL identifikuje zdroj, HTTP metoda popisuje akci. GET/HEAD jsou safe a idempotentní, PUT/DELETE jsou idempotentní, POST/PATCH nejsou.
MVC odděluje Model (logiku), View (zobrazení) a Controller (tok). Front Controller je vstupní bod každého požadavku.
GoF vzory: Creational (Singleton, Factory, Builder), Structural (Proxy, Facade, Decorator), Behavioral (Observer, Strategy, Command, Chain of Responsibility).
Active Record = logika v objektu, Data Mapper = oddělená logika ukládání, Unit of Work = dávkové provádění změn.

Kontrolní otázky pro státnice
Co je REST a jaká jsou jeho omezení? Architektura s 6 principy: klient-server, bezestavovost, cachovatelnost, vrstvená architektura, uniformní rozhraní, code on demand.
Jak se liší PUT a PATCH? PUT nahrazuje celý zdroj (idempotentní), PATCH mění pouze část (není idempotentní).
Jaký je rozdíl mezi Active Record a Data Mapper? Active Record má logiku DB v objektu, Data Mapper ji odděluje do Mapperu – snazší testování a výměna úložiště.
Co je HATEOAS? Princip, kdy API odpovědi obsahují hypertextové linky na další akce – klient nepotřebuje hardcoded znalost API struktury.
Jaký je rozdíl mezi monolitickou architekturou a microservices? Monolit = jeden celek (jednoduché testování, těžké škálování). Microservices = malé nezávislé služby (výborná škálovatelnost, složitá orchestrace).
K čemu slouží Observer pattern? Umožňuje loose coupling – observable notifikuje zaregistrované pozorovatele při změně stavu, aniž by o nich věděl dopředu.

Okruh 3 · BI-WI.21-19

Bezpečnost webových aplikací. Rizika a jejich opatření. Autentizace a autorizace uživatele.

OWASP Top 10, konkrétní typy útoků (SQL Injection, XSS, CSRF, Session Stealing), metody autentizace a druhy autorizace s jejich implementací.

🛡️ Základní pojmy bezpečnosti webových aplikací

Bezpečnost webové aplikace zahrnuje: znát hrozby, zabezpečit všechny kanály (síť, hostitel, aplikace), detekovat hrozby (logovat, zpracovat) a vyvíjet bezpečně od začátku.

Pojem	Definice
Zdroj	Chráněná informace nebo funkcionalita v aplikaci
Hrozba	Potenciální negativní efekt (ztráta dat, nedostupnost, …)
Zranitelnost	Chyba v aplikaci, která je předpokladem pro realizaci hrozby
Útok	Akce využívající zranitelnost k poškození zdrojů
Opatření	Ochrana implementovaná proti konkrétní hrozbě

📋 OWASP Top 10 – přehled verzí

OWASP (Open Web Application Security Project) – nezisková organizace vydávající seznam nejkritičtějších bezpečnostních rizik webových aplikací.

#	OWASP 2010	OWASP 2017
1	Injection	Injection
2	XSS	Broken Authentication
3	Broken Auth & Session Mgmt	Sensitive Data Exposure
4	Insecure Direct Object References	XML External Entities (XXE)
5	CSRF	Broken Access Control
6	Security Misconfiguration	Security Misconfiguration
7	Insecure Cryptographic Storage	XSS
8	Failure to Restrict URL Access	Insecure Deserialization
9	Insufficient Transport Layer Protection	Using Components with Known Vulnerabilities
10	Unvalidated Redirects and Forwards	Insufficient Logging & Monitoring

Injection je stále na prvním místě. XSS kleslo ze 2. na 7. místo v 2017 (lepší frameworky). CSRF zcela vypadlo z top 10 v 2021 (SameSite cookie to výrazně zmírňuje).

💉 SQL Injection – princip, příklad, ochrana

SQL Injection – útočník vloží SQL kód do vstupu, který je nekontrolovaně vložen do SQL dotazu, a tím změní jeho chování.

Nebezpečný kód:

$query = "SELECT * FROM course WHERE abbrev = '$_GET[abbrev]';";

Pokud útočník zadá jako hodnotu ' OR 1=1 OR abbrev = ', vznikne:

SELECT * FROM course WHERE abbrev = '' OR 1=1 OR abbrev = '';

Výsledek: vrátí se všechny záznamy. Útočník může získat citlivá data, poznat architekturu nebo data zničit.

Ochrana:

Validace vstupu – ověřit datové typy a formáty
Escapování – relativně náchylné na chybu, vždy využívat frameworky (ne vlastní implementaci)
Prepared Statements (parametrizované dotazy) – nejlepší ochrana; dotaz se odešle na SQL engine ODDĚLENĚ od dat, engine sám rozliší kód a data

$stmt = $pdo->prepare("SELECT * FROM course WHERE abbrev = ?");
$stmt->execute([$_GET['abbrev']]);

⚡ Remote Code Execution

Remote Code Execution (RCE) – spuštění útočníkova kódu v kontextu naší aplikace. Problém dynamických jazyků (PHP, Python, …).

Zranitelný kód:

include_once("pages/" . $_GET['page'] . ".php");

Útočník zadá ../config/database → načte se konfigurační soubor. Nebo vzdálené URL.

Ochrana:

Nikdy nekompilovat/vykonávat vstup od uživatele
Používat whitelist povolených hodnot:

switch ($_GET['page']) {
    case 'homepage': case 'detail': case 'contacts':
        include_once("pages/$_GET[page].php"); break;
    default: include_once("pages/404.php"); break;
}

🔴 Cross-Site Scripting (XSS)

XSS – injekce JavaScriptu do webové stránky; útočníkův skript se spouští v bezpečnostním kontextu dané stránky s plnou důvěrou prohlížeče.

Typy XSS:

Dočasný (Reflected) XSS – škodlivý kód je součástí URL nebo cookie; ohrožuje jen konkrétního uživatele
Perzistentní (Stored) XSS – škodlivý kód je uložen v databázi (komentář, uživatelský profil); ohrožuje všechny uživatele

Příklad zranitelného kódu (PHP):

echo "<p>$comment</p>";

Pokud comment obsahuje <script>window.location='https://utocnik.cz'</script>, spustí se útočníkův kód.

Ochrana:

Escapování výstupu – nejdůležitější; různé kontexty vyžadují různé escapování (HTML, JS, CSS, URL)
Validace vstupu – odmítat nebezpečné znaky na vstupu
Content Security Policy (CSP) – HTTP hlavička omezující, odkud se smí načítat skripty
HttpOnly cookie – JavaScript nemůže číst session cookie, čímž zabrání session stealing přes XSS

🔀 Cross-Site Request Forgery (CSRF)

CSRF – útok, při kterém útočník přiměje prohlížeč přihlášeného uživatele odeslat nežádoucí požadavek na důvěřující web. Server důvěřuje přihlášenému uživateli, ale požadavek nepochází od něj.

Příklad: uživatel je přihlášen na bankovním webu. Útočník ho naláká na stránku s:

<img src="http://vase-banka.cz/posli.php?kam=MUJUCET&kolik=10000" />

Prohlížeč automaticky přiloží cookies (session ID) → banka považuje požadavek za legitimní.

Ochrana:

Anti-CSRF token (XSRF token) – server vygeneruje unikátní token uložený v session a ve skrytém poli formuláře; při POST se porovnají; útočník token nezná
Kontrola hlavičky Referer/Origin – ne 100% (dá se podvrhnout), ale pomáhá
SameSite cookie – moderne cookies se neposílají při cross-site požadavcích
Více-faktorové ověření – u důležitých akcí vyžadovat extra faktor
Důsledné dodržování HTTP metod – GET nikdy nesmí mít vedlejší efekty (ale nechrání samo o sobě)

🔑 Session Stealing

Session Stealing – útočník získá Session ID a tím převezme identitu přihlášeného uživatele.

Způsoby krádeže Session ID:

Session ID v URL (lze zkopírovat z odkazu)
Slabý generátor Session ID (inkrementální hodnoty → útočník zkusí sousední hodnoty)
Cookie Stealing – přes XSS útočník přečte cookie a pošle ji na svůj server
Cookie Cooking – útočník nastaví uživateli předem dané Session ID (session fixation)

Ochrana:

Dlouhé náhodné Session ID (kryptograficky bezpečný generátor)
Časté obnovení Session ID (zvláště po přihlášení)
Akceptovat pouze Session ID vygenerovaná serverem
Cookies s atributem HttpOnly a Secure
Šifrování transportní vrstvy (HTTPS)
Doplňkové ověření: IP adresa, User-Agent, Referer, nonce

⚠️ Další bezpečnostní hrozby

Replay Attack – opakování dříve zachycených validních požadavků; ochrana: nonce (číslo použitelné jen jednou), časová razítka
Denial-of-Service (DoS) – snaha znepřístupnit zdroj zahlcením požadavky nebo zneužitím nákladné operace; DDoS = distribuovaná verze. Prevence: firewall, rate limiting, CAPTCHA, CDN.
Hesla – zásady ukládání:
- Nikdy plain-text!
- Vždy silný hash (bcrypt, Argon2, scrypt) – ne MD5 nebo SHA1
- Vždy salt (náhodná hodnota přidaná před hashováním) – chrání před rainbow tables
- Předávání pouze přes HTTPS
- Změna hesla: vždy znovu ověřit identitu, ideálně dvoufaktorově

🔐 Autentizace – identifikace a ověření identity

Autentizace – proces identifikace uživatele a ověření jeho identity (kdo jsi?).

Faktory autentizace:

Něco víš (Something you know) – heslo, PIN, ověřovací otázka
Něco máš (Something you have) – telefon (SMS, authenticator app), hardware token (USB, smart card), certifikát
Někým jsi (Something you are) – otisk prstu, duhovka, DNA

Druhy autentizace ve webových aplikacích:

Metoda	Princip	Bezpečnost
HTTP Basic	Base64(user:pass) v Authorization hlavičce; posílá se při každém požadavku	Base64 není šifrování; bez HTTPS je snadno odposlechnutelné. V praxi vždy HTTPS.
HTTP Digest	MD5 hash hesla + nonce místo plaintextu	MD5 je slabé. Stále nutné HTTPS.
Přihlašovací formulář	Vlastní implementace; informace o přihlášení uložena v cookie (session ID)	Hesla solit a hashovat (bcrypt). Nutné HTTPS.
API klíč	Náhodný, neuhodnutelný token v hlavičce nebo parametru	Musí být přes HTTPS, odvolatelný. Vhodné pro aplikace.
OAuth 2.0	Delegace přístupu přes třetí stranu (Google, GitHub); access token + refresh token	Komplexní, ale bezpečný. Standard pro „Login přes Google".

Více-faktorové ověřování (MFA/2FA):

Kombinuje alespoň dva různé faktory
Vhodné vrstvit dle citlivosti operace: čtení (0 faktorů) → běžné operace (1 faktor) → důležité akce (2+ faktory)
Vždy hledat kompromis mezi bezpečností a uživatelskou přívětivostí

🔓 Autorizace – ověření oprávnění

Autorizace – proces ověření, zda má uživatel oprávnění provést danou akci nebo přistoupit k danému zdroji (co smíš dělat?).

Autentizace vs. Autorizace – klíčový rozdíl

Autentizace = proces identifikace (kdo jsi?). Autorizace = proces udělení oprávnění (co smíš?). Autentizace předchází autorizaci. Existuje i autorizace bez autentizace (geolokace, souhlas s podmínkami).

Typy autorizace:

Geolokace (IP adresa, GPS) – geografické omezení přístupu
Věk – ověření věku dotazníkem při vstupu
Souhlas – souhlas s licenčními podmínkami
Preference – výběr uživatelského profilu (domácnosti vs. firmy)
Autentizace – přihlášení jako základ autorizace

Implementační vzory autorizace:

Vzor	Princip	Vhodné pro
Role (RBAC)	Statické přiřazení práv rolím; `hasRole(ADMIN)`; plochá nebo hierarchická struktura rolí	Jednoduché aplikace s jasně danými rolemi
Voter	Rozhodování na základě vazby uživatel–entita; `canEdit(article, user)`	Oprávnění vázaná na konkrétní objekt (autor článku)
ACL (Access Control List)	Komplexní přiřazení; statické i dynamické; hierarchické nebo grafové; kombinace role + voter	Komplexní enterprise systémy s jemnou granularitou

Implementace přístupu – Chain of Responsibility: Požadavek prochází řetězem kontrol: geolokace → ověření věku → souhlas s podmínkami → autentizace → autorizace. Každý článek řetězu buď propustí nebo odmítne požadavek.

📝 Shrnutí okruhu 3

OWASP Top 10 je žebříček nejkritičtějších webových bezpečnostních rizik; Injection je historicky na 1. místě.
SQL Injection: uživatelský vstup nekontrolovaně vložen do SQL dotazu. Ochrana: prepared statements.
XSS: injekce JS do stránky. Ochrana: escapování výstupu, CSP, HttpOnly cookie.
CSRF: útočník přiměje prohlížeč odeslat požadavek jménem uživatele. Ochrana: Anti-CSRF token, SameSite cookie.
Autentizace = kdo jsi, autorizace = co smíš. Tři faktory: znalost, vlastnictví, biometrie. Implementace: Role (RBAC), Voter, ACL.

Kontrolní otázky pro státnice
Jak funguje SQL Injection a jak se bránit? Vstup od uživatele se vloží přímo do SQL dotazu. Ochrana: prepared statements (parametrizované dotazy), validace, escapování.
Co je XSS a jaké jsou jeho typy? Injekce JavaScriptu do stránky. Reflected (dočasný, v URL) vs. Stored (perzistentní, v DB).
Jak funguje Anti-CSRF token? Server vygeneruje náhodný token, uloží ho do session a do skrytého pole formuláře. Při POST oba porovná; útočník token nezná, nemůže ho zahrnout do podvrženého požadavku.
Jak bezpečně ukládat hesla? Vždy hashovat (bcrypt/Argon2) a solit. Nikdy plain-text. Přenášet jen přes HTTPS.
Jaký je rozdíl mezi rolí, voterem a ACL? Role = statické přiřazení. Voter = vazba na konkrétní entitu. ACL = komplexní, hierarchické, kombinované.
Proč HttpOnly cookie chrání před XSS? JavaScript nemůže přečíst HttpOnly cookie, takže i při úspěšném XSS útoku nemůže útočník ukrást session cookie.

Okruh 4 · BI-WI.21-20

Základní postupy, technologie a standardy na straně klienta. Asynchronní zpracování požadavků webovým prohlížečem (AJAX), jeho výhody a nevýhody.

HTML5, CSS3, JavaScript/ECMAScript, DOM a události, AJAX a způsoby komunikace, Single Page Application vs. MPA, moderní přístupy (PWA, WebSockets).

📄 HTML5 – sémantika a struktura dokumentu

HTML (HyperText Markup Language) – značkovací jazyk pro strukturování dokumentů na webu. HTML5 je živý standard (Living Standard) spravovaný WHATWG.

Základní struktura HTML dokumentu:

<!DOCTYPE html> – deklarace typu dokumentu
<html lang="cs"> – kořenový element s jazykem
<head> – metadata: charset, viewport, title, styly, skripty
<body> – obsah stránky

Dělení elementů:

Blokové – zabírají celý řádek; h1–h6, p, div, ul, ol, table, form, blockquote, pre, address, hr
Řádkové – součást textu; a, span, strong, em, img, input, label, button, abbr, code, kbd
Bezvýznamové (Generic containers) – div (blokový), span (řádkový); nenesou sémantiku, pouze strukturují

Sémantické elementy HTML5:

<main> – hlavní obsah dokumentu
<article> – celistvá část dokumentu (novinka, komentář)
<section> – tematická sekce (blok komentářů)
<header> – záhlaví stránky nebo sekce
<nav> – navigační oblast
<aside> – vedlejší informace (sidebar, poznámky autora)
<footer> – zápatí stránky nebo sekce

Proč sémantika? Prohlížeč, vyhledávače i čtečky obrazovky lépe rozumí obsahu → lepší SEO, accessibility, outline dokumentu.

Formuláře v HTML5 – nové atributy a typy:

Nové typy inputu: email, tel, url, date, time, number, range
Nové atributy: required, pattern, min/max, placeholder, autocomplete
Metoda GET: data v URL (jen ASCII, idempotentní). Metoda POST: data v těle (binární data, multipart/form-data).

🎨 CSS – Kaskádové styly a kaskáda

CSS (Cascading Style Sheets) – jazyk popisující vizuální prezentaci HTML dokumentu. HTML = struktura, CSS = vzhled.

Selektory a specificita:

* – univerzální (0,0,0,0)
E – element (0,0,0,1)
.class – třída, atribut, pseudo-třída (0,0,1,0)
#id – identifikátor (0,1,0,0)
style="" – inline styl (1,0,0,0)
!important – přepíše vše (použít jen výjimečně)

Kaskáda – pořadí priority:

Nalezni všechny deklarace vztahující se k elementu
Seřaď dle důležitosti: UA → uživatel → autor → autor !important → uživatel !important
Při rovnosti: seřaď dle specificity selektoru
Při rovnosti: pozdější deklarace vítězí

Box model:

content → padding → border → margin
box-sizing: content-box (default) – width/height = jen obsah; padding/border se přičítají navíc
box-sizing: border-box – width/height zahrnuje i padding a border; intuitivnější

Moderní CSS3 layout:

Flexbox (display: flex) – jednorozměrné rozvrhování (řádek nebo sloupec)
Grid (display: grid) – dvourozměrné rozvrhování (řádky i sloupce)
Media Queries – adaptivní/responzivní design pro různá zařízení

CSS metodiky (konvence pojmenování):

BEM (Block Element Modifier) – .btn, .btn__icon, .btn--primary
OOCSS (Object-Oriented CSS) – oddělit strukturu od skinu, kontejner od obsahu
SMACSS – base, modules, layout (.l-content), state (.is-opened), theme

⚙️ JavaScript, ECMAScript a DOM

ECMAScript – standardizovaný jazyk pro skriptování (ECMA-262). JavaScript je implementace ECMAScript pro prohlížeče. Dynamicky typovaný, funkcionální, prototypový jazyk.

Vlastnosti JavaScriptu:

Imperativní syntaxe podobná Javě/C
Dynamicky typovaný (run-time evaluation)
Funkcionální – vnořené funkce, closures, lambda (arrow functions)
Prototypová dědičnost
Run-time prostředí: DOM (v prohlížeči), Node.js (na serveru)

Načítání JS do HTML:

Klasicky v <head> – blokuje parsování HTML (starý přístup)
async – stáhne asynchronně, spustí hned po stáhnutí (i za parsování HTML)
defer – stáhne asynchronně, spustí až po naparsování celého dokumentu (doporučeno)

DOM (Document Object Model):

Model reprezentující HTML dokument jako stromovou strukturu
Nezávislý na platformě/jazyku; standardizovaný W3C
Verze: DOM Level 1 (1998), Level 2 – getElementById() (2000), Level 3 – XPath, keyboard events (2004)

DOM události a jejich tok:

Capture fáze – událost prochází od rootu dolů k cílovému elementu
Bubble fáze – událost probublává od cílového elementu zpět k rootu
Registrace: addEventListener('click', handler, false) (false = bubble, true = capture)
Vícenásobná registrace posluchačů je možná (na rozdíl od onclick = ...)

Kdy registrovat události:

DOMContentLoaded – HTML naparsován, deferred skripty spuštěny; vhodné pro registraci event listenerů
window.load – veškerý obsah (obrázky, videa) načten; vhodné pro dynamický obsah závislý na zdrojích

🔁 AJAX – Asynchronous JavaScript and XML

AJAX – není samostatná technologie, ale množina technologií umožňující asynchronní komunikaci se serverem bez nutnosti plného znovunačtení stránky. Klíčová technologie: XMLHttpRequest (dnes spíše Fetch API).

Technologie AJAX:

HTML + CSS – prezentace
DOM – manipulace se stránkou
XML nebo JSON – výměna dat
JavaScript + XMLHttpRequest/Fetch API – asynchronní komunikace a propojení

Jak AJAX funguje – princip:

Uživatel provede akci (klik, scrollování, …)
JavaScript zachytí událost a vytvoří HTTP požadavek (XHR nebo fetch)
Požadavek jde na server asynchronně – stránka zůstává použitelná
Server vrátí data (JSON, HTML fragment, XML)
JavaScript zpracuje odpověď a aktualizuje DOM (jen změněnou část)

Výhody AJAX
Zkrácení odezvy – načítá se jen změněná část, uživatel méně čeká
Méně přenášených dat – v jednom požadavku se posílá jen potřebné
Úspora zdrojů na serveru – server přepočítává jen změnu, ne celou stránku
Lepší UX – plynulé interakce bez blikání (výměna celé stránky)

Nevýhody AJAX
Komplikovanější práce s historií prohlížeče – nutno použít fragment URL nebo History API (pushState)
Problematičtější záložky – URL se nemění, stav nelze záložkovat bez extra implementace
Indexace JS obsahu může být omezená – část crawlerů JavaScript zpracuje omezeně nebo se zpožděním, takže obsah načtený až přes AJAX může mít horší SEO
Uživatel může mít JS zakázán – aplikace nemusí fungovat
Vyšší počet HTTP požadavků – každá interakce = nový požadavek
Složitější kód – asynchronní logika je komplexnější na psaní a debugování

Způsoby AJAX komunikace:

Short Polling – klient se pravidelně ptá serveru (např. každých 5 s); jednoduché, ale neefektivní
Long Polling – klient odešle požadavek, server drží připojení otevřené, dokud nemá nová data; po odpovědi klient hned pošle nový
Streaming / Chunked Response – server posílá data postupně v jednom dlouhém spojení
WebSockets – trvalé obousměrné spojení (viz níže)
Server-Sent Events (SSE) – jednosměrné (server → klient) real-time push notifikace

📱 Single Page Application (SPA) vs. Multi Page Application (MPA)

SPA – aplikace, kde se při navigaci nemění celá stránka, ale jen část DOM; větší část logiky běží na klientovi.

Aspekt	MPA (tradiční)	SPA
Navigace	Full-page reload	Jen aktualizace DOM
Rychlost po načtení	Pomalejší	Rychlejší odezva
Prvotní načtení	Rychlé	Pomalejší (celá aplikace najednou)
SEO	Dobré (crawleři vidí HTML)	Problematické (nutný SSR)
Historie prohlížeče	Nativní	Nutno řešit (History API)
Přístup k datům	Server vrací HTML	Přes API (REST, GraphQL)

SPA výhody:

Jen jedno prvotní načtení statických souborů
Rychlejší responsivita – přijdou jen data, ne celé HTML
Přívětivější UX (plynulé přechody)

SPA nevýhody:

JS-only – bez JS aplikace nefunguje (nutný SSR pro přístupnost a SEO)
Při špatné implementaci pomalejší než MPA
Typické problémy JS/AJAX: history, bezpečnostní skenování
Aktualizace aplikace za běhu – nutno přenačíst celou SPA

SPA frameworky: React, Angular, Vue.js, Ember, Backbone, Svelte

🔌 WebSockets a moderní přístupy

WebSocket – protokol umožňující trvalé obousměrné (full-duplex) spojení mezi klientem a serverem. Vhodný pro real-time aplikace.

Princip navázání spojení: HTTP-first → WebSocket protocol upgrade (101 Switching Protocols) → přepnutí na WS protokol

Hlavičky se posílají jen jednou (při upgrade)
Trvalé statefull spojení (na rozdíl od bezestavového HTTP)
Nutno implementovat vlastní aplikační protokol nad WS
Vyžaduje speciální server pro zpracování (např. Node.js, Ratchet)

Události WebSocket: open (spojení navázáno), message (přijata zpráva), close (ukončeno), error (chyba)

Vhodné použití: hry, chaty, burzovní aplikace, monitoring, streaming

Progressive Web Application (PWA):

Webová aplikace dodávaná přes web, tvářící se jako nativní aplikace
Lze nainstalovat na zařízení, nemusí se spouštět v prohlížeči (prohlížeč je schován na pozadí)
Technologie: Web App Manifest (název, ikona, start URL, display mode) + Service Workers
Service Workers – proxy mezi aplikací a sítí; nemají přístup k DOM; zajišťují: cachování (offline fungování), push notifikace, background sync
Podpora: Chromium (nejlepší), Safari (omezená), Firefox (minimální)

Web Storage API:

localStorage – persistentní, sdílí se mezi okny stejné aplikace, bez expirace
sessionStorage – omezený lifetime (jen aktuální okno/tab)
Cookies: max 4 kB, Web Storage: max 5–10 MB
IndexedDB – NoSQL databáze v prohlížeči; ukládání JSON, téměř neomezená velikost; vhodné pro offline cache

🚀 Rapid Application Development (RAD) a SPA frameworky

Cíl: pracovat s minimálním úsilím, věnovat čas logice, ne opakujícímu se kódu.

CSS frameworky:

Obecné – Bootstrap, Bulma, Foundation (hotové komponenty)
Utility-first – Tailwind, Materialize (kombinace utility tříd)
Classless – aplikuje styly přímo na HTML elementy bez tříd (HTML-first přístup)
Lightweight – Pure.css, Milligram, Skeleton (minimální footprint)

JS support knihovny (alternatívy k SPA):

Alpine.js – „Vue.js v HTML atributech"; reaktivita bez build step
Hotwire (Turbo + Stimulus) – Rails ekosystém; Turbo Drive nahrazuje full-reload za AJAX, Turbo Frames přenačítá jen bloky, Stimulus definuje komponenty v JS odděleně od HTML

Verzovací modely (Git workflows):

Git Flow – robustní, větve pro feature/release/hotfix; vhodné pro verzované software
GitHub Flow – jednodušší; main je vždy deployable; feature větve + pull request + code review
GitLab Flow – kombinace, environment větve
One Flow – lineární historie, žádná develop větev, základ je rebase

Sémantické verzování (SemVer):

Formát: MAJOR.MINOR.PATCH (např. 1.2.3)
MAJOR – zpětně nekompatibilní změny
MINOR – přidání funkce se zachováním kompatibility
PATCH – oprava chyby se zachováním kompatibility
Konvence rozsahů: ^1.2.3 = >=1.2.3 <2.0.0, ~1.2.3 = >=1.2.3 <1.3.0

📝 Shrnutí okruhu 4

HTML5 přidalo sémantické elementy (main, article, section, nav, header, footer, aside) a nové typy formulářových polí. Sémantika zlepšuje SEO a accessibility.
AJAX = množina technologií (XHR/Fetch + JSON/XML + DOM + JS) umožňující asynchronní komunikaci. Výhoda: rychlejší UX, méně přenášených dat. Nevýhoda: problémy s historií, SEO, JS nutný.
DOM = stromový model HTML dokumentu s API. Události mají capture a bubble fázi. Preferujeme addEventListener (vícenásobná registrace).
SPA = logika na klientovi, navigace bez reload. Výhody: rychlá odezva. Nevýhody: SEO problémy, nutný JS, složitá správa stavu.
WebSocket = trvalé obousměrné spojení (101 Switching Protocols), vhodné pro real-time. PWA = webová aplikace chovající se jako nativní (Service Workers + Manifest).

Kontrolní otázky pro státnice
Co je AJAX a jaké technologie zahrnuje? Množina tech.: HTML+CSS (prezentace), DOM (manipulace), XML/JSON (data), JavaScript + XMLHttpRequest/Fetch (komunikace). Umožňuje asynchronní požadavky bez reload.
Jaké jsou výhody a nevýhody AJAX? Výhody: rychlejší odezva, méně dat, úspora serveru. Nevýhody: problémy s historií, záložkami, crawlery, vyšší počet požadavků, nutný JS.
Co je DOM a jaký je tok událostí? Stromový model HTML dokumentu = API pro manipulaci. Události: capture fáze (shora dolů) → target → bubble fáze (zdola nahoru).
Jaký je rozdíl mezi localStorage a sessionStorage? localStorage = persistentní, sdílí se mezi okny. sessionStorage = platí jen pro aktuální tab, po zavření se smaže.
Jak se liší SPA od MPA? MPA = full-page reload při každé navigaci. SPA = jen aktualizace DOM, logika na klientovi, přístup k datům přes API.
Co je Service Worker a k čemu slouží? Proxy mezi aplikací a sítí; nemá přístup k DOM; zajišťuje offline cachování (fetch intercept), push notifikace a background sync pro PWA.
Jak fungují WebSockets? HTTP-first → 101 Switching Protocols upgrade → trvalé obousměrné TCP spojení. Hlavičky jen jednou. Vhodné pro chat, hry, monitoring.