Bezpečnostní zásady v PHP kódu

Proč bezpečnost v PHP není jen o frameworku

PHP pohání významnou část webu a jeho bezpečnost stojí na třech pilířích: správný návrh (threat modeling a bezpečnostní architektura), bezpečná implementace (obrana na všech vrstvách: vstup → logika → výstup) a provozní disciplína (konfigurace, aktualizace, monitoring). Bez ohledu na použitý framework (Laravel, Symfony, Nette, Slim aj.) platí, že musíte chránit hranice systému, data, identitu uživatele i integritu běhového prostředí.

Validace vstupů a normalizace dat

Vstup (HTTP parametry, JSON, hlavičky, cookies, uploady) musí být považován za nedůvěryhodný. Aplikujte whitelist validace (formát, rozsah, délka, povolené znaky) a normalizaci (trim, canonicalization) před dalším zpracováním. Nikdy nespoléhejte na klientskou validaci.

• Pro strukturovaná data využijte filter_var(), validační knihovny (např. symfony/validator) a vlastní pravidla.
• Pro identifikátory používejte pevné datové typy (int, uuid), ne string bez omezení.
• Neakceptujte dodatečná pole v JSON (proti „mass assignment“ používejte explicitní mapování povolených atributů).

Bezpečný výstup a prevence XSS

Cross-Site Scripting vzniká, když neescapovaný vstup skončí v HTML, JavaScriptu, CSS či URL. Zásady:

• Kontextové escapování: HTML, atribut, URL, JavaScript, CSS – každý kontext má jiná pravidla.
• Zapněte autoescapování v šablonách (Twig/Blade/Latte) a ručně escapujte dynamické části v JS (json_encode($data, JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS|JSON_HEX_QUOT)).
• Omezte inline skripty a použijte Content-Security-Policy (CSP) s nonce (Content-Security-Policy: script-src 'self' 'nonce-...').
• Sanitizace rich textu přes whitelist (např. HTML Purifier) – nikdy nepouštějte syrové HTML.

SQL Injection a práce s databází

Veškeré dotazy stavte pomocí prepared statements (PDO, Doctrine DBAL, Eloquent) s parametrizací. Nikdy neinterpolujte vstup do SQL řetězce.

• Používejte PDO::prepare() a bindValue() s odpovídajícími typy; vypněte emulované prepared statements (PDO::ATTR_EMULATE_PREPARES = false).
• Pro ORM zajistěte, že query builder parametrizuje klauzule; dynamické názvy sloupců validujte proti whitelistu.
• Rozdělte role DB uživatelů (jen SELECT pro reporting, minimální práva pro app uživatele).

CSRF ochrana a správa relací

Cross-Site Request Forgery se brání CSRF tokeny v mutačních požadavcích (POST/PUT/PATCH/DELETE). Doporučení:

• Generujte kryptograficky silné tokeny (random_bytes(), bin2hex()) vázané na session; validujte jednorázově (rotace).
• Nastavte cookies HttpOnly, Secure, SameSite=Lax/Strict dle kontextu.
• Po přihlášení vždy regenerujte session ID (session_regenerate_id(true)) – prevence fixation.
• U API preferujte bearer tokeny v Authorization hlavičce; pro SPA zvažte double-submit token nebo SameSite strategii.

Ověřování, autorizace a správa hesel

Bezpečné heslové hospodářství a řízení přístupu jsou klíčové:

• Hesla ukládejte pomocí password_hash() (prioritně Argon2id nebo bcrypt) a ověřujte password_verify(). Používejte password_needs_rehash() pro migrační rehash.
• Rate limit pro login, lockout po několika pokusech, audit přihlášení a MFA (TOTP/WebAuthn).
• Autorizaci implementujte deny-by-default, RBAC/ABAC s kontrolami v kontrolerech i na úrovni dotazů (scoped queries).
• Pro časové porovnání tokenů/otisků používejte hash_equals() (ochrana proti timing útokům).

Bezpečné nahrávání souborů a cesty

Nahrané soubory představují vysoké riziko:

• Ukládejte mimo webroot a obsluhujte přes kontroler; pro veřejné servírování nastavte striktní Content-Type/Disposition.
• Validujte MIME (server-side), velikost, typ; generujte nové názvy a adresářovou strukturu.
• Zabraňte RCE a path traversal: nikdy nepracujte s uživatelskými cestami, používejte basename(), mapujte ID→cesta, blokujte .. a nulové bajty.
• Obrázky/mediální soubory procházejte přes bezpečné knihovny; nespouštějte externí binárky bez whitelistu argumentů.

Deserializace, eval a vzdálené volání

Vyhněte se nebezpečným funkcím (eval, assert se stringem, unserialize na nedůvěryhodných datech). Pokud musíte deserializovat, používejte unserialize($data, ['allowed_classes' => false]) nebo lépe JSON s explicitním mapováním. SOAP/RPC volání a webhooks validujte podepsanými požadavky a striktními timeouty.

SSRF, otevřené přesměrování a bezpečná práce s URL

Ověřujte a omezujte externí požadavky:

• Whitelist domén/hostitelů, zákaz interních IP rozsahů (169.254.0.0/16, 127.0.0.0/8, 10/8, 172.16/12, 192.168/16, link-local IPv6).
• DNS re-resolve po přesměrování a kontrola schémat (https pouze).
• U přesměrování z uživatelských parametrů používejte relative paths nebo mapu aliasů; jinak hrozí phishing (open redirect).

Bezpečná kryptografie

Neimplementujte vlastní šifrování. Používejte libsodium (sodium_crypto_aead_xchacha20poly1305_ietf_*) nebo openssl_encrypt s AEAD (AES-GCM). Klíče ukládejte mimo repozitář (env, secret manager), rotujte a omezte přístupy. Pro náhodná data používejte random_bytes(), nikoli mt_rand().

HTTP hlavičky a prohlížečová ochrana

Správná sada hlaviček zvyšuje baseline bezpečnost:

• Strict-Transport-Security (HSTS), vynucení HTTPS.
• Content-Security-Policy (CSP) s nonce/hashi, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy.
• Frame-Ancestors (v CSP) proti clickjackingu.

Chybové stavy, logování a informace ven

V produkci vypněte výpis chyb do výstupu a logujte bezpečně:

• display_errors = Off, log_errors = On, vlastní handler, korelace request-id.
• Nikdy nelogujte tajemství (hesla, tokeny, klíče). Maskujte PII dle GDPR.
• Uživatelům vracejte generické chybové stránky; detaily pouze do logů/observability (Sentry, ELK, OpenTelemetry).

Konfigurace PHP a hardening prostředí

Bezpečné defaulty výrazně omezí riziko:

• expose_php = Off, allow_url_fopen = Off (pokud není nutné), allow_url_include = Off.
• Omezte file_uploads a velikosti (upload_max_filesize, post_max_size), max_input_vars, rozumné timeouty (max_execution_time, default_socket_timeout).
• Na úrovni serveru: izolace účtů (FPM pool per app, chroot/containers), read-only kód, oddělené adresáře var/, tmp/ s noexec.

Závislosti, dodavatelský řetězec a aktualizace

Composer je mocný, ale vyžaduje disciplínu:

• Uzamkněte verze (composer.lock v repu), sledujte security advisories a pravidelně aktualizujte (Dependabot, Renovate).
• Používejte pouze důvěryhodné balíčky, minimální sadu a auditujte skripty v composer.json (sekce scripts).
• Zapněte autoload-classmap authoritative v produkci pro výkon a determinismus.

API bezpečnost: JWT, cookies a CORS

U API přes JWT dbejte na:

• Krátkou životnost (minuty), podpis HS256/RS256 se správou klíčů, audience/issuer kontrolu, kid validaci proti podvrhu.
• Nepřidávejte citlivá data do payloadu; JWT je pouze base64url, nikoli šifrování.
• CORS: explicitní Access-Control-Allow-Origin (bez * pro credentialed), povolené metody/hlavičky, nikdy neotvírejte Access-Control-Allow-Credentials: true s *.

Výkon vs. bezpečnost: rate limiting a antibrute-force

Implementujte ochrany proti zneužití:

• Rate limiting (token bucket, Redis) na citlivé endpointy (login, reset hesla, e-mail odeslání).
• Detekce anomálií (neplatné tokeny, neobvyklé geografie), šedé listiny a dynamická captcha až po prahu.

Bezpečnostní testování a CI/CD

Integrujte bezpečnost do pipeline:

• Static analysis (PHPStan/Psalm) s pravidly pro bezpečnost, lint šablon (CSP porušení, neescapované bloky).
• SAST/DAST skenery, závislostní audit (roave/security-advisories), unit/integration testy pro authz scénáře.
• Secrets scanning (Git hooks, CI) a pre-commit ochrany; podpisy releasů, SBOM (CycloneDX).

Šablonovací systémy a bezpečnost v praxi

Preferujte šablonovací stroje s autoescape (Twig/Latte/Blade). Zakazujte arbitrary code execution v šablonách, oddělte prezentační a aplikační logiku, využijte komponenty namísto raw echo. U e-mailových šablon stále escapujte a validujte URL.

Víceinstanční (multi-tenant) aplikace

Striktně vynucujte tenant scoping v každém dotazu (WHERE tenant_id = ?), validujte přístupové tokeny na úrovni tenanta, izolujte úložiště a cache klíče (tenant:<id>:* ). Vyhněte se insecure direct object references (IDOR) – nikdy nepoužívejte sekvenční ID bez kontroly vlastnictví.

Monitorování, audit a reakce na incidenty

Kromě logů provozujte metriky (latence, chybovost, 4xx/5xx), bezpečnostní události (přihlášení, změny práv, administrace) a alerty. Mějte připravené runbooky pro reset tokenů, rotaci klíčů a forced logout. Pravidelně provádějte zálohy a test obnovy.

Checklist minimálních opatření

• Prepared statements všude; žádné dynamické SQL bez whitelistu.
• Autoescape šablon + CSP s nonce.
• Session: Secure, HttpOnly, SameSite; regenerace po loginu; CSRF tokeny.
• Hesla: password_hash() (Argon2id/bcrypt), rate limit loginu, MFA.
• Uploads mimo webroot, validace MIME, nové názvy, žádné spouštění.
• Bezpečná konfigurace PHP a web serveru; logování bez tajemství.
• Aktualizace závislostí, audit balíčků, SAST v CI.

Závěr: bezpečnost jako kontinuální proces

Bezpečnost PHP aplikací není jednorázový úkol, ale soustava návyků a automatizovaných kontrol. Kombinací kontextového escapování, striktní validace, minimálních oprávnění, bezpečné kryptografie, správně nastavených hlaviček a provozní disciplíny vytvoříte kód, který odolá běžným útokům a bude lépe škálovat i auditovat. Standardizujte postupy v týmu, integrujte je do CI/CD a pravidelně je testujte v praxi.