Eén notitie per lab: wat de check meet, hoe je de cijfers leest en wat je eerst fixt. Geschreven vanuit opdrachten, niet vanuit leverancierspagina's. Bijgewerkt als de labs veranderen.
Notitie 01Web
Security headers: wat het cijfer echt meet
Het cijfer van MDN HTTP Observatory is geen vulnerability scan. Het leest de response headers van je voordeur en beoordeelt of de browser wordt verteld zich veilig te gedragen: HSTS dwingt HTTPS af, Content-Security-Policy beperkt waar scripts vandaan mogen komen, X-Frame-Options en de frame-ancestors-directive stoppen clickjacking, en de referrer- en cookie-flags beperken wat naar derden lekt.
Een B of hoger betekent dat de basis staat. Een D of F betekent bijna altijd een van twee dingen: helemaal geen Content-Security-Policy, of HTTPS dat nog te downgraden is omdat HSTS ontbreekt. Beide zijn configuratie, geen code, en beide fix je in een middag in de webserver of het CDN.
Wat het cijfer je niet kan vertellen: of de applicatie achter de headers veilig is, of de policy zo ruim is dat ze niets beschermt, en of interne hostnames dezelfde headers dragen. Daar begint een review.
Draai het lab: Security headers grade →
Notitie 02E-mail · DNS
Zes DNS-records bepalen of je mail te vervalsen is
Je domein spoofen kost één regel in een mailclient, tenzij DNS anders zegt. SPF somt op wie mag versturen, DMARC vertelt ontvangers wat ze met falende mail doen, DKIM ondertekent elk bericht, MX bewijst dat het domein überhaupt ontvangt, DNSSEC ondertekent de antwoorden zodat ze onderweg niet te vervangen zijn, en CAA beperkt welke certificaatautoriteiten voor de naam mogen uitgeven.
De veruit meest voorkomende bevinding is DMARC met p=none. Die policy monitort alleen; ze laat vervalste mail door en rapporteert het hooguit. De tweede is SPF die eindigt op ~all, een soft fail die de meeste ontvangers als schouderophalen lezen. De fix is p=quarantine of p=reject zodra de rapporten laten zien dat elke legitieme verzender gedekt is, en -all op SPF.
De check zoekt naar veertien gangbare DKIM-selectornamen, dus een eigen selector verschijnt als ontbrekend terwijl het ondertekenen wél werkt. Lees de DKIM-regel als een aansporing om te verifiëren, niet als een oordeel.
Draai het lab: Email and DNS posture →
Notitie 03Merk
Look-alike-domeinen: welke ertoe doen
De finder genereert tot 140 varianten van je naam uit de patronen die aanvallers echt gebruiken: een weggevallen letter, een dubbele, twee omgewisseld, een toetsenbord-buur, een koppelteken, een homoglyph zoals rn voor m, een achtervoegsel als -login, en dezelfde naam onder een ander topleveldomein. Daarna resolvet hij elke variant om te zien welke bestaan.
Een domein dat resolvet is geen bewijs van misbruik. Sommige zijn geparkeerd door speculanten, andere defensief geregistreerd door het merk zelf. Pak eerst de varianten aan die ook een MX-record hebben: die kunnen mail ontvangen, en dat is precies wat een phishingcampagne nodig heeft om geloofwaardig te zijn.
Praktische volgorde: registreer zelf de drie of vier goedkoopste varianten met hoog risico, zet de rest op een monitoringlijst, en zorg dat DMARC op het echte domein op reject staat zodat de look-alikes jouw naam niet in de afzenderregel kunnen lenen.
Draai het lab: Typosquat finder →
Notitie 04Credentials
Waarom een gelekt wachtwoord een identity-probleem is, geen wachtwoordprobleem
De check hasht het wachtwoord lokaal met SHA-1 en stuurt alleen de eerste vijf tekens van die hash naar Have I Been Pwned. De dienst geeft elke hash met dat prefix terug, honderden ongerelateerde, en de browser zoekt naar een match. Het wachtwoord zelf verlaat de pagina nooit.
Een aantal boven nul betekent dat precies dit wachtwoord in minstens één publiek datalek voorkomt. Aanvallers voeren die datasets de klok rond aan credential-stuffing-tools. Is het wachtwoord nog ergens geldig, dan staat dat account één script verwijderd van een overname, met of zonder MFA.
De fix is nooit één wachtwoord. Het is een manager die unieke wachtwoorden genereert, MFA die niet te herhalen is, en een directory-beleid dat gelekte wachtwoorden blokkeert op het moment dat ze worden ingesteld. Dat laatste is wat een identity-review verifieert.
Draai het lab: Pwned password check →
Notitie 05Blockchain
Een contract lezen zonder de README te vertrouwen
De X-ray leest de bytecode van een mainnet-adres rechtstreeks van publieke nodes en haalt de function selectors eruit, de proxy-slots volgens ERC-1967 en oudere Zeppelin-indelingen, de owner en de paused-status, en de gevaarlijke opcodes: SELFDESTRUCT, DELEGATECALL en CREATE2. Sourcify vertelt of de gepubliceerde broncode overeenkomt met wat er is uitgerold.
De risicosignalen zijn precies dat: signalen. Een upgradeable proxy betekent dat de logica onder je voeten kan veranderen, een owner-sleutel betekent dat één private key de bevoorrechte functies beheert, een mint-functie betekent dat de supply kan groeien. Elk daarvan is normaal voor sommige protocollen en fataal voor andere; de vraag is wie de sleutel heeft en hoe dat is geregeld.
Ongeverifieerde broncode is het ene signaal dat een transactie meteen moet stoppen. Als de uitgerolde code niet aan leesbare broncode te koppelen is, weet niemand buiten de deployer wat ze doet.
Draai het lab: Contract X-ray →
Notitie 06AI · tekst
Tekst die jou het ene vertelt en het model het andere
Documenten, e-mails en webpagina's kunnen instructies bevatten die een mens nooit ziet: Unicode-tag-tekens die als niets renderen, zero-width joiners, bidirectionele overrides die omdraaien wat het oog leest, en homoglyphs uit andere schriften. Een LLM leest het allemaal. De scanner maakt die tekens zichtbaar en toetst de genormaliseerde tekst daarna aan de OWASP LLM01-injectiefamilies, tool-poisoning-markers en gangbare secret-formaten.
Een hit is een reden om te kijken, geen oordeel: legitieme tekst bevat soms een zero-width joiner uit een kopieer-plakactie. Twee of meer bevindingen in één document, of welk exfiltratiepatroon dan ook dat naar een URL wijst, is een ander verhaal.
Alles wat een assistent voedt, van een supportinbox tot een cv-pipeline, hoort door zo'n check te gaan voordat het model het ziet. Die control is goedkoop; het ontbreken ervan is een bevinding.
Draai het lab: Hidden-instruction scanner →
Notitie 07AI · agents
De toolbeschrijving is onderdeel van de prompt
Zodra een agent verbinding maakt met een MCP-server, wordt elke toolbeschrijving tekst die het model leest en opvolgt. Een vergiftigde beschrijving kan het model opdragen een private key te lezen voordat het twee getallen optelt, alle mail via één tool te sturen, of daarover te zwijgen. De scanner controleert namen, beschrijvingen en schema's op die markers, op verwijzingen naar zustertools en op uitgaande URL's.
Het voorbeeldmanifest op de labs-pagina toont de vorm: een onschuldige add-tool met een <IMPORTANT>-blok dat om ~/.ssh/id_rsa vraagt, en een send_email-tool die voorrang claimt op de agenda. Geen van beide zou opvallen in een chattranscript.
Behandel MCP-servers als browserextensies met shell-toegang. Pin versies, vergelijk beschrijvingen bij elke update, en draai onvertrouwde servers zonder bestands- of netwerktoegang. Een agent-review controleert precies die drie dingen.
Draai het lab: MCP tool-poisoning scanner →