Beispielbericht — Website Security Deep Review (499 €)

So sieht eine echte Sicherheitsprüfung aus.

Der Bericht ist für Geschäftsführer, Inhaber und Entscheider geschrieben — nicht nur für Techniker. Verständlich, ehrlich, mit realistischen Risiken und praktischen Maßnahmen. Kein Angst-Verkauf. Hier ein Auszug aus einem echten Bericht.

1. Zusammenfassung für die Geschäftsleitung

Beispielfirma GmbH — beispiel-firma.de

Geprüft am 14. Mai 2026 · Schriftlich autorisiert · Passive externe Analyse · Prüfer: SAB Security, Karlsruhe

geprüfte Bereiche

Handlungsbedarf (Medium)

Empfehlungen (Low)

Bestätigt sicher

Gesamteindruck: Die Website ist grundsolide aufgestellt. HTTPS, HSTS und die wichtigsten Security Header sind korrekt gesetzt. Es wurden keine offenen Admin-Panels, keine Datenbank-Backups und keine sensiblen Konfigurationsdateien gefunden. Der wichtigste Handlungsbedarf liegt im E-Mail-Bereich: DKIM fehlt, DMARC ist auf Monitoring gestellt. Ohne DKIM können gefälschte E-Mails im Namen der Domain verschickt werden — ein relevantes Risiko für Kundenvertrauen und Fake-Rechnungen.

Fazit: Keine kritischen Sicherheitslücken. Zwei mittlere Themen mit realem Geschäftsrisiko (DKIM fehlt, DSGVO-Prozesslücke im Kontaktformular). Alle technischen Empfehlungen sind mit geringem Aufwand umsetzbar. Ein kurzer Nachtest nach der Behebung ist im Deep-Review-Paket enthalten.

2. Prüfumfang & Autorisierung

Was wurde geprüft

DNS: A, AAAA, MX, TXT, SPF, DKIM, DMARC
HTTP→HTTPS Weiterleitung und www/non-www Verhalten
TLS-Zertifikat und Verschlüsselung
Security Header (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
Öffentlich erreichbare Dateien (.env, .git, Backups, robots.txt, sitemap.xml, security.txt)
CMS-/Admin-Panel-Erkennung
Kontaktformular: Validierung, Einwilligung, Honeypot, Basic XSS, Rate-Limiting

Was bewusst nicht geprüft wurde

Keine Brute-Force-Angriffe
Keine Denial-of-Service-Tests
Kein Social Engineering
Keine destruktiven Tests
Kein Zugriff auf geschützte Systeme oder Daten
Keine Weitergabe von Zugangsdaten

Diese Prüfung wurde mit schriftlicher Freigabe des Auftraggebers durchgeführt. Alle Tests waren passiv, nicht-destruktiv und auf öffentliche Informationen beschränkt.

3. Methodik

Die Prüfung folgt einem standardisierten, reproduzierbaren Ablauf — vergleichbar mit dem ersten Blick eines Angreifers auf die öffentliche Website, jedoch kontrolliert, dokumentiert und ohne schädliche Handlungen.

Alle Tests werden von Karlsruhe, Deutschland aus durchgeführt. Jeder Prüfschritt wird mit Datum, Uhrzeit und Ergebnis protokolliert. Eingesetzte Werkzeuge: DNS-Abfragen (dig), HTTP-Header-Analyse (curl), TLS-Prüfung (openssl), sowie manuelle Überprüfung der identifizierten Einträge.

Der Bericht verwendet eine realistische, geschäftsorientierte Bewertung:

Medium — Echtes Geschäftsrisiko (Missbrauch, Compliance, Kundenvertrauen)
Low — Härtung, Absicherung, kleine Verbesserungen
Info — Beobachtung, keine akute Maßnahme nötig

Befunde, die nur theoretisch oder ohne nachweisbaren Geschäftsschaden sind, werden nicht aufgenommen. Kein „kritisch" ohne bewiesenen Exploit-Pfad.

4. Befunde im Detail

DKIM fehlt — E-Mail-Spoofing möglich

Medium

Ergebnis: Es wurden keine DKIM-Einträge für die Domain gefunden. Geprüfte Selektoren: default, google, selector1, selector2, mail, k1, cloudflare, cf.

selector1._domainkey.beispiel-firma.de TXT:
Kein Eintrag gefunden.

Geschäftliche Auswirkung

Ohne DKIM gibt es keinen kryptografischen Nachweis, dass E-Mails von @beispiel-firma.de tatsächlich von Ihnen stammen. Ein Angreifer kann E-Mails mit Ihrer Absenderadresse fälschen — z. B. eine gefälschte Rechnung an Ihre Kunden oder eine manipulierte Zahlungsaufforderung. DKIM ist neben SPF und DMARC der dritte Baustein der E-Mail-Authentifizierung. Das Fehlen ist besonders relevant für ein Unternehmen, das Rechnungen oder vertrauliche Informationen per E-Mail versendet.

Empfehlung: Konfigurieren Sie DKIM-Signing bei Ihrem E-Mail-Provider (Google Workspace, Microsoft 365, Cloudflare Email Routing etc.). Der Provider stellt den öffentlichen Schlüssel bereit, der als DNS-TXT-Eintrag veröffentlicht wird. Aufwand: ca. 15 Minuten. Danach SPF auf -all und DMARC auf p=quarantine erhöhen.

DMARC auf p=none — keine Durchsetzung

Low

Ergebnis: DMARC ist vorhanden, aber auf p=none (nur Überwachung) gestellt.

_dmarc.beispiel-firma.de TXT:
"v=DMARC1; p=none; rua=mailto:[email protected]"

Geschäftliche Auswirkung

p=none bedeutet, dass nicht authentifizierte E-Mails zwar gemeldet, aber nicht abgewiesen oder in den Spam-Ordner verschoben werden. Gefälschte E-Mails erreichen die Empfänger weiterhin. Die Überwachung ist ein guter erster Schritt, sollte aber nach Auswertung der Reports auf p=quarantine erhöht werden.

Empfehlung: Nach der DKIM-Einrichtung die DMARC-Reports 2–4 Wochen auswerten. Wenn keine legitimen E-Mails fehlschlagen, auf p=quarantine (pct=25 für 2 Wochen, dann pct=100) erhöhen.

DSGVO-Einwilligung im Kontaktformular nicht serverseitig geprüft

Medium

Ergebnis: Das Kontaktformular prüft die Datenschutz-Zustimmung nur im Browser (client-seitig). Ein direkter POST-Aufruf ohne privacy_consent wird vom Server akzeptiert.

POST /scan/contact mit privacy_consent:false →
{"ok":true} — Anfrage wurde ohne Einwilligung gespeichert.

Geschäftliche Auswirkung

Nach DSGVO muss die Verarbeitung personenbezogener Daten auf einer dokumentierten Einwilligung beruhen. Wenn die Einwilligung nur client-seitig geprüft wird, können Daten ohne Zustimmung gespeichert werden — ein Prozessmangel mit potenziellen Compliance-Risiken. Praktisches Risiko: gering (da nur Kontaktanfragen). Rechtliches Risiko: vorhanden.

Empfehlung: Serverseitige Prüfung: lehnen Sie Anfragen mit privacy_consent !== true ab (HTTP 400). Aufwand: ca. 5 Minuten.

CSP erlaubt 'unsafe-inline' und 'unsafe-eval'

Low

Ergebnis: Die Content-Security-Policy enthält 'unsafe-inline' und 'unsafe-eval' im script-src.

Geschäftliche Auswirkung

Diese Einträge schwächen den XSS-Schutz der CSP. Im aktuellen Setup sind sie jedoch nötig, da die Website legitime Inline-Skripte einsetzt. Das Risiko ist gering, da die Seite statisch ist und keine Benutzereingaben dynamisch rendert.

Empfehlung: Mittelfristig Inline-Skripte in externe .js-Dateien auslagern (mit Nonce oder Hash). Solange die Seite keine dynamischen Benutzerinhalte rendert, ist das aktuelle Setup akzeptabel.

PGP-Schlüssel in security.txt nicht erreichbar

Low

Ergebnis: Die security.txt referenziert einen PGP-Schlüssel unter /.well-known/pgp-key.txt, der HTTP 403 (Forbidden) zurückgibt.

Geschäftliche Auswirkung

Sicherheitsforscher, die eine Schwachstelle vertraulich melden möchten, können ihre Nachricht nicht verschlüsseln. Geringes praktisches Risiko, aber eine verpasste Chance für vertrauenswürdige Kommunikation.

Empfehlung: Entweder den PGP-Schlüssel bereitstellen (nginx-Regel anpassen) oder den Verweis aus security.txt entfernen. Aufwand: 2 Minuten.

5. Bestätigte Sicherheitsmaßnahmen

Prüfbereich	Ergebnis
HTTPS & TLS	TLS 1.3, gültiges Let's-Encrypt-Zertifikat	Sicher
HTTP→HTTPS Weiterleitung	301-Weiterleitung funktioniert korrekt	Sicher
HSTS (HTTP Strict Transport Security)	max-age=31536000; includeSubDomains; preload	Sicher
X-Frame-Options / X-Content-Type-Options	SAMEORIGIN / nosniff — korrekt gesetzt	Sicher
Referrer-Policy / Permissions-Policy	Restriktiv und sinnvoll konfiguriert	Sicher
Sensitive Dateien	.env, .git/* werden mit 403 geblockt	Sicher
Keine Admin-Panels	Kein /wp-admin, kein /admin, kein CMS-Backend offen	Sicher
robots.txt / sitemap.xml / security.txt	Alle drei vorhanden und korrekt	Vorhanden

6. Nachtest (im Deep-Review-Paket enthalten)

Die Website Security Deep Review (499 €) beinhaltet genau einen kurzen Nachtest, nachdem Sie die empfohlenen Maßnahmen umgesetzt haben.

Befund	Stand
DKIM fehlt	Offen
DMARC auf p=none	Offen
DSGVO-Einwilligung serverseitig	Offen
CSP unsafe-inline	Akzeptiertes Risiko
PGP-Schlüssel nicht erreichbar	Offen

Behoben — nach erfolgreichem Nachtest auf diesen Status gesetzt.
Akzeptiertes Risiko — bewusst nicht behoben, dokumentiert.
Offen — noch nicht bearbeitet.

7. Empfohlene nächste Schritte

Priorität	Maßnahme	Aufwand
1	DKIM bei E-Mail-Provider einrichten	~15 Min.
2	DSGVO-Einwilligung serverseitig prüfen	~5 Min.
3	DMARC nach DKIM auf p=quarantine erhöhen	~5 Min.
4	PGP-Schlüssel bereitstellen oder Referenz entfernen	~2 Min.
5	CSP-Inline-Skripte langfristig auslagern	~1 Std.

Das ist ein Auszug aus einem echten Deep-Review-Bericht. Jeder Bericht wird individuell auf Ihre Domain und Situation zugeschnitten — mit konkreten, umsetzbaren Empfehlungen. Kein generischer Scanner-Output.

Website Security Deep Review anfragen — 499 € → Preise ansehen