SSRF Preventie

Geen Achterdeur Via Je Eigen Server

Veilige webontwikkeling draait niet om extra frictie, maar om betere defaults in ontwerp, code en releaseflow.

Bij SSRF Preventie zit de meeste winst in veilige defaults die in elke release automatisch worden afgedwongen.

Dat maakt security minder een losse controle achteraf en meer een standaardkwaliteit van je product.

Directe maatregelen (15 minuten)

• Implementeer eerst invoervalidatie, veilige output-encoding en parameterized queries.
• Harden authenticatie, sessiebeheer en security headers als baseline.
• Borg maatregelen in CI/CD met tests, linting en release-gates.

Waarom dit telt

De kern van SSRF Preventie is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Verdediging: hoe je voorkomt dat je server een proxy wordt

Allowlists, geen blocklists

De eerste en belangrijkste regel: gebruik een allowlist, geen blocklist. Definieer welke domeinen en IP-ranges de server mag benaderen, en blokkeer al het andere.

Een blocklist die “127.0.0.1” en “169.254.169.254” blokkeert, is als een dam met twee vingers in de gaten terwijl de rest van de dam uit kaas bestaat. Je kunt niet alle mogelijke bypass-varianten blocklisten. Er zijn er te veel, en er worden er steeds meer uitgevonden.

Een allowlist draait de logica om: alleen expliciet toegestane bestemmingen zijn bereikbaar. Alles wat niet op de lijst staat, wordt geblokkeerd. Simpel, effectief, en bestand tegen creatieve bypass-technieken.

Valideer na DNS-resolutie

Controleer niet alleen de URL die de gebruiker opgeeft, maar ook het IP-adres waarnaar het domein resolvet. En doe die controle direct voor het request, niet eerder. Dit voorkomt DNS-rebinding-aanvallen.

import socket
import ipaddress

def is_safe_url(url):
    hostname = extract_hostname(url)
    ip = socket.gethostbyname(hostname)
    addr = ipaddress.ip_address(ip)

    # Blokkeer private en reserved ranges
    if addr.is_private or addr.is_reserved or addr.is_loopback:
        return False

    # Blokkeer link-local (169.254.x.x)
    if addr.is_link_local:
        return False

    return True

Schakel onnodige protocollen uit

Als je server alleen HTTP en HTTPS nodig heeft, blokkeer dan alle andere protocollen: file://, gopher://, dict://, ftp://. De meeste HTTP- bibliotheken ondersteunen deze protocollen standaard, maar je kunt ze uitschakelen via configuratie.

IMDSv2 afdwingen op AWS

Als je op AWS draait, schakel IMDSv1 uit en gebruik uitsluitend IMDSv2:

aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

--http-tokens required betekent dat de metadata-service alleen reageert op requests met een geldig token. Dat token is alleen verkrijgbaar via een PUT-request met een custom header – iets wat de meeste SSRF-kwetsbaarheden niet kunnen.

Egress filtering

Beperk uitgaand verkeer van je servers. Als je webserver alleen hoeft te praten met je database en een paar externe API’s, configureer dan de firewall zo dat alleen die verbindingen zijn toegestaan. Al het andere uitgaande verkeer wordt geblokkeerd.

Dit voorkomt niet dat een SSRF-kwetsbaarheid wordt misbruikt voor interne verkenning, maar het beperkt de impact drastisch. De server kan geen credentials naar een aanvaller sturen als uitgaand verkeer naar willekeurige IP’s geblokkeerd is.

Aparte netwerksegmenten

De metadata-service, de database, de cache-server, de admin-interface – ze horen allemaal niet op hetzelfde netwerksegment als de webserver. Segmenteer je netwerk zodat de webserver alleen kan bereiken wat hij strikt nodig heeft.

Dit is het netwerkequivalent van het principe van least privilege: geef elke component alleen toegang tot wat het nodig heeft en niets meer. Het klinkt vanzelfsprekend. Het gebeurt bijna nooit.

Het eerlijke gesprek over SSRF in 2026

Hier is het ding over SSRF dat niemand hardop zegt: het is een architectuurprobleem dat wordt behandeld als een applicatieprobleem.

De reden dat SSRF werkt, is niet dat ontwikkelaars dom zijn. Het is dat de architectuur van cloud computing – en van interne netwerken in het algemeen – is gebouwd op de aanname dat interne verzoeken vertrouwd zijn. De metadata- service op 169.254.169.254 heeft geen authenticatie. Redis op het interne netwerk heeft geen wachtwoord. De admin-interface is bereikbaar zonder VPN.

Elke keer dat een beveiligingsincident via SSRF plaatsvindt, wordt de schuld gelegd bij de ontwikkelaar die de URL niet valideerde. Maar de ontwikkelaar werkt in een omgeving waar “intern” gelijkstaat aan “veilig”, waar de metadata- service credentials uitdeelt aan iedereen die ernaar vraagt, en waar netwerksegmentatie iets is waar men “nog aan toekomt”.

SSRF is niet het probleem. SSRF is het symptoom. Het echte probleem is dat we in 2026 nog steeds systemen bouwen die vertrouwen op de vraag “waar komt dit request vandaan?” in plaats van op de vraag “wie stuurt dit request en mag die persoon dit doen?”

Totdat we die fundamentele verschuiving maken – van netwerk-gebaseerd vertrouwen naar identiteit-gebaseerd vertrouwen, van implicit trust naar zero trust – zal SSRF blijven bestaan. En zullen penetratietesters als een soort digitale huisartsen steeds hetzelfde recept uitschrijven: “U moet echt iets aan die bloeddruk doen.” “Ja dokter, ik kom er nog wel aan toe.”

Het verschil is dat als je je bloeddruk negeert, je zelf de consequenties draagt. Als je SSRF negeert, draagt je klant de consequenties. En je klant weet niet eens dat de metadata-service geen authenticatie heeft. Die vertrouwt erop dat jij dat geregeld hebt.

De server doet gewoon wat je vraagt. Misschien is het tijd dat we de server leren om nee te zeggen.

Samenvatting

SSRF is de kwetsbaarheid die laat zien hoe fragiel het concept van een “vertrouwd intern netwerk” is. Het transformeert een webserver van een gecontroleerd toegangspunt in een springplank naar alles wat intern bereikbaar is. Cloud metadata, interne services, databases, caches – alles is een URL verwijderd.

De verdediging vereist meer dan een URL-filter. Het vereist architecturale veranderingen: allowlists in plaats van blocklists, IMDSv2 in plaats van IMDSv1, netwerksegmentatie, egress filtering, en het verlaten van de aanname dat intern verkeer vertrouwd is.

Referenties