Bezpečnost plateb: PCI DSS pro e-shopy prakticky
Kartu za vás zpracovává platební brána, ale odpovědnost za bezpečnost platební stránky zůstává i na vás. Vysvětlujeme, co PCI DSS v4.0.1 od e-shopu chce a jak to splnit bez zbytečné práce.
Většina českých e-shopů data karet vůbec nevidí. Zákazník je zadá na platební bráně a e-shop dostane jen výsledek platby. Přesto se na vás standard PCI DSS vztahuje. A od 31. 3. 2025 se na platební stránku e-shopu dívá přísněji než dřív, protože útoky vedou přes skripty, které běží v prohlížeči zákazníka.
V článku vysvětlujeme, co PCI DSS v4.0.1 znamená pro běžný e-shop, jak vybrat správný dotazník SAQ, co přesně se změnilo v roce 2025 a co udělat prakticky. Nejde o právní ani auditorské poradenství. Konkrétní povinnosti vám potvrdí váš acquirer nebo platební brána.
Co je PCI DSS a koho se týká
PCI DSS (Payment Card Industry Data Security Standard) vydává PCI Security Standards Council, který založily karetní společnosti. Nejde o zákon. Povinnost ho dodržovat vám ukládá smlouva s acquirerem nebo platební bránou. Týká se každého, kdo přijímá karty, bez ohledu na velikost.
Aktuální verze je PCI DSS v4.0.1, vydaná v červnu 2024. Předchozí verze 4.0 skončila k 31. 12. 2024. Požadavky, které byly ve verzi 4 označené jako budoucí, jsou povinné od 31. 3. 2025.
Malé a střední e-shopy obvykle neprocházejí auditem. Shodu prokazují sebehodnoticím dotazníkem (SAQ). Který dotazník vyplníte, určuje hlavně to, jak je platba technicky napojená.
Redirect, iframe, nebo vlastní formulář
Pro výběr dotazníku rozhoduje, kde zákazník zadává číslo karty a kdo ovládá stránku, na které to dělá.
| Způsob napojení | Jak funguje | Typický dotazník |
|---|---|---|
| Přesměrování (redirect) | Zákazník odejde na platební stránku brány a pak se vrátí | SAQ A |
| Iframe brány | Platební formulář brány je vložený do stránky e-shopu | SAQ A, s novým kritériem ochrany proti skriptům |
| Formulář e-shopu posílající data přímo bráně (direct post, JavaScript) | Data jdou do brány, ale stránku s formulářem ovládá e-shop | SAQ A-EP |
| Data karty prochází serverem e-shopu | E-shop kartu přijímá, zpracovává nebo ukládá | SAQ D, výrazně náročnější |
Rozdíl mezi SAQ A a SAQ A-EP je velký. SAQ A má zlomek požadavků. SAQ A-EP zahrnuje mimo jiné pravidelné skenování zranitelností a řadu požadavků na správu serveru. SAQ D pokrývá prakticky celý standard.
Proto doporučujeme přesměrování nebo iframe brány a nikdy vlastní formulář na čísla karet. Většina českých bran, například Comgate, GoPay, Global Payments nebo Stripe, nabízí přesměrování na svou platební stránku, některé i vložený formulář. Konkrétní dotazník vám potvrdí acquirer, tabulka je jen orientační.
Co se změnilo v roce 2025: požadavky 6.4.3 a 11.6.1
Útoky typu Magecart vkládají do platební stránky škodlivý JavaScript, který opíše zadávané údaje karty. Nemusí napadnout bránu. Stačí kompromitovaný skript třetí strany, například analytika nebo chat, který běží na stejné stránce.
PCI DSS v4 na to reaguje dvěma požadavky platnými od 31. 3. 2025:
- 6.4.3 vyžaduje u všech skriptů na platební stránce evidenci, zdůvodnění, proč tam jsou, schválení a mechanismus, který ověří jejich integritu.
- 11.6.1 vyžaduje mechanismus, který odhalí neoprávněnou změnu platební stránky a HTTP hlaviček, jak je dostává prohlížeč zákazníka. Kontrola musí běžet nejméně jednou týdně, nebo v intervalu podle cílené analýzy rizik.
Úprava SAQ A v lednu 2025
Původně měly oba požadavky platit i pro e-shopy se SAQ A. PCI SSC v lednu 2025 zveřejnil upravený SAQ A, platný od 31. 3. 2025. Z dotazníku odstranil požadavky 6.4.3 a 11.6.1 a navázaný požadavek 12.3.1. Místo toho přidal kritérium způsobilosti: obchodník potvrzuje, že jeho web není náchylný k útokům skripty, které by mohly ovlivnit jeho platební systém.
Podle následného FAQ PCI SSC se kritérium týká e-shopů, které mají formulář brány vložený do své stránky, typicky přes iframe. Splnit ho jde dvěma způsoby:
- Web chráníte sami, například technikami podle požadavků 6.4.3 a 11.6.1.
- Získáte potvrzení od poskytovatele iframe, který splňuje PCI DSS, že jeho řešení při správné implementaci obsahuje ochranu proti skriptovým útokům.
PCI SSC zároveň zdůrazňuje, že úprava dotazníku neruší samotné požadavky standardu. Mění jen způsob, jak o nich obchodník podává zprávu. U čistého přesměrování na stránku brány zůstává situace nejjednodušší.
Tokenizace: proč data karty nechcete mít
Pokud potřebujete opakované platby, předplatné nebo platbu jedním kliknutím, nemusíte kvůli tomu ukládat karty. Brána vám vrátí token, tedy náhradní identifikátor karty, se kterým můžete další platby zakládat. Samotné číslo karty zůstává u brány.
Tokenizace drží e-shop mimo nejnáročnější část standardu. Data karty neukládáte, nemáte je v databázi, v zálohách ani v logách. Pozor na logy obecně: chyby při ladění integrace, kdy se do logu zapíše celý požadavek na bránu, jsou typickou cestou, jak se citlivá data dostanou tam, kam nemají.
PSD2 a silné ověření zákazníka
Vedle PCI DSS platí pro platby kartou evropská směrnice PSD2 a povinnost silného ověření klienta (SCA). V praxi ho zajišťuje protokol 3D Secure, kdy zákazník platbu potvrdí v aplikaci banky. PCI DSS chrání data karty, SCA ověřuje, že platí její držitel. Potřebujete obojí.
SCA řeší brána a banka zákazníka. E-shop ovlivní hlavně to, zda brána posílá dostatek údajů pro hladké ověření a zda využívá výjimky. Vlivu 3D Secure na konverzi se podrobně věnujeme v článku o 3D Secure a konverzním poměru.
Checklist: co udělat prakticky
- Zjistěte, jak máte napojenou bránu. Přesměrování, iframe, nebo vlastní formulář. Pokud nevíte, zeptejte se vývojáře nebo nás.
- Ověřte u acquirera nebo brány, jaký dotazník máte vyplnit a jak často shodu dokládat.
- Zbavte se vlastního formuláře na karty, pokud ho máte. Přechod na přesměrování nebo iframe výrazně sníží rozsah povinností.
- U iframe získejte potvrzení od brány k novému kritériu SAQ A, nebo zaveďte vlastní ochranu skriptů.
- Zmapujte skripty na stránkách s platbou. Analytika, chaty, A/B testy, pixely. Co tam nemusí být, odstraňte.
- Nastavte Content Security Policy a hlídejte změny stránky a hlaviček.
- Pro opakované platby používejte tokeny, nikdy neukládejte čísla karet.
- Zkontrolujte logy a zálohy, zda neobsahují data karet.
- Chraňte přístupy do administrace e-shopu a brány dvoufaktorovým ověřením. Obecné zabezpečení popisujeme v článku o základním hardeningu e-shopu.
- Opakujte kontrolu po každé změně checkoutu, šablony nebo platební integrace.
Kdy nám zavolat
Pokud nevíte, jaký dotazník vám patří, máte v checkoutu vlastní formulář na karty nebo chystáte změnu brány, projdeme to s vámi. Napojení platební brány řešíme v rámci služby platební systémy. Standardní implementace jedné brány u nás obvykle trvá 1–2 týdny. Pokud potřebujete nejdřív zjistit, kde stojíte, začněte konzultací.
Potřebujete s tím pomoct?