Hoe deze controle werkt
Scanaris haalt alle HTML-commentaren uit je hoofdpagina, dus alles tussen <!-- en -->, en zoekt daarin naar zes geheimpatronen. Vier zijn herkenbare sleutelformaten: geheime Stripe-sleutels (sk_live_ gevolgd door 20 of meer tekens), AWS-toegangssleutels (AKIA en 16 tekens), Google API-sleutels (AIza en 35 tekens) en private-key-headers (-----BEGIN PRIVATE KEY----- en de RSA- of EC-varianten). De andere twee zijn expliciete toewijzingen: password, passwd of pwd gevolgd door een waarde van minstens 6 tekens, en api_key, secret, token of bearer gevolgd door een waarde van minstens 16. Komt er een overeen, dan opent hij een bevinding met hoge ernst die het type gevonden geheim noemt, nooit de waarde. De patronen zijn bewust streng: een commentaar dat zegt "hier komt de token" zonder waarde erachter wordt niet gemeld.
Waarom dit belangrijk is
HTML-commentaren zijn onzichtbaar op de pagina, maar zichtbaar in de broncode, en iedereen ziet de broncode met Ctrl+U of een curl. Er is geen praktisch verschil tussen een sleutel in een commentaar zetten en hem op een forum plaatsen. Een geheime Stripe-sleutel laat iemand afschrijvingen en terugbetalingen aanmaken; een AWS-sleutel, je account en je factuur gebruiken; een databasewachtwoord, alles lezen. En geautomatiseerde geheimenjagers doorzoeken het hele web naar precies deze voorvoegsels, dus de tijd tussen het publiceren van de sleutel en het misbruik wordt in minuten gemeten.
Waarom het gebeurt
Iemand laat tijdens de ontwikkeling een notitie voor zichzelf achter ("<!-- gebruiker admin / password Tijdelijk2024 -->"), zet een configuratieblok "om te testen" in commentaar in plaats van het te verwijderen, of plakt een integratievoorbeeld met de echte sleutel. WordPress-templates en handgemaakte statische sites zijn het gevoeligst, omdat hun commentaren ongewijzigd in de browser aankomen. In moderne frameworks gebeurt het minder, maar het gebeurt: een commentaar in een statische .html in de openbare map of in een component dat niet wordt gecompileerd.
Hoe je het oplost
- Roteer eerst het geheim. Ga ervan uit dat het al gelezen is. Genereer een nieuwe bij de aanbieder, wijzig hem op je server en trek de oude in. Verwijder daarna het commentaar; niet andersom.
- Doorzoek het project vóór het deployen, niet alleen de hoofdpagina:
grep -rnE "sk_live_|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|BEGIN (RSA |EC )?PRIVATE KEY|(password|api_key|secret|token)\s*[:=]" --include=*.html --include=*.vue --include=*.php --include=*.hbs .- Verwijder commentaren in productie. Vue en Nuxt halen ze weg bij het compileren; in Next.js bereiken JSX-commentaren de HTML nooit. Voor statische HTML of WordPress verwijdert een minifier (
html-minifier-tersermetremoveComments) of je optimalisatieplugin ze. In PHP gebruik je PHP-commentaar (<?php // ... ?>), dat de server nooit verlaat. - Inloggegevens horen in omgevingsvariabelen, nooit in bestanden die geserveerd worden. En voeg een geheimdetector toe aan de repository (
gitleaksof GitHub secret scanning) zodat het er niet opnieuw in komt.
Controleer of het opgelost is
curl -s https://jouwdomein.nl | tr -d '\n' | grep -oE '<!--.{0,200}' | grep -iE "sk_live_|AKIA|AIza|PRIVATE KEY|password|api_key|secret|token|bearer"Er mag niets uitkomen. Ideaal is dat het eerste deel, zonder het laatste filter, ook geen commentaren teruggeeft: in productie dienen ze nergens toe.
Veelgestelde vragen
Het is een testsleutel, geen productiesleutel.
De patronen maken dat onderscheid: Stripes sk_test_ wordt niet gemeld, sk_live_ wel. Als de bevinding verscheen, past het formaat bij een echte sleutel of bij een expliciete wachtwoordtoewijzing. Is het echt een plaatshouder, vervang hem dan door iets dat niet op een inloggegeven lijkt, zoals VERVANGEN.
Worden JavaScript-commentaren ook gecontroleerd?
Deze controle kijkt alleen naar de HTML. Sleutels in JavaScript-bundels, met of zonder commentaar, worden gezocht door geheimen in JavaScript, en verwijzingen naar interne hosts door interne verwijzingen. Wat er nog meer per ongeluk lekt, staat in geheimen die je app in de browser lekt.
Tellen de voorwaardelijke commentaren van Internet Explorer mee?
Het zijn HTML-commentaren en ze worden op dezelfde manier geanalyseerd, maar ze bevatten geen geheimen en worden niet gemeld. Toch zijn ze in 2026 ballast: geen enkele ondersteunde browser interpreteert ze.