Gidsen: PHP- en serverbeveiliging
Vakartikelen voor beheerders en ontwikkelaars: webshells herkennen, php.ini beveiligen, logs analyseren, veilig programmeren.
PHP2Shell-tijdlijn: chronologie van 17 tot 25 oktober 2026
Alle gedocumenteerde data rond PHP2Shell in één overzicht, van de eerste waargenomen aanvalspoging tot de stand van 25-10-2026, en wat daaruit volgt voor uw controle.
Lees verder →02Bevestiging van de PHP-update door de hoster: zo vraagt u naar de patchstatus
Een getoonde PHP-versie bewijst na PHP2Shell weinig. Met dit sjabloon vraagt u uw hoster om een bevestiging die u kunt documenteren.
Lees verder →03Webshell herkennen en verwijderen
Hoe u achterdeurtjes op PHP-webservers opspoort zonder sporen te vernietigen, en waarom verwijderen alleen zelden volstaat.
Lees verder →04WordPress-backdoor vinden: achterdeurtjes systematisch opsporen
Waar achterdeurtjes zich in WordPress meestal verbergen en hoe beheerders ze met WP-CLI en enkele opdrachten systematisch opsporen.
Lees verder →05php.ini veilig configureren
Welke instellingen in de php.ini het aanvalsoppervlak verkleinen, hoe u ze tegen overschrijven beschermt en wat na PHP2Shell extra geldt.
Lees verder →06PHP disable_functions correct inzetten
Met disable_functions blokkeert u riskante PHP-functies. Zo stelt u de lijst passend bij uw toepassing vast zonder de website plat te leggen.
Lees verder →07open_basedir en isolatie per website
Hoe u met open_basedir, eigen systeemgebruikers en gescheiden PHP-FPM-pools voorkomt dat een inbraak op één website alle andere op de server treft.
Lees verder →08Bestandsrechten op de webserver
Waarom de webserver zijn eigen code niet mag wijzigen, welke rechten voor bestanden en mappen zinvol zijn en hoe u de huidige toestand snel controleert.
Lees verder →09composer audit: afhankelijkheden op kwetsbaarheden controleren
Hoe ontwikkelaars met composer audit bekende beveiligingslekken in bibliotheken vinden, de controle automatiseren en typische fouten in de deployment vermijden.
Lees verder →10PHP end of life: risico's van verouderde versies
Wat het einde van de ondersteuning van een PHP-versie betekent, welke takken na PHP2Shell nog officiële patches krijgen en hoe u de migratie plannbaar maakt.
Lees verder →11SQL-injectie in PHP voorkomen
Hoe ontwikkelaars SQL-injectie in PHP-toepassingen met prepared statements, whitelists en minimale databaserechten betrouwbaar uitsluiten.
Lees verder →12XSS in PHP voorkomen: cross-site scripting veilig afweren
Hoe ontwikkelaars cross-site scripting in PHP-toepassingen voorkomen: contextgerichte codering, auto-escaping in templates, opschoning van HTML en een Content Security Policy.
Lees verder →13Bestandsuploads in PHP veilig opzetten: PHP-uploadbeveiliging
Uploadformulieren zijn een veelgebruikte weg voor webshells. Zo controleert u bestandstypen goed, slaat u bestanden veilig op en voorkomt u dat de server geüploade scripts uitvoert.
Lees verder →14Sessies in PHP beveiligen: PHP-sessiebeveiliging in de praktijk
Sessies houden gebruikers aangemeld en zijn daarmee een aantrekkelijk doelwit. Zo configureert u cookies, sessie-ID's en opslaglocaties veilig en voert u de PHP2Shell-aanwijzing over upload progress door.
Lees verder →15Onveilige deserialisatie in PHP: unserialize en beveiliging
unserialize() met vreemde gegevens kan in het slechtste geval tot code-uitvoering leiden. Zo vervangt u het door JSON, beperkt u het waar het moet blijven en vindt u riskante plekken in de code.
Lees verder →16Local file inclusion in PHP voorkomen: LFI en RFI
Als include of require paden uit het verzoek overnemen, kunnen aanvallers vreemde bestanden laden. Zo bouwt u paginakeuze en sjablonen veilig en beveiligt u de server aanvullend.
Lees verder →17Beheerlogins beschermen tegen brute force: brute-force-bescherming voor elke login
Geautomatiseerde wachtwoordpogingen treffen elke bereikbare aanmeldpagina. Zo remt u aanvallers met rate limiting en Fail2ban, beschermt u accounts met een tweede factor en slaat u wachtwoorden juist op.
Lees verder →18DDoS of hackeraanval? Aanvallen juist inschatten
Trage website, hoge belasting, vreemde bestanden: of er een DDoS of een inbraak achter zit, bepaalt de juiste reactie. Zo schat u de situatie in met enkele controles.
Lees verder →19Webserverlogs na een aanval analyseren: het toegangslog goed lezen
Logbestanden zijn na een aanval vaak het belangrijkste spoor. Zo zet u toegangs-, fout- en PHP-logs goed veilig, vindt u opvallende verzoeken en vermijdt u typische fouten bij de analyse.
Lees verder →20Tweefactorauthenticatie voor beheertoegangen instellen
Een gestolen wachtwoord mag niet volstaan om uw server of webshop over te nemen. Zo kiest u de passende methode, beveiligt u alle beheertoegangen en plant u noodtoegangen.
Lees verder →21Back-upstrategie voor servers: back-ups volgens de 3-2-1-regel
Een back-up helpt alleen als hij een aanval overleeft en zich laat terugzetten. Zo voert u de 3-2-1-regel voor webservers in en plant u bewaartermijn en tests goed.
Lees verder →22Security headers voor websites: beveiligingsheaders correct instellen
Beveiligingsheaders instrueren de browser om uw bezoekers beter te beschermen. Zo stelt u de belangrijkste headers in Nginx en Apache in, voert u een Content Security Policy stapsgewijs in en controleert u het resultaat.
Lees verder →23Google-waarschuwing „Deze website is gehackt” verwijderen
Een hackwaarschuwing in de zoekresultaten kost bezoekers en vertrouwen. Zo ruimt u de website grondig op, vindt u verborgen spampagina's en vraagt u de herbeoordeling aan in de Search Console.
Lees verder →24Checklist na een hack: 20 punten voor de nazorg
Na een aanval telt de juiste volgorde. Deze checklist leidt in 20 punten door indamming, bewijsborging, opruiming, nieuwe toegangen, plichten en de gedocumenteerde afsluiting.
Lees verder →Elk uur telt. Schrijf ons nu.
Beschrijf kort het systeem, de PHP-versie en wat u opmerkt. Wij nemen contact op, brengen de situatie in kaart en werken op afstand tot het incident is afgerond en gedocumenteerd.