Leistungsumfang Deep Audit: alle 188 Tiefen-Prüfpunkte

Prüft alle Netzwerk-Requests vor jeglicher Banner-Interaktion auf bekannte Tracking-Domains (Google Analytics, Meta Pixel, Hotjar u.a.). Requests zu Tracking-Diensten ohne vorherige Einwilligung sind ein klarer Verstoß gegen § 25 TDDDG.

Klickt automatisch den Ablehnen-Button und beobachtet anschließend, welche Netzwerk-Requests ausgelöst werden. Tracking-Requests nach einer Ablehnung zeigen, dass die CMP-Implementierung technisch fehlerhaft ist.

Prüft gezielt gesetzte Cookies (nicht Requests) vor Banner-Interaktion. Serverseitig gesetzte Tracking-Cookies (Set-Cookie-Header) werden von clientseitigem Consent-Management oft nicht erfasst.

Prüft, ob nach dem Klick auf Ablehnen noch Tracking-Cookies vorhanden sind. Ein korrektes CMP-System löscht bei Ablehnung bestehende Tracking-Cookies und setzt keine neuen.

Erstellt eine vollständige Liste aller Cookies in drei Zuständen: vor Interaktion, nach Ablehnung und nach Zustimmung. Dieses Inventar ist die Grundlage für Ihre Datenschutzerklärung.

§ 25 TDDDG erfasst jede Form des Speicherns auf dem Endgerät — nicht nur Cookies. Prüft localStorage und sessionStorage auf Tracking-Einträge (User-IDs, Session-Hashes) vor Consent.

Misst die tatsächlichen Pixel-Dimensionen von Akzeptieren- und Ablehnen-Button. Ein deutlich größerer Akzeptieren-Button ist ein nach EuGH und EDPB unzulässiges Dark Pattern.

Prüft, ob die Schriftgröße des Akzeptieren-Buttons größer ist als die des Ablehnen-Buttons. Auch typografische Hervorhebung der Zustimmungsoption ist ein subtiles Dark Pattern.

Prüft, ob ein Ablehnen-Button auf der ersten Ebene des Banners sichtbar ist. Wenn zum Ablehnen erst auf "Einstellungen" geklickt werden muss, erhöht das den Aufwand für die Ablehnung bewusst.

Prüft, ob Checkboxen im Consent-Dialog bereits vorangekreuzt sind. Seit Planet49 ist klar: Vorangekreuzte Checkboxen sind keine wirksame Einwilligung.

Art. 7 Abs. 3 DSGVO: Eine erteilte Einwilligung muss jederzeit widerrufbar sein. Der Widerruf muss so einfach sein wie die Erteilung — typisch: Cookie-Einstellungen-Icon auf der Seite.

Jeder Netzwerk-Request an einen Drittanbieter übermittelt die IP-Adresse. Erfasst alle Domains, die per HTTP-Request kontaktiert werden, bevor der Nutzer eingewilligt hat — auch reine Pixel und Beacons.

Prüft ob ein Service Worker registriert ist, der Push-Notifications oder Background-Sync durchführt, bevor eine Einwilligung erteilt wurde. Service Worker laufen im Hintergrund und können Tracking persistent machen.

Prüft ob ein Cookie-Banner vorhanden ist und ob Tracking-Cookies existieren. Fehlt der Banner bei vorhandenen Tracking-Cookies, ist das ein schwerer Verstoß.

Vergleicht die Farbgest altung von Akzeptieren- und Ablehnen-Button. Ein farbiger, auffälliger Akzeptieren-Button neben einem blassen Ablehnen-Link ist ein verbreitetes Dark Pattern.

Prüft ob der Zugang zur Website blockiert wird, wenn keine Einwilligung erteilt wird. Cookie-Walls sind nach EDPB Guidelines 05/2020 grundsätzlich unzulässig, da die Einwilligung nicht freiwillig ist.

axe-core prüft über 200 Regeln und meldet jede Violation mit dem betroffenen HTML-Element, CSS-Selektor, der verletzten WCAG-Regel und einem Hilfstext. Die Schweregrade: critical (verhindert Nutzung), serious (erhebliche Beeinträchtigung), moderate (Workaround möglich), minor (kosmetisch).

Überblick über Gesamtzahl der Prüfungen, Violations, unvollständige Prüfungen (benötigen manuelle Überprüfung) und bestandene Regeln. "Incomplete"-Items sollten manuell geprüft werden — sie enthalten häufig echte Probleme.

Rendert die Seite in einem 320px-Viewport und misst den tatsächlichen Scroll-Überlauf. Horizontaler Scroll über 0px gilt als Verstoß, Ausnahmen gelten nur für Datentabellen, Bilder, Karten und Videos.

Setzt den Browser-Zoom auf 200% und prüft, ob Inhalte überlaufen oder beschnitten werden. Besonders kritisch: Overlays, Modal-Dialoge und fixed-position Elemente, die bei starkem Zoom Inhalte verdecken.

Liest die tatsächlich berechneten CSS-Farbwerte (computed styles) und berechnet das Kontrastverhältnis. Prüft gegen WCAG AA (4.5:1 für normalen Text) und AAA (7:1 für erhöhten Kontrast).

Navigiert per Tastatur durch die Seite und prüft, ob der Fokus-Indikator (Outline-Ring) bei jedem fokussierbaren Element sichtbar ist. outline:none ohne Ersatz ist ein häufiger Verstoß.

Misst die tatsächlichen Abmessungen interaktiver Elemente. Klick-/Touchflächen unter 44×44 CSS-Pixel sind für motorisch eingeschränkte Nutzer und auf mobilen Geräten schwer zu treffen.

Prüft ob ein verstecktes, aber fokussierbares Element am Seitenanfang existiert, das bei Tab-Drück sichtbar wird und zum Hauptinhalt springt. Ohne Skip-Link müssen Tastatur-Nutzer bei jedem Seitenaufruf durch die gesamte Navigation tabben.

Positive tabindex-Werte (>0) ändern die natürliche Fokus-Reihenfolge und führen fast immer zu Verwirrung. Der Deep Audit zählt alle Elemente mit positivem tabindex und bewertet den höchsten Wert.

Simuliert Tastatur-Navigation und prüft, ob der Fokus jemals in einem Element gefangen ist. Eine Tastaturfalle verhindert, dass Nutzer weiternavigieren können — das ist einer der schwerwiegendsten Barrierefreiheitsverstöße.

Prüft ob alle interaktiven Elemente (Buttons, Links, Dropdowns, Tabs) per Tastatur erreichbar und bedienbar sind. <div onclick> ohne tabindex und keydown-Handler ist nicht tastatur-zugänglich.

Modale Dialoge und Overlays müssen durch Drücken der Escape-Taste schließbar sein. Ohne diese Möglichkeit können Tastatur-Nutzer in einem Modal gefangen sein.

Prüft ob Elemente, die per display:none oder visibility:hidden aus dem Layout entfernt sind, trotzdem fokussierbar sind. Der Fokus "verschwindet" dann optisch, was Tastatur-Nutzer desorientiert.

Überschriften bilden die Inhaltsstruktur und dienen als primäres Navigationsmittel für Screenreader. Der Deep Audit prüft: genau eine h1, keine übersprungenen Ebenen, keine leeren Headings.

ARIA Landmarks (main, nav, banner, contentinfo) definieren die Hauptbereiche und ermöglichen Screenreader-Nutzern, direkt zu Abschnitten zu springen. Prüft ob die wichtigsten Landmarks vorhanden sind.

Das lang-Attribut auf <html> teilt Browsern, Screenreadern und Übersetzungstools die Sprache der Seite mit. Fehlt es, rät der Screenreader die Sprache anhand von Heuristiken — oft falsch.

ARIA (Accessible Rich Internet Applications) erweitert HTML um Semantik für Screenreader. Falsche ARIA-Attribute verschlechtern die Barrierefreiheit statt sie zu verbessern. Prüft auf ungültige Rollen, fehlende Labels und Konflikte.

Überblick über alle gefundenen Formulare auf der Seite: Anzahl, Typen (Kontakt, Newsletter, Login, Suche), vorhandene Features (Labels, Autocomplete, Validation).

Prüft ob jedes Eingabefeld ein programmatisch verknüpftes Label hat (<label for="..."> oder aria-label/aria-labelledby). Ohne Label können Screenreader-Nutzer nicht erkennen, was in das Feld eingegeben werden soll.

WCAG 1.3.5 fordert, dass Eingabefelder für personenbezogene Daten das autocomplete-Attribut korrekt verwenden (z.B. autocomplete="email", autocomplete="given-name"). Dies ermöglicht Autofill und hilft bei motorischen Einschränkungen.

Pflichtfelder müssen visuell und programmatisch als solche erkennbar sein. Ein rotes Sternchen allein reicht nicht — aria-required="true" oder das HTML5 required-Attribut muss gesetzt sein.

Prüft ob Formulare Fehlerbehandlungs-Muster implementieren: aria-invalid, aria-describedby für Fehlermeldungen, role="alert" für Live-Validation. Fehler müssen in Textform beschrieben werden.

Zusammengehörige Radio-Buttons und Checkboxen müssen in einem <fieldset> mit beschreibendem <legend> gruppiert sein. Ohne Gruppierung können Screenreader den Zusammenhang nicht vermitteln.

Formulare mit Passwort- oder Datei-Feldern, die method="get" verwenden, übertragen sensible Daten in der URL. Diese erscheinen im Browser-Verlauf, Server-Logs und Referrer-Headern. Ein schwerer Verstoß gegen Art. 32 DSGVO.

CAPTCHAs sind für Barrierefreiheit grundsätzlich problematisch: Visuelle CAPTCHAs schließen blinde Nutzer aus, Audio-CAPTCHAs schließen gehörlose Nutzer aus. Empfehlung: Honeypot-Felder oder unsichtbares reCAPTCHA v3.

Protokolliert alle Fehler in der Browser-Konsole während des Seitenaufbaus. JavaScript-Fehler signalisieren defekten Code, der Funktionalität beeinträchtigen kann — von fehlenden Analytics bis zu defekten Warenkörben.

Sichtbare PHP-Fehlermeldungen enthalten Dateipfade, Versionsnummern und Konfigurationsdetails. Diese Informationen sind für Angreifer wertvoll und stellen ein Sicherheits- und Datenschutzproblem dar.

Prüft ob ein <noscript>-Element vorhanden ist, das Nutzern ohne JavaScript eine Alternative oder zumindest einen Hinweis bietet.

Bilder unterhalb des sichtbaren Bereichs (below-fold) müssen nicht sofort geladen werden. loading="lazy" verzögert das Laden bis der Nutzer dorthin scrollt und verbessert die Ladezeit erheblich.

Wenn eine HTTPS-Seite Ressourcen über HTTP lädt, blockieren Browser aktive Inhalte (Scripts, iframes) und warnen bei passiven (Bilder). Dies kann Funktionalität zerstören und untergräbt die Verschlüsselung.

Der <title>-Tag ist die erste Information, die Screenreader beim Seitenaufruf vorlesen. Er muss aussagekräftig sein und den Seiteninhalt beschreiben. Fehlende oder generische Titel ("Startseite") sind problematisch.

Inline-Event-Handler (onclick, onmouseover im HTML) verhindern Content Security Policy und erschweren die Wartung. Empfehlung: addEventListener in externen Scripts.

Prüft ob der Viewport-Meta-Tag maximum-scale<2, minimum-scale, oder user-scalable=no enthält. Diese Einstellungen verhindern, dass Nutzer mit Seheinschränkungen die Seite vergrößern können.

WCAG 1.4.12 fordert, dass Nutzer Textabstände anpassen können. Der Deep Audit erhöht programmatisch Zeilen-, Absatz-, Buchstaben- und Wortabstand und prüft ob Inhalte abgeschnitten werden.

Prüft ob die Website die CSS-Media-Query prefers-reduced-motion respektiert. Menschen mit vestibulären Störungen oder Epilepsie können durch Animationen beeinträchtigt werden.

Misst die Renderzeit des größten sichtbaren Elements (Bild, Textblock, Video). Google-Empfehlung: unter 2.5 Sekunden gut, 2.5-4s verbesserungsbedürftig, über 4s schlecht.

Misst, wie stark sich Seiteninhalte während des Ladens verschieben. Plötzlich springende Buttons führen zu Fehlklicks. Google-Empfehlung: unter 0.1 gut, 0.1-0.25 verbesserungsbedürftig, über 0.25 schlecht.

Die Zeit zwischen HTTP-Anfrage und dem ersten empfangenen Byte. Langsamer TTFB deutet auf Server-Probleme, fehlende Caching-Strategien oder überlastete Datenbanken hin.

Misst DOMContentLoaded (HTML geparst), DOM Complete und Load Event (alle Ressourcen geladen). Langsame Ladezeiten erhöhen die Absprungrate und verschlechtern die User Experience.

Zählt HTTP-Requests und Transfervolumen nach Typ (Script, CSS, Bilder, Fonts). Jeder Request erzeugt Overhead: DNS, TCP, TLS-Handshake. Mehr als 80 Requests oder 3 MB Transfervolumen sind kritisch.

Scripts ohne async/defer im <head> blockieren das Rendering. Der Browser muss warten, bis jedes Script heruntergeladen und ausgeführt ist, bevor er weiteren Inhalt darstellt.

Prüft Bilder auf: fehlende Dimensionsangaben (verursacht CLS), veraltete Formate (PNG/JPEG statt WebP/AVIF), überdimensionierte Bilder (Auflösung > Darstellungsgröße).

Das alt-Attribut dient mehreren Zwecken: Screenreader lesen es vor, Suchmaschinen indexieren es, und es wird angezeigt wenn das Bild nicht lädt. Fehlende Alt-Texte sind der häufigste WCAG-Verstoß weltweit.

Das LG München I entschied: Die automatische Weitergabe der IP-Adresse an Google beim Laden von Google Fonts über das CDN ist ohne Einwilligung unzulässig. Dies gilt analog für Adobe Fonts (Typekit) und Font Awesome CDN.

Ohne font-display-Einstellung im @font-face-Block verhält sich der Browser unvorhersehbar: Text kann kurz unsichtbar sein (FOIT) oder mit Systemschrift erscheinen und dann springen (FOUT).

HTTP/2 bietet erhebliche Verbesserungen gegenüber HTTP/1.1: Multiplexing, Header-Kompression, Server-Push. Die meisten modernen Hoster unterstützen HTTP/2, Konfiguration ist serverseitig.

Zählt alle HTTP-Requests und kategorisiert sie in First-Party und Third-Party. Drittanbieter-Requests übermitteln mindestens die IP-Adresse und erfordern oft eine Rechtsgrundlage nach DSGVO.

Font Awesome über CDN (cdnjs, bootstrapcdn) übermittelt die IP-Adresse an US-Server. Analog zum Google-Fonts-Urteil ist dies ohne Einwilligung oder Vertragsgrundlage problematisch.

Defekte interne Links (404, 500) beeinträchtigen User Experience und SEO. Prüft alle internen Links auf der Seite und meldet HTTP-Fehler mit dem betroffenen Link und Ziel-URL.

Links mit target="_blank" ohne rel="noopener" ermöglichen der Zielseite über window.opener Zugriff auf die Ausgangsseite. Potenzielle Sicherheitslücke (Tabnabbing).

Dokumentiert alle internen und externen Links auf der Seite mit Ziel-URL und Linktext. Grundlage für Qualitätssicherung und die Prüfung der Datenschutzerklärung auf Vollständigkeit.

Canvas-Fingerprinting nutzt die Canvas-API um ein gerätespezifisches Profil zu erstellen. Ist nach § 25 TDDDG einwilligungspflichtig, da auf Endgeräte-Informationen zugegriffen wird.

Service Worker laufen im Hintergrund und können Push-Notifications, Background-Sync und Offline-Caching durchführen. Informationscheck — problematisch wenn Tracking-Funktionalität ohne Consent.

iframes ohne title-Attribut sind für Screenreader-Nutzer nicht identifizierbar. Der Titel sollte den Inhalt des iframes beschreiben (z.B. "Google Maps Standort" oder "YouTube Video: Produktvorstellung").

Versteckte oder minimale iframes (1x1 Pixel) von Tracking-Diensten laden beim Seitenaufruf automatisch und übermitteln Daten ohne sichtbare Interaktion. Einwilligungspflichtig.

YouTube-, Vimeo- oder Google Maps-iframes laden beim Seitenaufruf sofort Ressourcen vom Drittanbieter-Server und übermitteln die IP-Adresse. Ohne Einwilligung oder Rechtsgrundlage problematisch.

Listet alle externen Domains, die beim Seitenaufruf kontaktiert werden, mit Request-Anzahl und Typ. Jede Domain erhält die IP-Adresse des Nutzers — wichtig für die Vollständigkeit der Datenschutzerklärung.

Social Plugins (Facebook Like, Twitter Share, Instagram Embed) laden beim Seitenaufruf Ressourcen vom jeweiligen Anbieter. EuGH Fashion ID: Website-Betreiber sind gemeinsam Verantwortliche.

Live-Chat-Widgets (Zendesk, Intercom, Tidio, LiveChat) laden umfangreiche Scripts und setzen Cookies. Werden sie vor Einwilligung geladen, ist das ein Verstoß gegen § 25 TDDDG.

Google reCAPTCHA lädt Scripts von google.com und setzt Cookies. Es übermittelt umfangreiche Daten an Google-Server in den USA. Ohne Einwilligung oder Vertragsgrundlage problematisch.

Überblick über alle erkannten Technologien: CMS, Server, Frameworks, Bibliotheken, Analytics, CMP. Basis für die Vollständigkeit der Datenschutzerklärung.

Erkennt WordPress, Shopify, Wix, Squarespace, Joomla, Drupal, TYPO3, Magento u.a. anhand von Quellcode-Signaturen, Cookies und Meta-Tags. Zeigt Version falls sichtbar.

Response-Header wie Server: Apache/2.4.51 und X-Powered-By: PHP/8.1 verraten Angreifern die eingesetzte Software und ermöglichen gezielte Angriffe auf bekannte Schwachstellen der jeweiligen Version.

Erkennt React, Vue.js, Angular, Svelte, jQuery, Bootstrap und weitere anhand von globalen Variablen und Quellcode-Mustern. Informationscheck für Entwickler und Sicherheitsbewertung.

Bestimmte jQuery-Versionen (vor 3.5.0) haben bekannte XSS-Schwachstellen. Der Deep Audit erkennt die Version und prüft gegen die CVE-Datenbank. Betroffene Versionen sollten umgehend aktualisiert werden.

Erkennt Google Analytics, Matomo, Plausible, Fathom, Hotjar, Microsoft Clarity u.a. Alle Analytics-Dienste müssen in der Datenschutzerklärung aufgeführt sein.

Erkennt Cookiebot, Borlabs Cookie, OneTrust, usercentrics, Complianz u.a. anhand von Quellcode-Signaturen und Cookie-Mustern. Dokumentiert die eingesetzte CMP für die Compliance-Prüfung.

WordPress gibt seine Version standardmäßig im HTML-Quellcode preis: <meta name="generator" content="WordPress 6.x">. Dies erleichtert Angreifern, bekannte Schwachstellen der jeweiligen Version auszunutzen.

Erkennt eingesetzte WordPress-Plugins anhand von Quellcode-Pfaden und Signaturen. Veraltete Plugins sind das größte Sicherheitsrisiko bei WordPress-Installationen.

SRI schützt vor Supply-Chain-Angriffen: Wird ein externes CDN-Script manipuliert, erkennt der Browser die geänderte Prüfsumme und lädt es nicht. Alle externen Scripts und Stylesheets sollten SRI-Hashes haben.

Aggregiert mehrere Metriken (LCP, CLS, TTFB, Ressourcenanzahl) zu einem Score. Unter 50: schlecht, 50-89: verbesserungsbedürftig, 90-100: gut.

Prüft technische SEO-Grundlagen: Seitentitel, Meta-Description, h1, Canonical, Sitemap-Referenz, robots.txt, strukturierte Daten.

Ein fehlender oder nicht-aussagekräftiger Seitentitel ist einer der grundlegendsten SEO-Fehler. Suchmaschinen verwenden ihn als Haupt-Snippet in den Suchergebnissen.

Die Meta-Description beeinflusst die Klickrate in den Suchergebnissen. Fehlt sie, generiert Google einen eigenen Auszug — oft weniger ansprechend.

Jede Seite sollte genau eine h1 als Hauptüberschrift haben. Fehlende h1 oder mehrere h1-Elemente beeinträchtigen Screenreader-Navigation und SEO.

Ein <link rel="canonical"> teilt Suchmaschinen die bevorzugte URL für Seiten mit, die unter mehreren URLs erreichbar sind. Verhindert Duplicate-Content-Probleme.

Strukturierte Daten in JSON-LD (Schema.org) ermöglichen Rich Snippets in Suchergebnissen: Bewertungssterne, Preise, FAQs, Breadcrumbs. Erhöhen die Klickrate erheblich.

Open Graph Tags (og:title, og:description, og:image) steuern die Darstellung beim Teilen auf Social Media. Ohne sie verwendet die Plattform beliebige Inhalte der Seite.

Prüft Web-Qualitätsindikatoren: HTTPS, keine Mixed-Content-Fehler, keine Browser-Fehler, sichere APIs, korrekte Zeichensätze.

Lighthouse prüft eine Teilmenge der WCAG-Regeln (~35 Regeln). Für eine vollständige Prüfung siehe die axe-core Kategorie. Unter 50: kritisch, 50-89: verbesserungsbedürftig, 90+: gut.

Prüft ob eine Impressum-Seite über typische Pfade (/impressum, /imprint) oder Footer-Links erreichbar ist. Fehlt sie, ist das ein Verstoß gegen § 5 DDG.

Prüft das Impressum auf Pflichtangaben: Name/Firma, Anschrift, E-Mail, Telefon/Fax, Handelsregisternummer, USt-IdNr., Aufsichtsbehörde (bei Erlaubnispflicht). Bewertet den Prozentsatz der gefundenen Pflichtfelder.

Prüft ob eine Datenschutzerklärung über typische Pfade (/datenschutz, /privacy) oder Footer-Links erreichbar ist.

Prüft die DSE auf Pflichtangaben nach Art. 13 DSGVO: Verantwortlicher, Kontaktdaten, DSB, Zwecke, Rechtsgrundlagen, Empfänger, Drittlandtransfer, Speicherdauer, Betroffenenrechte, Beschwerderecht.

Erkennt veraltete Verweise: "BDSG alt", "TMG" (seit 14.05.2024 DDG), "TTDSG" (seit 14.05.2024 TDDDG). Veraltete Referenzen signalisieren eine nicht aktualisierte DSE.

Prüft ob die DSE ein Datum enthält und ob es älter als 12 Monate ist. Eine veraltete DSE ist ein Indikator für fehlende Aktualisierung bei geänderten Diensten.

Eine DSE mit weniger als 300 Wörtern kann die Informationspflichten nach Art. 13 DSGVO kaum erfüllen. Typische vollständige DSE haben 2.000-5.000 Wörter.

Impressum und Datenschutzerklärung müssen von jeder Seite aus leicht erreichbar sein. Der Footer ist der etablierte Standard-Ort. Fehlende Footer-Links können bereits einen Verstoß darstellen.

Folgt internen Links von der Startseite und prüft bis zu 30 Unterseiten. Dokumentiert Seitenanzahl, HTTP-Status, Ladezeiten und gefundene Probleme pro Seite.

Seiten mit 404 (Not Found), 410 (Gone) oder 500 (Internal Server Error) werden erfasst. Kaputte Seiten beeinträchtigen User Experience und SEO-Ranking.

Prüft alle gecrawlten Seiten auf vorhandene <title>-Tags. Fehlende Titel beeinträchtigen Screenreader-Navigation und SEO.

Prüft alle gecrawlten Seiten auf vorhandene h1-Überschrift. Fehlt sie, fehlt die Hauptüberschrift für Screenreader-Navigation.

Prüft alle gecrawlten Seiten auf das lang-Attribut. Fehlende Sprachdeklaration betrifft Screenreader-Aussprache und Silbentrennung.

Aggregiert Alt-Text-Probleme über alle gecrawlten Seiten. Gibt die Gesamtanzahl fehlender Alt-Texte an und listet die betroffenen Seiten.

Protokolliert JavaScript-Fehler auf allen gecrawlten Unterseiten. Fehler auf Unterseiten bleiben oft unentdeckt, da sie nicht auf der Startseite sichtbar sind.

SPF legt per DNS-TXT-Record fest, welche Mailserver E-Mails im Namen Ihrer Domain senden dürfen. Ohne SPF kann jeder Server weltweit E-Mails mit Ihrer Absenderadresse versenden.

DMARC baut auf SPF und DKIM auf und definiert eine Policy: Was soll mit E-Mails passieren, die die Prüfung nicht bestehen? Ohne DMARC werden gefälschte E-Mails trotzdem zugestellt.

DKIM fügt ausgehenden E-Mails eine kryptographische Signatur hinzu, die vom Empfänger geprüft werden kann. Bestätigt, dass die E-Mail tatsächlich vom angegebenen Mailserver stammt und nicht verändert wurde.

MX-Records definieren die Mailserver für Ihre Domain. Informationscheck zur Dokumentation des E-Mail-Setups.

CAA-Records legen fest, welche Zertifizierungsstellen SSL-Zertifikate für Ihre Domain ausstellen dürfen. Verhindert, dass Angreifer bei einer anderen CA ein Zertifikat für Ihre Domain beantragen.

DNSSEC fügt kryptographische Signaturen zu DNS-Antworten hinzu und schützt vor DNS-Spoofing und Cache-Poisoning. Muss vom Domain-Registrar und DNS-Provider unterstützt werden.

IPv4-Adressen sind erschöpft. IPv6 ist der Standard für zukünftige Konnektivität. Prüft ob ein AAAA-Record vorhanden ist.

RFC 7208 erlaubt maximal 10 DNS-Lookups bei der SPF-Validierung. Überschreitung führt zu PermError und Ihre SPF-Prüfung schlägt fehl — E-Mails werden als verdaechtigt eingestuft.

Prüft ob das Zertifikat gültig ist, wann es abläuft und ob eine rechtzeitige Erneuerung eingerichtet ist. Abgelaufene Zertifikate führen zu Browser-Warnungen, die Besucher abschrecken.

Prüft die aktive TLS-Version. TLS 1.3 ist der aktuelle Standard, TLS 1.2 ist akzeptabel, TLS 1.0/1.1 sind unsicher und seit 2020 von allen Browsern abgelehnt.

Prüft die verwendete Cipher Suite auf bekannte Schwächen: RC4, DES, 3DES, MD5, NULL und EXPORT Cipher sind unsicher. Empfohlen: AES-256-GCM, ChaCha20-Poly1305.

Prüft aktiv, ob der Server noch Verbindungen mit TLS 1.0 oder 1.1 akzeptiert, indem eine Verbindung mit diesen Versionen versucht wird. Akzeptiert der Server sie, ist die Konfiguration unsicher.

Alle HTTP-Anfragen sollten per 301-Redirect auf HTTPS weitergeleitet werden. Ohne Weiterleitung können Nutzer versehentlich die unverschlüsselte Version der Seite aufrufen.

HSTS teilt dem Browser mit, für einen definierten Zeitraum ausschließlich HTTPS-Verbindungen zu verwenden. Schützt vor SSL-Stripping-Angriffen, bei denen ein Angreifer HTTPS auf HTTP herunterstuft.

Prüft ob das Zertifikat von einer vertrauenswürdigen Certificate Authority (CA) ausgestellt wurde und die Zertifikatskette vollständig ist. Selbstsignierte Zertifikate lösen Browser-Warnungen aus.

Gesamtbewertung der 7 primären Security-Header. Gibt einen Score basierend auf Vorhandensein und Konfigurationsqualität aller geprüften Header.

Erzwingt HTTPS-Verbindungen für einen definierten Zeitraum. Empfohlene Konfiguration: max-age=31536000; includeSubDomains; preload.

CSP definiert, welche Quellen für Scripts, Styles, Bilder und andere Ressourcen erlaubt sind. Einer der mächtigsten Sicherheits-Header gegen XSS und Code-Injection.

Verhindert MIME-Type-Sniffing: Ohne ihn könnten Browser versuchen, den Inhaltstyp zu erraten und etwa eine als Bild getarnte JavaScript-Datei ausführen.

Schützt vor Clickjacking: Ein Angreifer bettet Ihre Website unsichtbar in einen iframe auf seiner Seite ein und verleitet Nutzer zu Klicks auf versteckte Elemente.

Steuert, welche URL-Informationen beim Klick auf einen Link an die Zielseite übermittelt werden. Ohne Policy wird die vollständige URL übermittelt — inklusive Query-Parameter mit sensiblen Daten.

Kontrolliert, welche Browser-APIs die Website und eingebettete iframes nutzen dürfen: Kamera, Mikrofon, Geolocation, Payment, Fullscreen u.a.

War ein Browser-Feature zur XSS-Filterung. Ist veraltet und wurde von allen modernen Browsern entfernt. Kann sogar Sicherheitsprobleme verursachen. Empfehlung: Auf CSP setzen.

CORS steuert, welche Domains über Browser-Requests auf Ihre Ressourcen zugreifen dürfen. Access-Control-Allow-Origin: * erlaubt jedem Zugriff und ist in den meisten Fällen zu weit gefasst.

Prüft ob Server-Header (Server, X-Powered-By) Versionsnummern preisgeben. Diese Information erleichtert gezielte Angriffe auf bekannte Schwachstellen.

Prüft ob eine robots.txt vorhanden ist und ob sie sinnvolle Anweisungen enthält. Warnt vor problematischen Einträgen (z.B. Disallow: / blockiert alle Crawler).

Prüft ob eine XML-Sitemap vorhanden und valide ist. Hilft Suchmaschinen, alle Seiten zu finden und zu indexieren.

Prüft Cookies auf Sicherheitsflags: Secure (nur über HTTPS), HttpOnly (kein JavaScript-Zugriff), SameSite (CSRF-Schutz). Fehlende Flags erhöhen das Angriffsrisiko.

Gesamtbewertung: Welche Ports sind offen, welche entsprechen dem Erwarteten (80, 443), welche sind unerwartet und potenziell gefährlich.

Basierend auf den Port-Scan-Ergebnissen wird die Gesamtqualität der Firewall-Konfiguration bewertet. Nur HTTP/HTTPS offen = gut. Datenbank-Ports offen = kritisch.

FTP überträgt Zugangsdaten im Klartext. Sollte durch SFTP (SSH, Port 22) ersetzt werden. Öffentlich erreichbares FTP ist ein Sicherheitsrisiko.

Telnet überträgt alles im Klartext — inklusive Passwörter. Darf auf keinem Produktionsserver öffentlich erreichbar sein. Durch SSH ersetzen.

Eine öffentlich erreichbare MySQL-Datenbank ist eines der schwerwiegendsten Sicherheitsrisiken. Brute-Force-Angriffe auf Datenbank-Passwörter sind ein Standard-Angriffsvektor.

Remote Desktop Protocol ermöglicht vollständige Server-Fernsteuerung. Öffentlich erreichbares RDP ist ein häufiger Einstiegspunkt für Ransomware-Angriffe.

Wie MySQL — eine öffentlich erreichbare PostgreSQL-Datenbank ist ein kritisches Sicherheitsrisiko. Zugriff nur über localhost oder VPN erlauben.

VNC ermöglicht graphische Fernsteuerung. Viele VNC-Implementierungen haben keine starke Authentifizierung. Muss per VPN oder SSH-Tunnel geschützt werden.

Redis hat standardmäßig keine Authentifizierung. Ein öffentlich erreichbarer Redis-Server kann von jedem gelesen und beschrieben werden — ein extremes Sicherheitsrisiko.

Elasticsearch hat standardmäßig keine Authentifizierung. Enthält oft sensible Daten (Suchindizes, Logs). Tausende offene Elasticsearch-Instanzen werden regelmäßig von Angreifern gescannt.

MongoDB ohne Authentifizierung ist einer der häufigsten Gründe für Datenlecks. Enthält oft personenbezogene Daten. Muss per Firewall und Authentifizierung geschützt werden.

POP3 (unverschlüsselt) für E-Mail-Abruf. Sollte durch POP3S (Port 995) oder IMAPS (Port 993) ersetzt werden.

IMAP (unverschlüsselt) für E-Mail-Zugriff. Sollte durch IMAPS (Port 993) ersetzt werden.

Port 8080 wird oft für Entwicklungsserver, Proxies oder alternative Webserver verwendet. Kann auf einen ungesicherten Dienst hinweisen.

Gesamtbewertung: Anzahl der gefundenen exponierten Dateien und deren Kritikalität. Jede exponierte sensible Datei ist ein sofortiger Handlungsbedarf.

Die .env-Datei enthält Umgebungsvariablen: Datenbank-Passwörter, API-Keys, geheime Schlüssel. Öffentlicher Zugriff ermöglicht vollständige Kompromittierung des Systems.

Ein exponiertes .git-Verzeichnis ermöglicht das Herunterladen des gesamten Quellcodes inkl. Git-History. Kann Passwörter, API-Keys und interne Logik offenlegen.

wp-config.php.bak oder wp-config.php~ enthalten Datenbank-Zugangsdaten im Klartext. PHP-Backup-Dateien werden vom Server als Plaintext ausgeliefert, nicht ausgeführt.

Datenbank-Dumps (.sql, .sql.gz) können den gesamten Datenbestand enthalten: Nutzerdaten, Passwörter, Bestellungen, E-Mails. Meldepflichtiger Datenschutzvorfall wenn personenbezogene Daten enthalten.

phpinfo() zeigt die gesamte PHP-Konfiguration: Pfade, Module, Umgebungsvariablen (oft inkl. Passwörter), Server-Informationen. Muss auf Produktionsservern gelöscht werden.

Enthält gehashte Passwörter für HTTP-Basic-Auth. Obwohl gehasht, können schwache Passwörter offline geknackt werden.

Zeigt detaillierte Informationen über aktive Verbindungen, Anfragen und Server-Last. Kann IP-Adressen von Besuchern und interne URLs offenlegen.

Debug-Logs können Fehlermeldungen, Stack-Traces, Datenbankabfragen und teilweise personenbezogene Daten enthalten. Sollten nie öffentlich zugänglich sein.

Security.txt (RFC 9116) unter /.well-known/security.txt ermöglicht Sicherheitsforschern, Schwachstellen verantwortungsvoll zu melden. Sollte Kontakt-E-Mail und Verschlüsselungskey enthalten.

Wenn der Webserver Verzeichnisinhalte als HTML-Liste anzeigt, können Angreifer die Dateistruktur durchsuchen und sensible Dateien finden, die nicht direkt verlinkt sind.

Überblick über alle gefundenen Subdomains mit Kategorisierung in kritisch, riskant und informativ. Basis für die Bewertung der Angriffsoberfläche.

Ein DNS-Wildcard-Eintrag (*.domain.de) lässt jeden beliebigen Subdomain-Namen auflösen. Kann die Subdomain-Enumeration beeinflussen und ungewollte Angriffsvektoren eröffnen.

Prüft auf: db.*, database.*, mysql.*, phpmyadmin.*, admin.*, cpanel.*, staging.*, production.*. Diese Subdomains deuten auf sensible Systeme hin, die nie öffentlich erreichbar sein sollten.

Prüft auf: dev.*, test.*, beta.*, internal.*, intranet.*, jenkins.*, gitlab.*. Diese Subdomains können Entwicklungsumgebungen mit schwacher Authentifizierung exponieren.

Prüft auf verwaiste CNAME-Records (dangling CNAMEs): Subdomains die auf nicht mehr existierende Dienste (Heroku, GitHub Pages, AWS) zeigen, können von Angreifern übernommen werden.

Prüft wann die Domain abläuft. Unter 30 Tagen: kritisch (sofort verlängern). Unter 90 Tagen: hoch (zeitnah verlängern). Über 180 Tagen: ok.

Prüft ob WHOIS Privacy aktiviert ist. Ohne Privacy sind Name, Adresse, Telefon und E-Mail des Domain-Inhabers öffentlich einsehbar.

Ermittelt den physischen Standort des Servers über GeoIP-Datenbanken. Server außerhalb der EU/EWR erfordern zusätzliche Schutzmaßnahmen nach Art. 44-49 DSGVO (Standardvertragsklauseln, Angemessenheitsbeschluss).

Identifiziert den Hosting-Anbieter und prüft ob ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO typischerweise angeboten wird. Informationscheck für Ihre Compliance-Dokumentation.

Prüft auf öffentlich erreichbare Admin-Interfaces: phpMyAdmin, Adminer, Webmin, cPanel, Plesk, WHM. Diese Interfaces sollten nie ohne zusätzlichen Schutz öffentlich erreichbar sein.

Prüft ob beide Varianten (www und non-www) erreichbar sind und ob eine korrekte 301-Weiterleitung eingerichtet ist. Ohne Weiterleitung indexiert Google beide als separate Seiten.

Prüft robots.txt auf Einträge, die wichtige Seiten blockieren (z.B. Disallow: /impressum). Kann SEO und Erreichbarkeit beeinträchtigen.

Prüft ob die Startseite ein noindex-Meta-Tag oder X-Robots-Tag enthält. Auf Produktionsseiten ist dies fast immer ein versehentlich vergessenes Staging-Relikt.

Zählt die Anzahl der Weiterleitungen von der eingegebenen URL bis zur endgültigen Seite. Lange Ketten (3+) verlangsamen das Laden und verwirren Suchmaschinen.

Prüft ob ein PTR-Record für die Server-IP existiert. Fehlender Reverse-DNS kann dazu führen, dass E-Mails als Spam eingestuft werden.

MTA-STS (Mail Transfer Agent Strict Transport Security) erzwingt TLS-verschlüsselte E-Mail-Übertragung. Schützt vor Downgrade-Angriffen auf E-Mail-Verbindungen.

Prüft ob der Server Gzip- oder Brotli-Kompression für HTML, CSS und JavaScript aktiviert hat. Kompression kann das Transfervolumen um 60-80% reduzieren.

Prüft die Server-IP gegen bekannte DNS-basierte Blacklists (DNSBL). Eine gelistete IP kann E-Mail-Zustellung und Website-Reputation beeinträchtigen.

Öffnet das Chat-Widget im gerenderten DOM – einschließlich iFrames und Shadow DOM – und prüft Launcher, Kopfzeile und Eingabebereich auf einen erkennbaren KI-Hinweis. Der Pro-Check kann das Widget nur erkennen, nicht bewerten: Die Beschriftung entsteht erst durch JavaScript.

Abgestufte Bewertung: Bezeichnungen wie „Assistent“, „Helfer“ oder ein bloßer Vorname lassen offen, ob ein Mensch oder eine Maschine antwortet. „Bot“ ist ein Grenzfall. Abs. 5 verlangt eine klare und eindeutige Kennzeichnung.

Lädt die Bilddateien und liest ihre Metadaten aus: C2PA Content Credentials, IPTC DigitalSourceType, XMP-Felder und den EXIF-Software-Tag. Bei einem Treffer wird das Umfeld des Bildes auf eine sichtbare Kennzeichnung geprüft. Wichtig: Bildoptimierung entfernt Metadaten fast immer – ein negativer Befund beweist deshalb nichts.

Beobachtet die tatsächlich ausgelösten Netzwerk-Requests und erkennt so auch KI-Dienste, die erst zur Laufzeit nachgeladen werden und im Quelltext nicht stehen. Zusätzlich werden JavaScript-Bundles nach eingebundenen Anbieter-SDKs durchsucht. Serverseitige Aufrufe aus dem eigenen Backend bleiben allerdings auch hier unsichtbar.

Erkennt Optimierungs-Dienste, die Metadaten entfernen. Ist eine solche Optimierung aktiv, kann die Bildprüfung KI-Herkunftsdaten grundsätzlich nicht mehr finden. Der Check macht diese Prüflücke transparent, statt sie zu verschweigen.

Reiner Informations-Befund ohne Wertung: listet alle erkannten KI-Integrationen, Widgets, Generatoren-Signaturen und Medien mit Herkunftsmetadaten in einer Tabelle. Ohne diesen Überblick lässt sich keine Kennzeichnungsstrategie festlegen; das Inventar ist zugleich der Startpunkt für die interne Dokumentation.