Professioneller Code Review
Ich analysiere deinen Code auf Sicherheitsrisiken, Performance-Probleme und technische Schulden – mit konkreten Handlungsempfehlungen.
- Sicherheitslücken & OWASP Top 10
- Performance-Bottlenecks erkennen
- Technische Schulden dokumentieren
- Konkreter Massnahmenplan
Code Review anfragen
Ich melde mich schnellstmöglich bei dir.
100% kostenlos & unverbindlich
Warum ist ein Code Review wichtig?
Versteckte Sicherheitslücken und Performance-Probleme können teuer werden.
Ein professioneller Code Review deckt Schwachstellen auf, bevor sie zu echten Problemen werden. Ob du eine bestehende Anwendung übernommen hast, einen externen Entwickler kontrollieren möchtest oder einfach sicherstellen willst, dass dein Code auf dem neuesten Stand ist.
- SQL Injection & XSS Schwachstellen finden
- Performance-Bottlenecks identifizieren
- Technische Schulden dokumentieren
- Best Practices und Clean Code
Häufige Probleme, die ich finde
Was beinhaltet ein Code Review?
Umfassende Analyse deines Codes mit konkreten Handlungsempfehlungen
Sicherheitsanalyse
Prüfung auf OWASP Top 10 Schwachstellen, SQL Injection, XSS, CSRF und weitere Sicherheitsrisiken.
Performance-Analyse
Identifikation von Bottlenecks, langsamen Queries, Memory Leaks und Optimierungspotenzial.
Code-Qualität
Bewertung von Architektur, Design Patterns, Lesbarkeit und Wartbarkeit des Codes.
Dependency Check
Analyse verwendeter Bibliotheken auf bekannte Sicherheitslücken und Aktualität.
Dokumentation
Ausführlicher Bericht mit priorisierten Empfehlungen und Lösungsvorschlägen.
Besprechung
Persönliche Nachbesprechung aller Findings mit Erklärungen und Q&A.
Code Review Pakete
Quick Check
- Sicherheits-Scan
- Dependency Check
- Kurzbericht (2-3 Seiten)
- Priorisierte Empfehlungen
- Detaillierte Code-Analyse
Ideal für kleinere Projekte oder einen ersten Überblick.
Deep Dive
- Alles aus Quick Check
- Detaillierte Code-Analyse
- Performance-Profiling
- Architektur-Bewertung
- Ausführlicher Report (10+ Seiten)
- 1h Nachbesprechung
Für komplexe Projekte und gründliche Analyse.
Was wird beim Code Review geprüft?
Ein professioneller Code Review geht weit über einen einfachen Blick auf den Quellcode hinaus. Ich prüfe deinen Code systematisch auf alle relevanten Qualitätsdimensionen.
Moderne Webanwendungen sind komplex – und Schwachstellen verstecken sich oft an unerwarteten Stellen. Beim Code Review kombiniere ich automatisierte Analyse-Tools mit manueller Prüfung, um auch subtile Probleme zu finden, die Scanner übersehen.
Sicherheitslücken
Ich prüfe auf SQL Injection (direkte Datenbankmanipulation durch Benutzereingaben), XSS (Cross-Site Scripting, bei dem schadhafter Code im Browser ausgeführt wird), CSRF (Cross-Site Request Forgery, ungewollte Aktionen im Namen eingeloggter Nutzer), unsichere Dateizugriffe, fehlende Authentifizierungsprüfungen und andere OWASP-Top-10-Risiken.
Performance-Bottlenecks
Langsame Abfragen, fehlende Datenbankindizes, ineffiziente Schleifen, unnötige API-Calls und Memory Leaks identifiziere ich durch Profiling und Code-Analyse.
Code-Qualität & Wartbarkeit
Ich bewerte Lesbarkeit, Struktur, Einhaltung von Coding Standards, sinnvolle Benennung von Variablen und Funktionen sowie den Einsatz bewährter Design Patterns.
Dokumentation
Fehlende oder veraltete Dokumentation erhöht den Aufwand für zukünftige Entwickler erheblich. Ich prüfe, ob der Code verständlich kommentiert und die Architektur dokumentiert ist.
Für wen ist ein Code Review sinnvoll?
Ein Code Review macht in verschiedenen Situationen Sinn – nicht nur bei grossen Projekten.
Vor dem Launch
Bevor deine Anwendung live geht, lohnt es sich, den Code einmal gründlich prüfen zu lassen. So vermeidest du peinliche Sicherheitsvorfälle kurz nach dem Start und startest mit einem sauberen Fundament.
Bei Übernahme eines Projekts
Du übernimmst eine bestehende Anwendung von einem anderen Entwickler oder einem früheren Team? Ich verschaffe dir einen strukturierten Überblick über den Zustand des Codes, damit du weisst, womit du es zu tun hast.
Nach externem Entwickler
Du hast ein Projekt extern entwickeln lassen und möchtest sicherstellen, dass die Qualität stimmt? Ein unabhängiges Review gibt dir Gewissheit und eine objektive zweite Meinung.
AI-generierter Code (Vibe Coding)
Du baust deine Anwendung mit AI-Tools wie Claude, ChatGPT oder Cursor? Vibe Coding liefert schnell Ergebnisse – aber AI-generierter Code hat oft versteckte Sicherheitslücken, fragile Architektur und ist schwer wartbar. Ein erfahrener Entwickler prüft, was die AI übersehen hat.
Die kritischsten Sicherheitslücken in Webanwendungen
Täglich werden neue Schwachstellen entdeckt. Die folgenden Kategorien decken die häufigsten und gefährlichsten Angriffsvektoren ab, die ich bei jedem Code Review systematisch prüfe.
Die Kategorisierung orientiert sich an den OWASP Top 10 – dem international anerkannten Standard für Sicherheitsrisiken in Webanwendungen – ergänzt um weitere praxisrelevante Schwachstellen aus dem CWE-Katalog (Common Weakness Enumeration).
1. SQL Injection (SQLi)
KritischCWE-89Was passiert
Ein Angreifer schleust eigenen Datenbankcode über ein Eingabefeld ein, um die Datenbank auszulesen, zu manipulieren oder komplett zu löschen. SQL Injection ist seit über 20 Jahren eine der gefährlichsten Schwachstellen und nach wie vor weit verbreitet.
Angriffs-Szenario
Ein Login-Formular fragt den Benutzernamen ab. Der Angreifer gibt ' OR '1'='1 ein. Die Datenbank verarbeitet das als «Lass den Nutzer rein, wenn der Name stimmt ODER wenn 1 gleich 1 ist». Da 1 immer gleich 1 ist, wird der Angreifer ohne Passwort eingeloggt – und hat Zugriff auf alle Daten.
Behebung
Die Lösung sind Prepared Statements (parametrisierte Abfragen). Dabei werden Benutzereingaben strikt als Text und niemals als ausführbarer Code behandelt. Moderne Frameworks wie Laravel, Symfony oder CodeIgniter bieten das standardmässig über ihren Query Builder.
Was ich beim Code Review prüfe
Ich durchsuche den gesamten Code nach direkter String-Konkatenation in SQL-Queries, prüfe ob der Query Builder korrekt verwendet wird und identifiziere Stellen, an denen Raw Queries ohne Parameter-Binding eingesetzt werden – auch in selten genutzten Admin-Funktionen.
2. Cross-Site Scripting (XSS)
KritischCWE-79Was passiert
Schadcode (meist JavaScript) wird in eine Webseite eingeschleust und im Browser anderer Nutzer ausgeführt. Damit können Angreifer Session-Cookies stehlen, Formulardaten abfangen oder Nutzer auf gefälschte Seiten umleiten.
Angriffs-Szenario
In einem öffentlichen Kommentarfeld hinterlässt jemand den Text: <script>stealCookies()</script>. Jeder Nutzer, der diesen Beitrag aufruft, führt diesen unsichtbaren Code unbewusst im eigenen Browser aus – und der Angreifer erhält die Session-Cookies aller Besucher.
Behebung
Strikte Ausgabecodierung (Output Encoding) ist der Schlüssel. Sonderzeichen wie < und > werden vor der Anzeige in sicheren Text umgewandelt (z.B. <), damit der Browser sie nicht als Code interpretiert. In PHP geht das mit htmlspecialchars() oder der esc()-Funktion des Frameworks.
Was ich beim Code Review prüfe
Ich prüfe jede Stelle, an der Benutzereingaben oder Datenbankwerte in HTML, JavaScript oder Attribute ausgegeben werden. Besonders kritisch: Suchfelder, Kommentare, Profildaten und Admin-Backends, in denen die Ausgabe oft ungeprüft erfolgt.
3. Broken Access Control (IDOR)
KritischCWE-639Was passiert
Der Server prüft nicht, ob ein eingeloggter Benutzer das Recht hat, eine bestimmte Ressource aufzurufen. IDOR (Insecure Direct Object Reference) ist eine der häufigsten Schwachstellen – sie entsteht, wenn IDs in URLs direkt auf Datenbankeinträge verweisen, ohne Berechtigungsprüfung.
Angriffs-Szenario
Ein Nutzer klickt auf seine Rechnung und sieht die URL /download?invoice_id=5001. Er ändert die Zahl manuell auf 5000 und kann sofort die private Rechnung eines fremden Kunden herunterladen – mit Name, Adresse und Bankdaten.
Behebung
Bei jedem Zugriff braucht es eine serverseitige Autorisierungsprüfung: «Gehört die Ressource mit ID 5000 wirklich dem aktuell angemeldeten Benutzer?» Zusätzlich helfen indirekte Referenzen (UUIDs statt fortlaufende IDs), um das Erraten zu erschweren.
Was ich beim Code Review prüfe
Ich prüfe jeden Controller-Endpunkt, der eine ID aus der URL oder dem Request entgegennimmt: Wird geprüft, ob der aktuelle Benutzer auf genau diesen Datensatz zugreifen darf? Fehlt diese Prüfung, kann jeder eingeloggte Nutzer auf fremde Daten zugreifen.
4. Cross-Site Request Forgery (CSRF)
HochCWE-352Was passiert
Ein Angreifer bringt einen eingeloggten Nutzer dazu, unbeabsichtigt eine Aktion auf einer anderen Website auszuführen – zum Beispiel eine Überweisung tätigen oder ein Passwort ändern – ohne dass der Nutzer es bemerkt.
Angriffs-Szenario
Der Nutzer ist bei seiner Bank eingeloggt. Er besucht ein Forum, in dem ein Angreifer ein unsichtbares Bild eingebettet hat: <img src="bank.ch/transfer?to=angreifer&amount=1000">. Der Browser des Nutzers sendet diesen Request automatisch mit den gültigen Session-Cookies – die Überweisung wird ausgeführt.
Behebung
Der Schutz funktioniert über CSRF-Tokens: Bei jedem Formular wird ein zufälliger, einmaliger Token generiert und serverseitig geprüft. Ohne den korrekten Token wird der Request abgelehnt. Moderne Frameworks bieten das als eingebaute Middleware.
Was ich beim Code Review prüfe
Ich prüfe, ob CSRF-Schutz global aktiviert ist und ob alle zustandsverändernden Endpunkte (POST, PUT, DELETE) einen gültigen Token verlangen. Häufig finde ich CSRF-Schutz, der zwar konfiguriert aber auskommentiert oder nur teilweise aktiv ist.
5. Server-Side Request Forgery (SSRF)
HochCWE-918Was passiert
Der Angreifer zwingt den Webserver dazu, im Namen des Servers Anfragen an interne, eigentlich geschützte Systeme zu senden. So kann der Angreifer auf Dienste zugreifen, die von aussen nicht erreichbar sind.
Angriffs-Szenario
Eine Webseite bietet eine Funktion, um Profilbilder per URL hochzuladen. Der Angreifer gibt statt einer Bild-URL http://localhost:8080/admin/delete-all ein. Der Server führt die Anfrage aus, da er «sich selbst» vertraut – und löscht alle Daten.
Behebung
Am sichersten ist eine Allowlist (Erlaubnisliste) für erlaubte Ziel-URLs. Zusätzlich sollten alle Anfragen an interne IP-Adressbereiche blockiert werden (127.0.0.1, 10.0.0.0/8, 169.254.169.254). URLs müssen strikt validiert und Redirects zu internen Adressen verhindert werden.
Was ich beim Code Review prüfe
Ich identifiziere alle Stellen, an denen der Server HTTP-Anfragen basierend auf Benutzereingaben macht – z.B. URL-Previews, Webhooks, Bild-Imports oder API-Proxies. Jede dieser Stellen prüfe ich auf fehlende URL-Validierung.
6. Kryptografische Fehler
HochCWE-327Was passiert
Sensible Daten wie Passwörter, Kreditkartennummern oder persönliche Informationen werden unverschlüsselt gespeichert oder übertragen. Auch die Verwendung veralteter Verschlüsselungsalgorithmen (z.B. MD5 für Passwörter) fällt in diese Kategorie.
Angriffs-Szenario
Eine Anwendung speichert Passwörter als MD5-Hash in der Datenbank. Nach einem Datenleck kann ein Angreifer mit frei verfügbaren Rainbow-Tables innerhalb von Sekunden Millionen MD5-Hashes in Klartext-Passwörter zurückverwandeln.
Behebung
Für Passwörter gehören ausschliesslich bcrypt oder Argon2 mit ausreichendem Cost-Factor eingesetzt. Alle Daten laufen über HTTPS/TLS. Sensible Daten, die nicht benötigt werden, sollten gar nicht erst gespeichert werden. Nur aktuelle Verschlüsselungsstandards verwenden (AES-256, keine veralteten Algorithmen).
Was ich beim Code Review prüfe
Ich prüfe, welche Hash-Algorithmen für Passwörter verwendet werden, ob Secrets (API-Keys, JWT-Secrets) sicher gespeichert sind, ob HTTPS durchgängig erzwungen wird und ob sensible Daten in Logs oder Fehlermeldungen auftauchen.
7. Sicherheitsfehlkonfiguration
HochCWE-16Was passiert
Die Software ist an sich sicher, aber die Umgebung oder der Server wurden unsicher eingerichtet. Debug-Modus in Produktion, Standard-Passwörter, unnötig offene Ports oder fehlende Security-Header machen die Anwendung angreifbar.
Angriffs-Szenario
Ein Entwickler vergisst nach der Liveschaltung, den Debug-Modus zu deaktivieren. Bei einem Fehler zeigt die Website detaillierte Stack Traces mit Datenbank-Zugangsdaten, Server-Pfaden und Umgebungsvariablen an – ein Goldschatz für jeden Angreifer.
Behebung
Hier helfen automatisierte Härtungs-Checklisten für den Server. Debug-Ausgaben in Produktion deaktivieren, alle Standard-Passwörter ändern, Security-Header setzen (CSP, HSTS, X-Frame-Options) und Test-Endpunkte vor dem Go-Live entfernen.
Was ich beim Code Review prüfe
Ich prüfe Konfigurationsdateien auf Debug-Flags, Standard-Zugangsdaten, exponierte Test-Routen, fehlende Security-Header und ob Umgebungsvariablen korrekt nach Environment getrennt sind. Häufig finde ich vergessene Test-Controller, die in Produktion Datenbank-Details preisgeben.
8. Anfällige und veraltete Komponenten
MittelCWE-1104Was passiert
Die Anwendung nutzt veraltete Bibliotheken, Frameworks oder Plugins mit bekannten Sicherheitslücken (CVEs). Angreifer können diese öffentlich dokumentierten Schwachstellen mit fertigen Exploit-Tools ausnutzen.
Angriffs-Szenario
Eine WordPress-Seite nutzt ein Plugin, das seit 2 Jahren kein Update erhalten hat. In der Zwischenzeit wurde eine kritische SQL-Injection-Lücke öffentlich bekannt. Automatisierte Bots scannen das Internet nach genau dieser Plugin-Version und kompromittieren die Seite innerhalb von Stunden.
Behebung
Regelmässige Dependency-Audits sind Pflicht (composer audit, npm audit). Alle Abhängigkeiten aktuell halten, nicht mehr gepflegte Pakete entfernen. Tools wie Dependabot oder Snyk benachrichtigen automatisch bei neuen CVEs.
Was ich beim Code Review prüfe
Ich analysiere composer.json, package.json und Lock-Dateien auf veraltete Pakete und bekannte CVEs. Zusätzlich prüfe ich, ob die PHP-Version, das Framework und der Webserver aktuell sind.
9. Identifikations- und Authentifizierungsfehler
HochCWE-287Was passiert
Schwachstellen in der Anmeldung und Session-Verwaltung ermöglichen es Angreifern, Passwörter zu erraten (Brute-Force), Sessions zu übernehmen (Session Hijacking) oder Multi-Faktor-Authentifizierung zu umgehen.
Angriffs-Szenario
Eine Anwendung hat kein Rate-Limiting auf dem Login-Endpunkt. Ein Angreifer startet ein automatisiertes Script, das 10'000 Passwort-Kombinationen pro Minute durchprobiert. Ohne Schutzmassnahmen findet er innerhalb weniger Stunden das richtige Passwort.
Behebung
Die wichtigsten Massnahmen: Rate-Limiting auf Login-Endpunkte, Multi-Faktor-Authentifizierung (2FA), sichere Session-Verwaltung (httpOnly, Secure, SameSite-Cookies) und Account-Lockout nach fehlgeschlagenen Versuchen. Bewährte Auth-Bibliotheken statt Eigenentwicklungen nutzen.
Was ich beim Code Review prüfe
Ich prüfe den kompletten Auth-Flow: Login-Logik, Token-Generierung, Session-Konfiguration, Passwort-Reset, 2FA-Implementierung und Logout-Mechanismus. Häufig finde ich JWT-Tokens ohne Ablaufzeit, fehlende Session-Regenerierung nach Login oder Logout-Endpunkte, die den Token nicht wirklich invalidieren.
10. Unsicheres Design
MittelCWE-209Was passiert
Sicherheitsrisiken, die bereits bei der Planung der Software-Architektur entstehen – nicht durch Programmierfehler, sondern durch fehlende Sicherheitskonzepte. Dazu gehören fehlende Eingabevalidierung auf Architekturebene, unzureichende Trennung von Benutzerrechten oder das Fehlen von Defense-in-Depth.
Angriffs-Szenario
Ein Online-Shop erlaubt Benutzern, beliebig viele Promo-Codes gleichzeitig einzulösen, weil die Architektur keine Begrenzung vorsieht. Ein Nutzer stackt 50 Rabattcodes und erhält Produkte zu negativen Preisen – der Shop zahlt drauf.
Behebung
Sicherheitsanforderungen gehören bereits in die Planungsphase. Threat Models definieren, das Principle of Least Privilege anwenden und Business-Logik-Validierungen einbauen, die nicht nur technische sondern auch fachliche Grenzen prüfen.
Was ich beim Code Review prüfe
Ich analysiere die Gesamtarchitektur: Gibt es eine saubere Trennung zwischen öffentlichen und geschützten Bereichen? Werden Geschäftsregeln serverseitig validiert? Sind Admin-Funktionen von Benutzerfunktionen isoliert? Fehlen Rate-Limits oder Quotas für ressourcenintensive Operationen?
11. Software- und Datenintegritätsfehler
MittelCWE-502Was passiert
Das System vertraut Updates, Plugins oder externen Daten ohne Verifizierung. Unsichere Deserialisierung erlaubt Angreifern, beliebigen Code auszuführen, indem sie manipulierte Objekte einschleusen.
Angriffs-Szenario
Eine Anwendung nutzt unserialize() auf Benutzereingaben. Der Angreifer sendet ein manipuliertes PHP-Objekt, das beim Deserialisieren automatisch eine __destruct()-Methode aufruft – und damit beliebigen Code auf dem Server ausführt.
Behebung
Unsichere Deserialisierung vermeiden – JSON statt PHP-Serialisierung für externe Daten nutzen. Updates und Plugins über digitale Signaturen verifizieren. Für externe Skripte Subresource Integrity (SRI) einsetzen.
Was ich beim Code Review prüfe
Ich suche nach Verwendungen von unserialize(), eval(), shell_exec() und ähnlichen gefährlichen Funktionen. Zusätzlich prüfe ich CI/CD-Pipelines und Deployment-Prozesse auf Integritätsprüfungen.
12. Fehler bei Sicherheitsprotokollierung
MittelCWE-778Was passiert
Angriffe werden vom System nicht protokolliert oder Alarme nicht ausgelöst. Ohne Logging und Monitoring bleiben Einbrüche unbemerkt – oft über Monate oder Jahre. Im Schnitt dauert es 277 Tage, bis ein Datenleck entdeckt wird.
Angriffs-Szenario
Ein Angreifer probiert systematisch tausende Passwörter auf dem Login-Endpunkt durch. Weil keine fehlgeschlagenen Login-Versuche protokolliert werden und kein Alarm konfiguriert ist, bemerkt niemand den Angriff – bis der Angreifer eingeloggt ist und Daten exportiert hat.
Behebung
Alle sicherheitsrelevanten Ereignisse müssen protokolliert werden: fehlgeschlagene Logins, Zugriffsversuche auf geschützte Ressourcen, Änderungen an Berechtigungen. Dazu gehören Echtzeit-Alarme für verdächtige Muster (z.B. 50 fehlgeschlagene Logins in 5 Minuten).
Was ich beim Code Review prüfe
Ich prüfe, ob sicherheitsrelevante Ereignisse geloggt werden, ob Logs manipulationssicher gespeichert werden und ob es ein Alerting-System für kritische Vorfälle gibt. In vielen Projekten finde ich gar kein Security-Logging oder Logs, die nur in Entwicklungsumgebungen aktiv sind.
13. Path Traversal (Directory Traversal)
KritischCWE-22Was passiert
Ein Angreifer manipuliert Dateipfade, um auf Dateien ausserhalb des vorgesehenen Verzeichnisses zuzugreifen – etwa Konfigurationsdateien mit Datenbankpasswörtern oder die Passwort-Datei des Betriebssystems.
Angriffs-Szenario
Eine Anwendung liefert Dateien über die URL /download?file=bericht.pdf aus. Der Angreifer ändert den Parameter zu ../../../etc/passwd und erhält die Benutzer-Datei des Servers – oder schlimmer: ../.env mit allen Datenbank-Zugangsdaten.
Behebung
Dateipfade mit realpath() validieren und prüfen, ob der aufgelöste Pfad innerhalb des erlaubten Verzeichnisses liegt. Mit basename() nur den Dateinamen ohne Pfadangaben extrahieren. Benutzereingaben niemals direkt in Dateipfaden verwenden.
Was ich beim Code Review prüfe
Ich identifiziere alle Stellen, an denen Dateinamen oder Pfade aus Benutzereingaben (URL-Parameter, Formulare, Upload-Felder) stammen und prüfe, ob eine korrekte Pfad-Validierung mit realpath() und Verzeichnis-Whitelisting implementiert ist.
14. Unsicherer Datei-Upload
HochCWE-434Was passiert
Wenn eine Anwendung hochgeladene Dateien nicht ausreichend prüft, können Angreifer ausführbare Dateien (PHP-Shells, manipulierte SVGs mit JavaScript) hochladen und damit die volle Kontrolle über den Server erlangen.
Angriffs-Szenario
Ein Angreifer benennt eine PHP-Datei in bild.jpg.php um und lädt sie über ein Avatar-Upload-Formular hoch. Der Server speichert die Datei im öffentlichen Verzeichnis. Der Angreifer ruft /uploads/bild.jpg.php auf – und hat eine Remote Shell auf dem Server.
Behebung
Dateien serverseitig auf MIME-Type und Magic Bytes prüfen (nicht nur die Dateiendung). Uploads ausserhalb des öffentlichen Verzeichnisses speichern oder in einem Verzeichnis ohne Ausführungsrechte. Dateien beim Speichern umbenennen. Bei SVGs: strikte Sanitisierung gegen XSS-Payloads.
Was ich beim Code Review prüfe
Ich prüfe jeden Upload-Mechanismus: Werden Dateitypen serverseitig validiert (nicht nur clientseitig)? Landen Uploads in einem ausführbaren Verzeichnis? Werden SVG-Dateien auf eingebettetes JavaScript geprüft? Werden Dateinamen sanitisiert?
Offizielle Quellen und Industriestandards
Für tiefergehende Recherche zu spezifischen Schwachstellen empfehle ich diese anerkannten Quellen:
Häufige Fragen zum Code Review
Was brauchst du für den Code Review?
Wie lange dauert ein Code Review?
Ist mein Code bei dir sicher?
Welche Programmiersprachen kannst du reviewen?
Kannst du die gefundenen Probleme auch beheben?
Reviewst du auch AI-generierten Code (Vibe Coding)?
Code Review anfragen
Lass deinen Code von einem erfahrenen Entwickler prüfen. Ich melde mich innerhalb von 24 Stunden bei dir.
Jetzt Kontakt aufnehmenPassende Blog-Beiträge
Hostpoint PHP-Umstellung am 24. Juni 2026: Was Sie jetzt wissen müssen
Hostpoint aktualisiert am 24. Juni 2026 automatisch alle PHP-Versionen: 8.1 → 8.2 und 8.4 → 8.5. Was das bedeutet, we...
Metanet PHP Extended Support: Was tun, wenn Sie diese E-Mail erhalten haben?
Metanet informiert Kunden über veraltete PHP-Versionen und kündigt ab 21.07.2026 kostenpflichtigen PHP Extended Suppo...
PHP-Sicherheit 2026: So schützen Schweizer KMU ihre Webanwendungen
Entdecke die wichtigsten Schritte, um deine PHP-Webanwendungen sicher zu halten und wie ich dir dabei helfen kann.