Jedna doména, šest různých pravd: co vidí DNS, TLS, prohlížeč, Googlebot, sociální crawler a bezpečnostní skener

https://example.com/artykul

a dostanete šest různých odpovědí:

• DNS tvrdí, že doména vede na dvě IP adresy,
• vrstva TLS vidí certifikát, který nezahrnuje www,
• váš prohlížeč zobrazuje správnou, personalizovanou stránku,
• Googlebot indexuje starší titulek,
• LinkedIn stále zobrazuje předchozí obrázek,
• bezpečnostní skener uděluje slabé hodnocení kvůli chybějícím hlavičkám.

Žádné z těchto pozorování nemusí být nepravdivé.

Každý systém se dívá na jinou část stacku, používá jinou cache, posílá jinou sadu hlaviček, může se připojovat z jiné lokality a ne vždy vykonává JavaScript stejným způsobem. „Pravda webové stránky“ není jeden dokument. Je to soubor stavů viditelných pro různé klienty.

Nejdůležitější závěr: doména může fungovat správně v prohlížeči vlastníka a zároveň mít chybné DNS pro část resolverů, nesprávný certifikát na jednom uzlu CDN, neindexovatelný obsah pro Googlebota, starý náhled na sociálních sítích a slabé zabezpečení HTTP odpovědí.

Tento článek nepředpokládá, že každý rozdíl je chyba. Personalizace, jazykové varianty, cache a distribuovaná infrastruktura jsou běžné. Problém začíná tehdy, když je rozdíl nezamýšlený, neviditelný v monitoringu nebo znemožňuje konkrétnímu klientovi dostat se ke správné verzi.

Dokumentace a chování popsaných systémů byly ověřeny 23. července 2026.

Šest perspektiv v jedné tabulce

Pozorovatel	Co skutečně kontroluje	Co obvykle nezná	Co může změnit výsledek
DNS	název hostitele, záznamy, delegaci, cache, DNSSEC	obsah HTML, cestu URL, titulek stránky	resolver, TTL, region, IPv4/IPv6
TLS	endpoint, SNI, certifikát, SAN, chain, protokol	obsah stránky a její SEO	IP adresu, uzel CDN, konfiguraci virtual host
Prohlížeč	DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, cache, DOM	záměr autora a stav ostatních klientů	uživatel, viewport, locale, storage, service worker
Googlebot	dostupnost, robots, HTTP, HTML, zdroje, renderování, canonical, noindex	obsah vyžadující přihlášení nebo interakci	mobile-first, crawl cache, render queue, blokování zdrojů
Crawler sociálních sítí	URL, redirect, metadata, náhledový obrázek, cache platformy	plný zážitek z aplikace	platforma, cache, Open Graph, dostupnost obrázku
Bezpečnostní skener	veřejný povrch a testy ve svém rozsahu	celou byznysovou logiku, kód a role uživatelů	typ skeneru, autorizaci, cestu, konfiguraci testu

„Stejná doména“ neznamená vždy stejný test

Než porovnáte výsledky, přesně určete zkoumaný zdroj:

http://example.com
https://example.com
https://www.example.com
https://example.com/
https://example.com/artykul
https://example.com/artykul?utm_source=test

Nejsou to technicky totožné požadavky. Mohou:

• vést přes jiná přesměrování,
• používat jiné hostitele,
• dorazit na jiný virtual host,
• mít jiná pravidla cache,
• ukazovat na různé canonicaly,
• vracet jiné hlavičky,
• vyvolávat samostatné karty na sociálních sítích.

Audit by měl vždy zaznamenat úplnou URL, čas, lokalitu testu, user-agent, koncový status a řetězec přesměrování.

Pravda číslo 1: DNS vidí název, ne stránku

DNS překládá název hostitele na data potřebná k nalezení služby. V typickém dotazu pro:

https://example.com/artykul?id=42

DNS zajímá název:

example.com

Neanalyzuje cestu /artykul, parametry ?id=42, titulek HTML ani značku canonical. DNS je hierarchický systém názvů a záznamů o zdrojích.

Co může vidět diagnostika DNS?

Mimo jiné:

example.com.      IN A      192.0.2.10
example.com.      IN AAAA   2001:db8::10
www.example.com.  IN CNAME  edge.example.net.
example.com.      IN CAA    0 issue "letsencrypt.org"

Může také zkontrolovat:

• servery NS,
• záznam SOA,
• poštu MX,
• data TXT,
• záznamy HTTPS a SVCB,
• podpisy DNSSEC.

Proč mohou dva lidé dostat různé odpovědi?

Nejjednodušší příčinou je cache. Resolver může uchovávat odpověď až do vypršení TTL. Negativní odpovědi, jako NXDOMAIN, mohou být také ukládány do cache.

Rozdíly mohou vyplývat také z:

• různých resolverů,
• odlišných verzí cache,
• geografické infrastruktury nebo load balancingu DNS,
• samostatných odpovědí pro IPv4 a IPv6,
• migrace mezi operátory,
• nekonzistentních autoritativních serverů,
• poškozeného řetězce DNSSEC.

DNSSEC ověřuje původ a integritu dat DNS, ale nešifruje samotný dotaz. Chybný záznam DS může způsobit, že validující resolver vrátí SERVFAIL, zatímco resolver bez validace stále zobrazí adresu.

Co DNS nepotvrzuje?

Správná odpověď DNS nedokazuje, že:

• server funguje,
• port 443 je otevřený,
• certifikát je správný,
• aplikace vrací kód 200,
• stránka je indexovatelná,
• bezpečnostní hlavičky jsou nasazeny.

DNS říká, kam se má klient pokusit připojit. Neříká, co po připojení najde.

Pravda číslo 2: TLS vidí identitu endpointu, ne obsah článku

Po nalezení adresy klient vytvoří spojení se serverem a vyjedná TLS. V prostředí, které obsluhuje více domén na jedné adrese, umožňuje rozšíření SNI klientovi uvést název serveru, pro který chce spojení navázat.

Vrstva TLS může mimo jiné odhalit:

• podporované verze protokolu,
• vyjednaný algoritmus,
• certifikát serveru,
• názvy SAN,
• certifikační autoritu,
• datum platnosti,
• zprostředkující certifikáty,
• výsledek vyjednávání ALPN, například HTTP/2.

TLS 1.3 je definován v RFC 8446 a chrání přenos dat mezi klientem a serverem.

Certifikát odpovídá názvu, ne obsahu

Klient kontroluje, zda název hostitele odpovídá identitě zapsané v certifikátu, především v subjectAltName.

Certifikát pro:

example.com

nemusí zahrnovat:

www.example.com
api.example.com

Wildcard:

*.example.com

automaticky nezahrnuje kořenovou doménu example.com ani víceúrovňový www.eu.example.com.

Proč jeden uživatel vidí správný certifikát a jiný ne?

Možné scénáře:

• A a AAAA vedou na různé servery,
• jeden uzel CDN neobdržel nový certifikát,
• konfigurace SNI má chybný výchozí virtual host,
• provoz z určitého regionu míří na jinou infrastrukturu,
• origin má jiný certifikát než veřejný edge,
• část serverů posílá neúplný chain.

Z pohledu uživatele je to stále „stejná doména“, ale z pohledu sítě to není stejný endpoint.

Co TLS neví?

Správný TLS nedokazuje, že:

• stránka je zabezpečená na úrovni aplikace,
• JavaScript nemá XSS,
• uživatel má správná oprávnění,
• canonical je správný,
• Google zaindexuje obsah,
• karta Open Graph má dobrý obrázek.

Zelený zámek znamená chráněné spojení s názvem, který klient akceptoval. Není certifikátem kvality celé aplikace.

Pravda číslo 3: prohlížeč vidí výsledek fungování celého prostředí

Prohlížeč vykonává mnohem více práce než pouhé stažení HTML. Typická navigace zahrnuje DNS, transportní spojení, TLS, HTTP požadavek, analýzu HTML, stažení CSS a JavaScriptu, sestavení DOM a CSSOM, layout a renderování pixelů.

To, co uživatel vidí na obrazovce, může být jiné než zdrojový kód odpovědi.

Zdrojové HTML, DOM a obrazovka jsou tři různé věci

HTML ze serveru

<div id="app"></div>
<script src="/app.js"></script>

DOM po vykonání JavaScriptu

<div id="app">
  <h1>Raport dla zalogowanego użytkownika</h1>
</div>

Obraz na obrazovce

Na výsledný vzhled mají vliv ještě CSS, fonty, velikost viewportu, dostupnost obrázků, systémová nastavení a interakce uživatele.

Co personalizuje „pravdu prohlížeče“?

• cookies a relace,
• localStorage a sessionStorage,
• jazyk prohlížeče,
• časové pásmo,
• šířka obrazovky,
• prefers-color-scheme,
• prefers-reduced-motion,
• oprávnění,
• A/B experiment,
• odpovědi API,
• stav přihlášení.

Prohlížeč má také soukromou HTTP cache. Odpověď uložená jako čerstvá může být použita bez opětovného stažení, v závislosti na direktivách cache.

Service worker může zachytávat požadavky a vracet data z vlastní cache nebo z nestandardní offline strategie. To vysvětluje situace, kdy běžné obnovení stále zobrazuje starou verzi, zatímco anonymní režim zobrazuje novou.

Proč je „u mě to funguje“ slabý test?

Vlastník stránky může mít:

• aktivní relaci administrátora,
• data v cache,
• starý service worker,
• přístup k API, které není veřejně dostupné,
• jiný jazyk a region,
• rozšíření upravující stránku,
• přeskočený banner nebo onboarding.

Test v prohlížeči by měl zahrnovat čistý profil, anonymní režim, mobilní zařízení, IPv4, IPv6 a nepřihlášeného uživatele.

Pravda číslo 4: Googlebot vidí stránku určenou ke crawlování, renderování a indexování

Google popisuje zpracování JavaScriptových stránek jako tři hlavní fáze:

1. crawling,
2. rendering,
3. indexing.

Googlebot stáhne URL, analyzuje odpověď a může předat stránku do Web Rendering Service. Google používá k renderování aktuální verzi prohlížeče Chrome, ale výsledek nemusí vzniknout ve stejném okamžiku jako první stažení.

Googlebot není běžný uživatel

Google má Googlebot Smartphone a Desktop a u většiny stránek indexuje především mobilní verzi. Většina požadavků tedy pochází od mobilního crawleru.

Googlebot:

• nepřihlašuje se k vašemu účtu,
• nemá vaše cookies,
• nevidí soukromá data,
• nechová se jako uživatel procházející všechny scénáře,
• může stahovat zdroje samostatně,
• podléhá robots.txt a kontrolám indexování.

Google výslovně uvádí, že nenačte hlavní obsah vyžadující interakci, jako je kliknutí, zadání dat nebo posunutí prvku.

Robots.txt není totéž co noindex

robots.txt řídí, které URL může crawler stahovat. Google zdůrazňuje, že to není mechanismus, který by zaručoval odstranění URL z výsledků.

Aby noindex zafungoval, crawler musí být schopen stránku stáhnout a vidět značku nebo hlavičku. Pokud je URL zároveň zablokovaná v robots.txt, Google nemusí noindex vidět.

<meta name="robots" content="noindex">

nebo:

X-Robots-Tag: noindex

Canonical je nápověda, ne bezpodmínečný příkaz

<link rel="canonical" href="https://example.com/artykul">

Google může vybrat jinou verzi canonical, než uvedl vlastník, protože canonicalizace zohledňuje mnoho signálů. Google označuje uvedení canonical za nápovědu, ne za pravidlo.

Co může vidět uživatel, ale ne Googlebot?

• obsah až po kliknutí na „Zobrazit více“,
• data dostupná pouze po přihlášení,
• prvek závislý na nedostupném API,
• obsah načítaný zablokovaným skriptem,
• desktopovou verzi bohatší než mobilní,
• komponentu fungující pouze s daty uloženými v prohlížeči.

Co může vidět Googlebot, ale ne běžný uživatel?

Server může například vracet jinou variantu pro jeho user-agent. Samotné technické přizpůsobení není automaticky porušením, ale záměrné zobrazování zásadně odlišného obsahu vyhledávači než uživatelům může být považováno za cloaking.

Nejbezpečnější praxí je poskytnout stejný podstatný obsah v počáteční odpovědi nebo v renderování, které nevyžaduje interakci uživatele.

Pravda číslo 5: crawler sociálních sítí staví kartu, ne plný zážitek ze stránky

Když je URL vložena do Facebooku, LinkedInu, Slacku nebo jiné platformy, systém může stránku stáhnout a sestavit náhled. Nemělo by se předpokládat, že každá platforma spouští JavaScriptovou aplikaci přesně jako plnohodnotný prohlížeč uživatele.

Nejpřenositelnějším způsobem popisu stránky je metadata umístěná v <head> počátečního HTML.

Základní Open Graph

Specifikace Open Graph definuje čtyři povinné vlastnosti:

<meta property="og:title" content="Tytuł artykułu">
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/og/article.jpg">
<meta property="og:url" content="https://example.com/artykul">

V praxi je vhodné doplnit:

<meta property="og:description" content="Opis artykułu">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Opis grafiki">

Meta/Facebook

Meta doporučuje používat tagy Open Graph, aby crawler mohl získat titulek, popis a náhledový obrázek. Dokumentace Meta popisuje také stahování a ukládání metadat do cache při sdílení URL.

To znamená, že změna obrázku na serveru nemusí okamžitě změnit existující kartu. Platforma může stále mít starší snapshot.

LinkedIn

LinkedIn uvádí, že náhledy využívají mimo jiné Open Graph nebo oEmbed. Starý obrázek může pocházet z cache a Post Inspector umožňuje obnovit data pro nová sdílení.

Existující příspěvky mohou zachovat předchozí náhled i po obnovení URL.

Slack

Slack dokumentuje klasické unfurling jako proces, při kterém systém po zjištění odkazu prochází stránku a vytváří náhled. Aplikace Slack mohou také poskytovat vlastní, programovatelné unfurly.

To je důležité rozlišení: karta ve Slacku může být standardním výsledkem crawlování nebo nestandardním objektem vráceným integrací.

Proč platformy zobrazují jiné obrázky?

• jedna platforma má starou cache,
• jiná nemůže obrázek stáhnout,
• URL obrázku přesměrovává,
• obrázek má nedostupný MIME nebo stavový kód,
• několik og:image má jiné pořadí,
• stránka má samostatné tagy pro různé jazykové verze,
• bot dostává jinou variantu přes CDN nebo firewall,
• metadata jsou přidávána až JavaScriptem.

Nejbezpečnější je umísťovat základní tagy pro sociální sítě přímo do HTML ze serveru a uvádět absolutní HTTPS adresy.

Pravda číslo 6: bezpečnostní skener vidí pouze rozsah, který dokáže prozkoumat

„Bezpečnostní skener“ může znamenat velmi různé nástroje:

• analyzátor HTTP hlaviček,
• skener konfigurace TLS,
• DAST provádějící požadavky a testy zranitelností,
• crawler aplikace,
• SAST analyzující kód,
• skener závislostí,
• nástroj pro testování infrastruktury.

V tomto článku mluvíme především o externím skeneru, který zkoumá veřejně dostupnou stránku.

Co vidí skener hlaviček?

MDN HTTP Observatory hodnotí především HTTP hlavičky a vybrané bezpečnostní konfigurace.

Může kontrolovat mimo jiné:

• CSP,
• HSTS,
• ochranu proti framingu,
• X-Content-Type-Options,
• cookies,
• přesměrování na HTTPS,
• vybrané cross-origin politiky.

To neznamená, že přečetl kód backendu, role uživatelů, konfiguraci databáze nebo všechny API endpointy.

Písmenné hodnocení není verdiktem o celém zabezpečení

Dokumentace Observatory upozorňuje, že scoring má poukazovat na nevyužité bezpečnostní mechanismy a že potřeba konkrétní hlavičky může záviset na typu webu.

Stránka může získat vysoké hodnocení hlaviček a přesto mít:

• IDOR,
• chybnou autorizaci,
• SQL Injection,
• zranitelný administrační panel,
• odhalené klíče,
• byznysovou logiku umožňující zneužití.

Možná je i opačná situace: jednoduchý JSON endpoint dostane horší hodnocení za chybějící hlavičky typické pro HTML dokument, přestože některé z nich pro něj nemají stejný význam.

DAST má jiný rozsah, ale rovněž omezení

OWASP popisuje web application vulnerability scanners jako nástroje, které aplikace externě testují na zranitelnosti a chybnou konfiguraci.

ZAP upozorňuje, že automatické skenování má omezení. Bez nakonfigurovaného ověření neodhalí stránky za přihlášením a automatický spider neprovede všechny realistické uživatelské procesy.

Výsledek závisí na:

• účtu a roli použité v testu,
• dostupných URL,
• formulářích a testovacích datech,
• rozsahu domén,
• user-agentu,
• limitů WAF,
• doby skenování,
• toho, zda skener vykonává JavaScript.

Skener říká: „v tomto rozsahu jsem našel nebo nenašel určité signály“. Neříká: „dokázal jsem, že neexistují žádné zranitelnosti“.

Jedna URL, šest správných zpráv

Následující příklad je hypotetický, ale technicky realistický.

Zkoumaná adresa:

https://example.com/raport

DNS

A:    192.0.2.10
AAAA: 2001:db8::20
TTL:  300

Závěr: doména má dva možné endpointy.

TLS přes IPv4

SAN: example.com, www.example.com
TLS: 1.3
Chain: poprawny

TLS přes IPv6

SAN: old.example.net
TLS: 1.2
Chain: poprawny, ale zła nazwa

Závěr: část klientů stránku neotevře.

Prohlížeč vlastníka

• používá IPv4,
• má aktivní relaci,
• service worker vrací verzi z cache,
• zobrazuje aktuální zprávu.

Závěr uživatele: „všechno funguje“.

Googlebot Smartphone

• míří přes IPv6,
• nemůže projít TLS,
• stránku nestahuje.

Závěr SEO: nový obsah není crawlován.

LinkedIn

• má náhled uložený o týden dříve,
• zobrazuje předchozí og:image.

Závěr marketingu: karta je neaktuální.

Skener hlaviček

• testuje IPv4,
• stahuje dokument bez přihlášení,
• zjišťuje chybějící CSP a HSTS.

Závěr bezpečnosti: transport funguje, ale hardening odpovědi je neúplný.

Všechny zprávy popisují jinou část systému.

Matice symptomů

Symptom	Nejpravděpodobnější perspektiva	První test
Stránka funguje jen části uživatelů	DNS, IPv6 nebo TLS	dig A/AAAA, test obou adres
Certifikát jiné domény	TLS/SNI	openssl s_client -servername
Po nasazení je stále vidět stará stránka	cache prohlížeče nebo service worker	čistý profil, DevTools Application
Google zobrazuje starý titulek	crawl/index cache nebo jiný canonical	URL Inspection, kontrola rendered HTML
Stránka není v indexu	robots, noindex, chyby crawlování	robots.txt, Search Console
Facebook nebo LinkedIn zobrazuje starý obrázek	cache crawleru sociálních sítí	debugger nebo Post Inspector
Skener ukazuje chybějící HSTS, ale prohlížeč používá HTTPS	hlavičky odpovědi	curl -I pro finální URL
Výsledek skeneru je dobrý, ale funkce má chybu přístupu	logika aplikace mimo rozsah skeneru	test autorizace a rolí
Mobilní obsah je v Google chudší	mobile-first a odlišný obsah	porovnání mobilního renderu
noindex nefunguje	URL zablokovaná v robots.txt	povolení crawlování a opakovaný test

Metodika kompletního auditu

1. Zaznamenejte úplný řetězec URL

curl -IL https://example.com/artykul

Věnujte pozornost:

• stavům,
• změně hostitele,
• přechodu HTTP→HTTPS,
• koncové URL,
• počtu přesměrování.

2. Zkontrolujte DNS z několika resolverů

dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com CAA
dig example.com A +dnssec

Porovnejte odpovědi s resolverem operátora, veřejným resolverem a autoritativním serverem.

3. Zkontrolujte každý endpoint TLS

openssl s_client \
  -connect 192.0.2.10:443 \
  -servername example.com \
  -showcerts

Zopakujte pro IPv6 a další adresy vrácené DNS.

4. Zkontrolujte HTTP odpověď bez stavu uživatele

curl -sS -D headers.txt https://example.com/artykul -o page.html

Ověřte:

• stavový kód,
• Content-Type,
• cache,
• CSP,
• HSTS,
• X-Robots-Tag,
• obsah <head>.

5. Porovnejte zdrojové HTML a DOM

V prohlížeči zkontrolujte:

• View Source,
• panel Elements,
• Network,
• Application,
• aktivní service worker,
• cache storage,
• cookies.

6. Zkontrolujte Googlebota

Použijte nástroj URL Inspection v Google Search Console a porovnejte:

• stažené HTML,
• vyrenderované HTML,
• screenshot,
• zdroje, které se nepodařilo načíst,
• canonical uvedený a vybraný Googlem,
• možnost indexování.

Neidentifikujte Googlebota pouze podle user-agentu. Google doporučuje ověření přes reverse DNS nebo oficiální rozsahy IP.

7. Zkontrolujte kartu pro sociální sítě

Analyzujte:

<title>
<meta name="description">
<meta property="og:title">
<meta property="og:description">
<meta property="og:image">
<meta property="og:url">

Poté použijte obnovovací nástroje konkrétní platformy.

8. Spusťte několik tříd bezpečnostních testů

• analýzu hlaviček,
• test TLS,
• DAST na k tomu určeném prostředí,
• testy ověření a autorizace,
• analýzu závislostí,
• revizi kódu a konfigurace.

Jedno hodnocení nenahrazuje ostatní.

Vzorový <head> dostupný pro různé klienty

<!doctype html>
<html lang="pl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>Jedna domena, sześć różnych prawd</title>
  <meta
    name="description"
    content="Jak DNS, TLS, przeglądarka, Googlebot, social crawler i skaner bezpieczeństwa widzą tę samą domenę."
  >

  <link
    rel="canonical"
    href="https://example.com/jedna-domena-szesc-prawd"
  >

  <meta name="robots" content="index,follow">

  <meta
    property="og:title"
    content="Jedna domena, sześć różnych prawd"
  >
  <meta property="og:type" content="article">
  <meta
    property="og:url"
    content="https://example.com/jedna-domena-szesc-prawd"
  >
  <meta
    property="og:image"
    content="https://example.com/images/six-truths-1200x630.jpg"
  >
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta
    property="og:image:alt"
    content="Schemat sześciu warstw obserwujących jedną domenę"
  >
</head>

Nejdůležitější metadata jsou v HTML odpovědi, a ne teprve po spuštění aplikace.

Praktický checklist „šesti pravd“

DNS

• A a AAAA vedou na aktivní endpointy.
• Všechny autoritativní servery vracejí konzistentní data.
• TTL je srozumitelné a monitorované.
• DNSSEC prochází validací.
• www a apex mají zamýšlené chování.
• Test byl proveden z několika resolverů a lokalit.

TLS

• Každá IP adresa vrací správný certifikát.
• SAN zahrnuje každý používaný hostname.
• Chain je kompletní.
• IPv4 a IPv6 mají stejnou kvalitu konfigurace.
• SNI vybírá správný virtual host.
• CDN a origin mají správný TLS.

Prohlížeč

• Stránka funguje v čistém profilu.
• Byla zkontrolována nepřihlášená verze.
• Zdrojové HTML obsahuje klíčový obsah a metadata.
• DOM po renderování odpovídá očekávání.
• Service worker a cache nemaskují nasazení.
• Mobilní verze obsahuje plný obsah.
• Chyby API jsou ošetřeny.

Googlebot

• robots.txt umožňuje stáhnout stránku a zdroje.
• noindex odpovídá záměru.
• Canonical je konzistentní s přesměrováními a sitemapou.
• Hlavní obsah nevyžaduje kliknutí.
• Mobilní render obsahuje stejný podstatný obsah.
• URL Inspection zobrazuje správné HTML a screenshot.
• Zdroje CSS a JS jsou dostupné.

Crawler sociálních sítí

• Základní Open Graph se nachází v počátečním HTML.
• og:url ukazuje na správnou stálou URL.
• og:image je absolutní HTTPS adresa.
• Obrázek vrací 200 a správný MIME.
• Rozměry obrázku jsou deklarovány.
• Každá jazyková verze má správná metadata.
• Cache platformy byla po změně obnovena.

Bezpečnost

• Byly otestovány hlavičky finální odpovědi.
• Test zahrnuje více než homepage.
• Byly zkontrolovány endpointy po přihlášení.
• Role uživatelů byly otestovány samostatně.
• Automatické výsledky ověřil člověk.
• DAST byl doplněn o SAST a analýzu závislostí.
• Slabé nebo vysoké hodnocení bylo interpretováno v kontextu.

Nástroje POLPROG užitečné při takovém auditu

• Inspektor DNS a SSL zobrazuje záznamy domény a data certifikátu.
• Open Graph Preview kontroluje metadata a kartu sdílení.
• Inspektor bezpečnostních hlaviček analyzuje hardening HTTP odpovědí.
• Kondice webu spojuje signály SEO, výkonu, dostupnosti a bezpečnosti.
• FlowTrace vizualizuje cestu od události v prohlížeči přes DNS, TLS, CDN, backend a renderování.

Nejčastější mýty

„Když stránka funguje u mě, funguje všude“

Ne. Váš resolver, IP protokol, cache, cookies a uzel CDN mohou být jiné.

„Google vidí přesně totéž co Chrome“

Google renderuje stránky pomocí prohlížeče Chrome, ale Googlebot má jiný stav, mobile-first user-agent, samostatné fáze crawlování a renderování a nevykonává obsah vyžadující interakci.

„Robots.txt odstraní stránku z Google“

Ne. Robots.txt omezuje crawling. K řízení indexování slouží noindex, který musí být pro crawler viditelný.

„Canonical nutí Google použít vybranou URL“

Ne. Je to důležitý signál, ale Google může vybrat jiný canonical.

„Změnil jsem og:image, takže karta je už nová“

Ne vždy. Platforma může používat uloženou verzi a vyžadovat opětovné stažení URL.

„A+ ve skeneru znamená, že aplikace je bezpečná“

Ne. Znamená to vysoké hodnocení v konkrétní sadě testů. Nedokazuje správnou autorizaci, byznysovou logiku ani bezpečnost kódu.

Verdikt

Jedna doména nemá jednu technickou „tvář“.

• DNS vidí název a záznamy.
• TLS vidí endpoint a identitu certifikátu.
• Prohlížeč vidí vyrenderovaný zážitek konkrétního uživatele.
• Googlebot vidí zdroj dostupný ke crawlování, renderování a indexování.
• crawler sociálních sítí vidí metadata potřebná k sestavení karty.
• bezpečnostní skener vidí výhradně povrch pokrytý jeho testy.

Zralý audit se tedy neptá jen: „Funguje stránka?“

Ptá se:

Dla kogo?
Z jakiej lokalizacji?
Po IPv4 czy IPv6?
Z jakim stanem cache?
Z jakim user-agentem?
Przed czy po wykonaniu JavaScriptu?
Z logowaniem czy bez?
W jakim zakresie testu?

Teprve odpovědi na tyto otázky vytvářejí ucelený obraz systému.