Proč většina webů není bezpečná: Systémový problém, ne technologické selhání

Úvod: Bezpečnost selhává před prvním řádkem kódu Debata o bezpečnosti webů je dlouhodobě vedena špatně. Řeší se konkrétní zranitelnosti, aktualizace nebo nástroje. Tím se ale řeší až důsledky. Skutečný problém vzniká mnohem dříve --- ve chvíli, kdy se rozhoduje o tom, jaký systém bude vůbec postaven. Většina webů není nebezpečná proto, že by obsahovala chyby, ale proto, že jejich architektura chyby umožňuje zneužít. ## **1. Historický kontext: Proč dnešní weby vznikly špatně** Většina současných webů vznikla v době, kdy byl web statickou prezentací s minimem dat a omezenou interakcí. Architektura tomu odpovídala. Dnes však weby fungují jako komplexní aplikace (SaaS, e-commerce), které ukládají citlivá klientská data. Problém je, že jejich vnitřní struktura zůstala monolitická a závislá na CMS. Systém má odpovědnost aplikace, ale strukturu prezentace. ## **2. Monolit jako hlavní slabina** V monolitickém systému běží frontend, logika i data v jednom prostředí se stejnými oprávněními. Neexistují bezpečnostní hranice, které by izolovaly problém. Průnik do jedné části (např. přes nekvalitní plugin pro fotogalerii) znamená automaticky průnik do celku. Rozdíl mezi drobným incidentem a katastrofou v monolitické architektuře prakticky neexistuje. {width="6.267716535433071in" height="5.013888888888889in"} Shutterstock ## **3. Iluze bezpečnostních nástrojů** Firmy často věří, že firewall (WAF) nebo bezpečnostní pluginy zajistí ochranu. Tyto nástroje jsou však pouze reaktivní -- filtrují známé útoky a reagují na vzorce chování. Neřeší ale špatnou architekturu, přímý přístup k datům ani eskalaci oprávnění. Jakmile útok využije neznámou zranitelnost (Zero-day) nebo obejde filtr, bezpečnost postavená na nástrojích se hroutí. ## **4. Nekontrolovaná komplexita a ztráta přehledu** Moderní web je slepencem jádra CMS, desítek pluginů, frontendových frameworků a externích služeb. Problémem není samotný počet částí, ale fakt, že nejsou pod jednotnou kontrolou. Mají různý původ i životní cyklus. Vzniká systém, který nikdo plně nechápe a u kterého nikdo nedokáže předpovědět, co se při útoku rozbije. **Systém, který nelze plně pochopit, nelze považovat za bezpečný.** ## **5. Přímá vazba mezi webem a daty: Architektonický hřích** Dominantní, leč chybný model stále počítá s tím, že webová vrstva komunikuje přímo s databází a má k ní široká oprávnění. Tato cesta je volena proto, že je jednoduchá a levná na implementaci. Daň za tuto rychlost se však platí při incidentu: jakýkoliv průnik do aplikace dává útočníkovi klíče k celému datovému skladu včetně možnosti exportu nebo změny dat. ## **6. Supply Chain: Útok na dálku** Útočníci v roce 2026 necílí na konkrétní weby, ale na jejich závislosti. Kompromitací jedné knihovny na CDN nebo jednoho marketingového skriptu mohou ovlivnit miliony webů najednou. Pokud web spouští cizí kód bez striktní kontroly integrity a bezpečnostních politik (CSP), stává se pouhým prostředníkem pro distribuci malwaru. ## **7. Nekompromisní principy bezpečné architektury (Standard 2026)** Aby byl web v roce 2026 považován za bezpečný, musí splňovat tyto minimální standardy: ### **7.1 Fyzické oddělení vrstev** Frontend nesmí mít technickou možnost komunikovat přímo s databází. Veškerý provoz musí jít přes izolovanou vrstvu API, která funguje jako filtr. Databáze samotná musí být umístěna v privátní síti, nedostupná z veřejného internetu. ### **7.2 Zero Trust a validace každého kroku** Žádná část systému nesmí být implicitně důvěryhodná jen proto, že je „vnitřní". Každý požadavek mezi komponentami musí být autentizován a každá operace validována. Oprávnění musí být nastavena na absolutní minimum (Least Privilege). ### **7.3 Digitální hygiena dodavatelského řetězce** - **Content Security Policy (CSP):** Striktní vymezení, odkud se smí > načítat skripty. - **Subresource Integrity (SRI):** Ověřování otisku každého externího > souboru. - **Audit závislostí:** Kontinuální monitoring zranitelností ve všech > použitých komponentách. ### **7.4 Systémová auditovatelnost** Bezpečnost vyžaduje disciplínu v logování. Nejde jen o to vědět, *že* se někdo přihlásil, ale mít možnost zpětně analyzovat každou změnu v datech a každou neobvyklou exfiltraci. Bez možnosti zpětné analýzy nelze z incidentu vyvodit poučení ani zastavit jeho šíření. ## **Závěr: Bezpečnost nelze přidat, lze ji jen navrhnout** Problém většiny současných webů není v tom, že by byly špatně zabezpečené. Problém je hlubší: **nejsou navrženy tak, aby bezpečné být mohly.** Dokud budeme na weby pohlížet jako na marketingové skládačky z náhodných pluginů, budeme se točit v kruhu reaktivních oprav. Skutečná změna vyžaduje odvahu k architektonické disciplíně. Bezpečnost není produkt, který si koupíte; je to výsledek rozhodnutí, která učiníte ještě předtím, než napíšete první řádek kódu.