Werk aan je veiligheid op je site

Als startende programmeur moet je met veel zaken rekening houden. Een aspect om rekening mee te houden vanaf de start van je site is de veiligheid. Veiligheid in de zin van je webserver tot en met je eigen pagina’s. Voor je webserver gaan we er vanuit dat je een professionele webserver gebruikt. Deze zal de server en alles daarom heen veilig regelen voor je. Dat is werk voor de expert en moet je lekker aan hen overlaten. Jij kan je richten op wat jij programmeert. In dit artikel gaan we in op een aantal aspecten om zelf je niveau van veiligheid op te hogen. Het is niet allesomvattend en zal zeker niet compleet zijn, maar zie het als een goede start om je site veiligheid te onderhouden en verbeteren.

config.php

Ga je bouwen aan een site met een database, dan wil je graag je gegevens voor het benaderen van je database veilig zetten. Dit kan op meerdere manieren en hangt zeker af van de configuratie van je webserver. Check daarom ook altijd de kennisbank van je hosting partij. Los daarvan, je kunt zelf ook zaken goed inregelen. Een goed doordachte mappenstructuur helpt je al op weg:

/public_html/formulier/
β”œβ”€β”€ includes/
β”‚ └── config.php
β”œβ”€β”€ send.php
└── index.php

In dit geval stop je je bestanden die veel informatie bevatten zoals config.php in een aparte map. De kunst is dat derden deze map niet kunnen openen. Daarmee zorg je ervoor dat kwaadwillende bezoekers het moeilijk hebben deze informatie te achterhalen. Dit betekent dat je in je config.php een paar extra code regels gaat toevoegen om te zorgen dat dit bestand niet benaderbaar is. Voorbeeld:

<?php
// Stop directe toegang
if (basename($_SERVER['PHP_SELF']) == basename(__FILE__)) {
http_response_code(403);
exit('Toegang geweigerd.');
}
// SMTP-configuratie of database toegang, wat je wilt
define('SMTP_HOST', 'smtp.mijnhosting.nl');
define('SMTP_PORT', );
define('SMTP_USER', '…');
define('SMTP_PASS', '…');
define('MAIL_TO', '…');

DIt bestand is voor derden niet bereikbaar. Probeert een bezoeker erop te komen, dan stuurt http_response_code(403) een melding de lucht in. Je eigen bestanden van je site moeten wel dit bestand kunnen benaderen. Om dit veilig te stellen, voeg je aan ieder bestand dat gebruik maakt van de config.php de volgende code toe:

require_once(__DIR__ . '/includes/config.php');

βœ… Nu kan iemand niet zomaar via de browser includes/config.php laden, want het script zelf blokkeert dat.

Bestanden op de server verplaatsen

Als het mogelijk is op je server, kun je de config.php bestanden ook buiten de web directory plaatsen. Dat betekent dat de server je een map biedt die jij via FTP wel kan benaderen en voor je webpagina’s wel bereikbaar is, maar voor derden nooit aan te roepen is. De server blokkeert namelijk simpelweg de toegang tot deze map al voor jou.

/home/gebruikersnaam/
/public_html/formulier/index.php
/config.php ← hier dus

De map public_html is de map die voor bezoekers van je site aan te roepen is. Daarbuiten komt een bezoeker niet mits de server uiteraard goed is ingericht. In je bestanden die gebruik moeten maken van de gegevens in config.php zet je de volgende code:

require_once('/home/gebruikersnaam/config.php');

πŸ”’ Voordeel: nooit publiek bereikbaar.
⚠️ Let op: vereist dat je via FTP of file manager buiten public_html mag plaatsen (niet altijd mogelijk bij shared hosting).

Beveilig gevoelige bestanden

Als website bouwer wil je voorkomen dat derden je site kunnen misbruiken om gegevens in te laden die je niet wilt. Dit is een groot en belangrijk onderwerp. Onder andere input beveiliging van alle formulieren is onderdeel van dit beleid en zorgen dat verwerkingsbestanden niet iets doen als een verkeerde pagina de info aanlevert. Dit laatste punt gaan we nu uitdiepen voor je. Dan heb je alvast een start van het hoe en waarom.

CSRF ofwel Cross-Site Request Forgery kan een lastig probleem vormen voor webbouwers. Je bouwt onbewust een mooi contact formulier en zet dit op je site. Een hacker komt op je site en ziet een gat in je beveiliging en bouwt zelf een formulier dat jouw site misbruikt. Denk aan bestelformulieren waardoor je het idee hebt dat alles goed is, maar uiteindelijk iemand anders je geld ontvangt en jij niet. Kan lastig zijn! Dit probleem is simpel op te lossen. We gaan een token toevoegen aan ieder formulier om te checken of de input daar vandaan komt waar je het van verwacht. Hoe doen we dat:

🧱 1. Genereer de token bij het laden van het formulier:

session_start();
if (empty($_SESSION['csrf_token'])) {
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

🧱 2. In je formulier zet je dan een verborgen veld:

<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>

πŸ§ͺ 3. Controleer de token bij het verwerken (dus bijvoorbeeld op verwerk.php) :

session_start();
if (!isset($_POST['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
http_response_code(403);
exit('Ongeldige CSRF-token. Actie geblokkeerd.');
}

βœ… Alleen formulieren die vanaf jouw site geladen zijn bevatten het juiste token. Een andere website kan dit token niet raden, dus mislukt de aanval.

Let op: dit is een voorbeeld om mee te starten en na te gaan denken over een vorm van beveiliging. Er zijn nog veel meer smaken om de veiligheid op te voeren. We raden je aan zelf een protocol vast te leggen voor iedere pagina die je bouwt om te checken of het veilig is en of er meer behoefte aan veiligheid bestaat.