Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Eine Website ist nicht sicher, nur weil sie funktioniert. Schnell oder KI-gestützt entwickelte PHP-Projekte können Autorisierung, Upload-Prüfung, kontextbezogenes Output-Encoding, Prepared Statements, CSRF, Session- und Secret-Kontrollen auslassen. Dieser Leitfaden erklärt defensive Prüfungen ohne Exploit-Payloads.
Codegeneratoren beschleunigen Entwicklung, kennen aber nicht automatisch Trust Boundaries, Framework-Version und Deployment-Policy. Ein funktionierender Upload kann trotzdem Autorisierung, MIME-Prüfung oder sichere Ablage vermissen.
Den gesamten Route→Middleware→Controller→Storage→Datenbank-Fluss prüfen. Authentication und Authorization getrennt behandeln.
OWASP empfiehlt Allowlist-Endungen, serverseitige Typprüfung, generierte Dateinamen, Größenlimits, autorisierte Nutzer und möglichst Ablage außerhalb des Webroots.
Nur .php zu blockieren reicht nicht. Doppel-Endungen, Handler, MIME/Signatur, Dateinamen und Skriptausführung im Upload-Verzeichnis prüfen.
XSS-Abwehr benötigt kontextabhängiges Output-Encoding für HTML, Attribute, JavaScript, CSS und URLs; erlaubtes Rich HTML braucht vertrauenswürdige Sanitization.
Auch Admin-Panels sind über Namen, Produkttexte, Kommentare, Suchbegriffe oder Log-Viewer gefährdet. CSP ist Zusatzschutz, kein Ersatz.
Auch mit PDO kann unsichere String-Verkettung SQL Injection ermöglichen. OWASP empfiehlt parametrisierte Queries/Prepared Statements.
Dynamische Bezeichner über Allowlist wählen und Datenbankkonto mit minimalen Rechten betreiben.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
$sorgu = $pdo->prepare("SELECT id, ad FROM kullanicilar WHERE email = :email LIMIT 1");
$sorgu->execute([':email' => $email]);Benutzereingaben nicht direkt mit shell_exec, system, exec, passthru oder proc_open kombinieren. Wenn möglich Sprach-/Bibliotheks-API statt OS-Kommando verwenden.
Falls zwingend nötig: festes Programm/Argument-Schema, Allowlist, niedrig privilegiertes Konto und Timeout.
Authentication identifiziert den Nutzer, Authorization prüft Zugriff auf das konkrete Objekt. Ressourcenabfragen an aktuellen Benutzer/Tenant binden.
Admin-Aktionen brauchen serverseitige Rollen-/Rechteprüfung; versteckte UI-Schaltflächen sind keine Sicherheit.
Da Browser Session-Cookies automatisch senden, benötigen kritische Aktionen geeignete CSRF-Abwehr wie Token, SameSite und je nach Architektur Origin/Referer-Prüfung.
Löschen, E-Mail-/Kontowechsel, Rollenänderungen und Uploads priorisieren; GET sollte keinen Zustand ändern.
Secure, HttpOnly, passendes SameSite, Session-ID-Wechsel nach Login, Logout-Invalidierung, Rate-Limit und MFA für privilegierte Konten.
Passwörter mit password_hash/password_verify speichern; Reset-Tokens einmalig, kurzlebig und nicht erratbar.
.env, .git, SQL-Dumps, ZIP-Backups, Logs und Debug-Stacks nicht öffentlich ausliefern; Secrets nicht ins Repository hardcoden.
Production-Debug abschalten, geschützte technische Logs für Betreiber beibehalten.
Laut offizieller PHP-Tabelle ist 8.2 im August 2026 im Security-Support; 8.3, 8.4 und 8.5 sind unterstützte Zweige. PHP 8.1 ist seit Dezember 2025 EOL.
Upgrades über Staging und Kompatibilitätstest durchführen; Frameworks, Composer-Pakete und Plugins separat pflegen.
Schreibrechte nur wo nötig, nicht das gesamte Projekt auf 777 setzen. Skriptausführung in beschreibbaren Upload-/Cache-Verzeichnissen möglichst deaktivieren.
Webserver-, PHP-FPM- und Deployment-Identitäten trennen und Admin-Dienste per Firewall/VPN/IP-Policy beschränken.
Prüfung von Auth/AuthZ, Upload, Input/Output, Datenbank, Dateisystem, Command Execution, Secrets, Dependencies und Serverkonfiguration. Statische Findings werden am echten Anwendungsfluss validiert.
Kontrollierte Negativtests nur auf ausdrücklich autorisierter Staging-Kopie. Bericht mit Severity, betroffenem Endpoint/Datei, Fix und Retest-Status.
Allgemeiner Stand nach dem offiziellen PHP-Supportplan im August 2026. Bei Backports durch den Distributor zusätzlich dessen Lifecycle-Policy prüfen.
Standardfälle werden nach der Vorprüfung normalerweise in ein Analysefenster von 24–72 Stunden eingeplant. Die Dauer hängt von Dateimenge, Logzugriff, Schadcode-Verbreitung und Anwendungsarchitektur ab.
Wichtiger Hinweis: Nur eigene oder ausdrücklich autorisierte Systeme testen.
Nein. Er braucht vor Production dieselbe Sicherheitsprüfung.
Nein. Mehrschichtige Allowlist-, Typ-, Storage-, Auth- und Execution-Kontrollen sind nötig.
Prepared Statements schützen stark; unsichere Verkettung kann das Risiko zurückbringen.
Nein. Kontext-Encoding und Sanitization bleiben erforderlich.
Laut offiziellem Lifecycle ist 8.1 seit 18. Dezember 2025 EOL.
Externe Prüfung ja, Quellcodezugriff liefert aber deutlich bessere Code-Abdeckung.