Bezpečnost API integrací v ecommerce
Každá integrace je další dveře do e-shopu. Ukážeme, kde se klíče nejčastěji ztrácejí, jak ověřit, že webhook opravdu poslala platforma, a co hlídat u dodavatelů.
Moderní e-shop mluví přes API s ERP, dopravci, platební bránou, marketplace, e-mailingem a desítkou doplňků. Každé takové napojení je další vstup do vašich dat: objednávek, zákazníků, cen i skladu. Útočník nemusí prolomit administraci e-shopu, když najde API klíč v zapomenutém skriptu nebo v repozitáři.
V tomto článku projdeme, kde integrace nejčastěji selhávají z pohledu bezpečnosti a jak to řešíme při stavbě napojení. Nejde o teorii pro banky. Jde o pravidla, která dávají smysl i pro e-shop s jedním ERP a třemi doplňky.
Kde integrace nejčastěji selhávají
Nezisková organizace OWASP vydává seznam nejzávažnějších rizik API. Aktuální vydání OWASP API Security Top 10 je z roku 2023 a podle jeho autorů jsou tři z prvních pěti rizik spojená s autorizací. V e-shopové praxi se to promítá do několika typických situací:
| Riziko | Jak vypadá v e-shopu | Obrana |
|---|---|---|
| Chybná autorizace na úrovni objektu | Změnou ID v URL si zákazník zobrazí cizí objednávku | Kontrola vlastnictví u každého požadavku |
| Chybná autentizace | API bez ověření, sdílený token pro všechny | Samostatný token pro každou službu, krátká platnost |
| Neomezená spotřeba zdrojů | Skript zahltí API a shodí synchronizaci | Rate limity, stránkování, časové limity |
| Příliš široká oprávnění | Feedový skript má právo mazat objednávky | Minimální oprávnění pro každý klíč |
| Nebezpečná konzumace API třetích stran | Data od dodavatele se zapisují bez kontroly | Validace všech vstupů, i od „důvěryhodných“ partnerů |
| Špatná konfigurace | Testovací endpoint dostupný z internetu, podrobné chybové hlášky | Oddělené prostředí, obecné chybové odpovědi |
Poslední řádek tabulky je podceňovaný. OWASP v roce 2023 přidal kategorii nebezpečné konzumace API právě proto, že útočníci stále častěji jdou přes napojené služby, ne přímo na cílový systém.
Klíče a tokeny: kde se ztrácejí
Většina úniků nezačíná sofistikovaným útokem. Začíná klíčem, který je vidět tam, kde nemá být:
- ve zdrojovém kódu a v repozitáři, včetně historie commitů,
- v tabulce „přístupy“ sdílené s celou firmou a bývalými dodavateli,
- v e-mailu nebo chatu, kde se klíč posílal „jen na chvíli“,
- v logu, kam se omylem zapisuje celá hlavička požadavku,
- na frontendu, kde ho v kódu stránky najde kdokoli.
Pravidla, která u integrací dodržujeme:
- Každá služba má vlastní klíč. Když unikne klíč feedového skriptu, zneplatníte jen ten.
- Klíče jsou ve správci tajemství nebo aspoň v proměnných prostředí, ne v kódu.
- Krátká platnost tam, kde to platforma umí. Shoptet například pro volání API používá dočasné tokeny s platností 30 minut, které se získávají z trvalého tokenu instalace doplňku (k 9/2026).
- Výměna klíčů je nacvičená. Víte, kde všude se klíč používá, a výměna netrvá den.
- Odchod člověka nebo dodavatele znamená výměnu klíčů, ke kterým měl přístup.
Správa přístupů lidí je samostatné téma. Popisujeme ji v článku Dvoufaktorové ověření a správa přístupů týmu.
Princip minimálních oprávnění
Každá integrace má dostat jen práva, která opravdu potřebuje. Skript, který generuje feed, potřebuje číst produkty. Nepotřebuje zapisovat, a už vůbec ne číst zákazníky.
Platformy to umožňují různě. WooCommerce u každého klíče REST API nabízí úroveň přístupu jen pro čtení, jen pro zápis, nebo čtení i zápis. Shoptet u doplňků vyžaduje, aby doplněk deklaroval, ke kterým datům potřebuje přístup, a u soukromých API tokenů přiděluje skupiny endpointů s právem čtení, zápisu, nebo obojího. Shopify pracuje s rozsahy přístupu (access scopes), které aplikace žádá při instalaci.
Praktická rada: při každém novém napojení si sepište, jaká data integrace čte a jaká zapisuje. Pokud dodavatel doplňku žádá plná práva a neumí vysvětlit proč, je to varovný signál.
Webhooky: ověřte, kdo je poslal
Webhook je obyčejný HTTP požadavek na vaši URL. Kdokoli, kdo adresu zná, může poslat falešnou zprávu „objednávka zaplacena“. Proto platformy webhooky podepisují a příjemce musí podpis ověřit.
| Platforma | Hlavička s podpisem | Algoritmus (k 9/2026) |
|---|---|---|
| Shoptet | Shoptet-Webhook-Signature | HMAC-SHA1 z těla zprávy, klíč z endpointu pro obnovu podpisového klíče |
| Shopify | X-Shopify-Hmac-SHA256 | HMAC-SHA256 v base64, klíčem je client secret aplikace |
| WooCommerce | X-WC-Webhook-Signature | HMAC-SHA256 v base64, klíčem je secret webhooku |
| Stripe | Stripe-Signature | Podpis včetně časové značky, knihovny ve výchozím stavu odmítají zprávy starší než 5 minut |
Na co si dát pozor při implementaci:
- Počítejte podpis ze surového těla zprávy. Shopify výslovně upozorňuje, že když framework tělo nejdřív převede na objekt, podpis nesedí.
- Porovnávejte podpisy v konstantním čase, ne běžným porovnáním řetězců.
- Chraňte se proti opakování zpráv. Stripe k tomu používá časovou značku v podpisu a doporučuje hodnotu tolerance nenastavovat na nulu, protože tím se kontrola vypne.
- Webhook berte jako signál, ne jako pravdu. U důležitých událostí (platba, storno) si stav ověřte dotazem na API.
- Zpracování je idempotentní. Stejná událost doručená dvakrát nesmí vytvořit dvě objednávky v ERP.
Praktické využití webhooků rozebíráme v článku Webhooky v ecommerce.
Vstupy od partnerů jsou taky vstupy
Data od dodavatele, z marketplace nebo z ERP se často zapisují do e-shopu bez kontroly, protože „je to náš partner“. Jenže feed dodavatele může obsahovat HTML nebo skript v popisu produktu, odkaz na obrázek mimo očekávanou doménu nebo nesmyslnou cenu. Když se takový obsah zobrazí na webu, problém máte vy, ne dodavatel.
Proto každý vstup validujeme: typy a rozsahy hodnot, povolené HTML značky v popisech, domény obrázků, délky textů. Integrační vrstva nebo middleware je ideální místo, kde tyto kontroly dělat jednou pro všechny zdroje.
Limity, logování a detekce
Bezpečnost není jen o tom, kdo se dostane dovnitř. Je i o tom, jestli si všimnete, že se něco děje.
- Rate limity na vašich endpointech. Když vystavujete vlastní API nebo příjem webhooků, omezte počet požadavků. Ochrání vás to před zahlcením i před hádáním ID.
- Respektujte limity partnerů. Shoptet povoluje nejvýš 3 souběžná spojení na token a při překročení vrací HTTP 429 (k 9/2026). Agresivní skript může zablokovat i ostatní integrace.
- Logujte, kdo co volal a kdy. Ale nikdy nelogujte celé tokeny, hesla ani platební údaje.
- Upozornění na anomálie. Náhlý nárůst chyb 401 a 403, požadavky z neznámých IP adres, stahování celé databáze zákazníků ve 3 ráno.
Obecné zabezpečení e-shopu popisujeme v článku Bezpečnost e-shopu: základní hardening. Pokud integrace pracuje s platebními údaji, platí navíc pravidla PCI DSS, viz Bezpečnost plateb a PCI DSS.
Jak na to prakticky
Bezpečnostní checklist pro každou integraci:
- Má integrace vlastní klíč, ne sdílený s jinou službou?
- Jsou klíče mimo zdrojový kód a mimo sdílené dokumenty?
- Má klíč jen oprávnění, která integrace opravdu potřebuje?
- Ověřujete podpis u všech příchozích webhooků?
- Je zpracování webhooků odolné proti duplicitám a opakování?
- Validujete data od partnerů před zápisem a zobrazením?
- Respektuje integrace limity API a má vlastní limity na vstupu?
- Logujete přístupy bez citlivých údajů a hlídáte anomálie?
- Víte, jak klíč vyměnit, a zvládnete to během hodiny?
Pokud si u svých napojení nejste jistí, projdeme je s vámi. Při stavbě nových integrací a vlastních API a microservices tyto body řešíme od prvního dne, u existujících napojení uděláme revizi a navrhneme, co opravit nejdřív. Rozsah a cenu připravíme po konzultaci.
Potřebujete s tím pomoct?