Website selbst prüfen

Der externe Website-Scanner sieht nur, was eine Website nach außen zeigt. Mit diesen nur lesenden Prüfungen kontrollierst du zusätzlich Server, Logs, PHP, Datenbank, WordPress und Browser. Die Befehle ändern nichts an deiner Konfiguration und löschen keine Daten.

Wichtig: Ein Treffer ist zunächst ein Prüfhinweis, kein Beweis für unnötige Speicherung. REMOTE_ADDR kann beispielsweise nur gelesen werden, ohne jemals dauerhaft gespeichert zu werden.

Komplettcheck (Linux/VPS)

Dieses Skript erkennt typische Webserver, sucht nur in Konfigurationsdateien und prüft Header. Es liest keine Datenbankinhalte und gibt keine gespeicherten Besucher-IP-Adressen aus.

#!/bin/sh
echo "Wir speichern nicht! – Selbsttest"
echo
command -v apache2 >/dev/null && echo "[i] Apache erkannt"
command -v nginx >/dev/null && echo "[i] nginx erkannt"
command -v caddy >/dev/null && echo "[i] Caddy erkannt"
command -v php >/dev/null && echo "[i] PHP erkannt"

echo
echo "== Logging-Konfiguration =="
grep -RniE 'CustomLog|ErrorLog|access_log|error_log|log[[:space:]]*\{' /etc/apache2 /etc/nginx /etc/caddy 2>/dev/null | head -80

echo
echo "== Weitergereichte Client-IP =="
grep -RniE 'RemoteIPHeader|X-Forwarded-For|X-Real-IP|CF-Connecting-IP|True-Client-IP|trusted_proxies' /etc/apache2 /etc/nginx /etc/caddy 2>/dev/null | head -80

echo
echo "== Response-Header =="
curl -sSI https://DEINE-DOMAIN.TLD | grep -iE '^(set-cookie|location|server|via|cf-|x-)'

echo
echo "[?] Provider-, WAF- und DDoS-Logs können lokal unvollständig oder unsichtbar sein."

Apache

apache2ctl -S
grep -RniE 'CustomLog|ErrorLog|LogFormat|RemoteIPHeader|RemoteIPTrustedProxy|RemoteIPInternalProxy' /etc/apache2 2>/dev/null

→ Apache ohne unnötige IP-Logs

nginx

nginx -T 2>&1 | grep -nEi 'access_log|error_log|log_format|real_ip|set_real_ip_from|proxy_set_header.*(X-Real-IP|X-Forwarded-For)'

→ nginx ohne unnötige IP-Logs

Caddy

grep -RniE 'log|trusted_proxies|client_ip_headers|X-Forwarded-For|X-Real-IP' /etc/caddy 2>/dev/null

→ Caddy-Logs reduzieren · → Trusted Proxies prüfen

PHP / eigene Anwendung

Im Projektverzeichnis ausführen. Der Befehl sucht Quellcode, der IP-, Cookie-, Session- oder Browsermerkmale verwendet:

grep -RniE --include='*.php' --exclude-dir=vendor --exclude-dir=cache --exclude-dir=backups '\$_SERVER\[["'"']REMOTE_ADDR|HTTP_X_FORWARDED_FOR|HTTP_CF_CONNECTING_IP|setcookie\(|session_start\(|HTTP_USER_AGENT' .

Danach jeden Treffer einzeln prüfen: Wird der Wert nur verwendet oder tatsächlich in Datei/Datenbank geschrieben?

MySQL / MariaDB – nur Schema prüfen

Diese Abfrage liest ausschließlich Spaltennamen und Tabellennamen aus information_schema, keine Besucherdaten:

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE

FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND (
    COLUMN_NAME REGEXP '(^|_)(ip|ip_address|remote_addr|visitor_id|session_id|user_agent)($|_)'
    OR COLUMN_NAME IN ('ip','ipaddress','useragent')
  )
ORDER BY TABLE_NAME, COLUMN_NAME;

Ein gefundener Spaltenname beweist noch nicht, dass dort Daten gespeichert werden.

WordPress / WP-CLI

wp plugin list --status=active

wp option get active_plugins --format=json
wp option list --search='*stat*' --fields=option_name,autoload
wp option list --search='*analytics*' --fields=option_name,autoload

Danach insbesondere Statistik-, Security-, Formular-, CAPTCHA- und Newsletter-Plugins mit den passenden Anleitungen abgleichen.

Browser-Konsole

Auf der eigenen Website in den Entwicklerwerkzeugen ausführen:

console.table({

  cookies: document.cookie || '(keine per JavaScript lesbaren Cookies)',
  localStorage: Object.keys(localStorage),
  sessionStorage: Object.keys(sessionStorage)
});

HttpOnly-Cookies sind absichtlich nicht über document.cookie sichtbar. Deshalb zusätzlich im Browser unter „Application/Speicher“ und in den Netzwerk-Headern prüfen.

HTTP / curl

curl -sSIL https://DEINE-DOMAIN.TLD

curl -sSI https://DEINE-DOMAIN.TLD | grep -i '^set-cookie:'
curl -sSL https://DEINE-DOMAIN.TLD | grep -Eoi '(src|href|action)=["'"']https?://[^"'"' ]+' | sort -u

Die letzte Abfrage findet statisch im HTML sichtbare externe URLs. JavaScript kann weitere Requests erst zur Laufzeit erzeugen; dafür die Netzwerkansicht des Browsers verwenden.

Eigene Test-IP in Logs suchen

Nur mit deiner eigenen aktuellen Test-IP durchführen. Nach einem einzelnen Seitenaufruf gezielt prüfen, ob sie in deinen Logs auftaucht:

TEST_IP='DEINE.EIGENE.IP'

grep -RFn -- "$TEST_IP" /var/log/apache2 /var/log/nginx 2>/dev/null

Keine fremden IP-Adressen ausgeben oder komplette Logs veröffentlichen. Ein Sicherheitssystem kann eine Angriffs-IP bewusst und zeitlich begrenzt speichern.

Reverse Proxy / CDN

grep -RniE 'X-Forwarded-For|X-Real-IP|CF-Connecting-IP|True-Client-IP|RemoteIPHeader|real_ip_header|trusted_proxies' /etc/apache2 /etc/nginx /etc/caddy 2>/dev/null

→ Cloudflare: Origin ohne Besucher-IP · → IP-Verarbeitung vs. Speicherung

Was diese Selbsttests nicht feststellen können

interne Logs des Hostinganbieters, sofern sie dir nicht zugänglich sind,
interne DDoS-/WAF-/Security-Protokolle externer Anbieter,
Verarbeitung bei Drittanbietern hinter einer externen Verbindung,
JavaScript-Netzwerkverkehr allein durch statisches HTML-Grep.

Für diese Ebenen sind Anbieterinformationen, Verträge/Dokumentation und die Browser-Netzwerkanalyse zusätzlich nötig.