Alles, was der Pentest prüfen kann

Drei Prüftiefen

Wie tief wir gehen können, hängt davon ab, was du bereitstellst. Das legen wir vor dem Start gemeinsam fest. Bei jedem Bereich unten steht, was er braucht.

Server, Verschlüsselung und HTTP

Braucht: nur deine Freigabe. Einzelne Punkte brauchen Testkonten oder Einblick.

• HTTP- und HTTPS-Varianten, Weiterleitungsziele und Herabstufung auf unverschlüsselte Verbindungen
• Zertifikatskette, Gültigkeit, Hostnamen und SNI
• TLS-Versionen und Kryptografie-Eigenschaften
• HSTS und der Kontext von includeSubDomains
• Schutzunterschiede zwischen Hosts, Sprachversionen, Fehlerseiten und APIs
• Einheitliches Verhalten über IPv4 und IPv6
• Durchsetzung der Sicherheits-Header an CDN, Reverse Proxy und Anwendung
• Erlaubte HTTP-Methoden und ihre tatsächliche Wirkung
• Caching privater Inhalte und Trennung von Rollen und Mandanten im Cache (mit Testkonten)
• Debug-, Status-, Diagnose- und Verwaltungsrouten
• Fehlerseiten und Umgang mit unerwarteten Eingaben
• Host-Validierung, vertrauenswürdige Forwarded-Header, Origin-Schutz und Proxy-Konfiguration (mit Einblick)

Browser und Frontend

Braucht: nur deine Freigabe. Geschützte Bereiche brauchen Testkonten.

• Wirksame Content Security Policy, auch bei eingebetteten Widgets und auf sensiblen Seiten
• Clickjacking-Schutz bei angemeldeten oder folgenreichen Funktionen
• Cookies: Zweck, Secure, HttpOnly, SameSite, Domain, Path und Laufzeit
• Sitzungstokens, private Daten und Geheimnisse in URLs, DOM, localStorage, sessionStorage und IndexedDB
• Abfluss von Reset-, Freigabe- und Buchungstokens über Referrer und Tracking
• Mixed Content, Formularziele und unsicher eingebundene Ressourcen
• Datenflüsse im DOM zu gefährlichen Stellen im JavaScript
• postMessage: Ursprungsprüfung, erwarteter Absender, Nachrichtenformat und erlaubte Aktionen
• Service Worker, Browser-Caches, Abmelden und Benutzerwechsel
• CORS: Origin, Credentials und welche Daten sich tatsächlich lesen lassen
• CSRF bei freigegebenen Testhandlungen
• Öffentliche JavaScript-Konfiguration, Source Maps, Kommentare und eingebundene Drittanbieter
• Darstellung von Suche, Formularfehlern, API- und Chatbot-Ausgaben

Login, Sitzungen und Schnittstellen

Braucht: Testkonten für die meisten Punkte. Von außen prüfen wir nur, was öffentlich erreichbar ist.

Anmeldung

• Registrierung und Verifizierung mit erlaubten Testkonten
• Verräterische Antwortunterschiede bei bekannten Testidentitäten
• Passwortänderung, Zurücksetzen und alternative Anmeldewege
• Ablauf, Einmalverwendung und Bindung von Reset- und Magic-Links
• MFA, Wiederherstellung und erneute Anmeldung vor sensiblen Änderungen
• OAuth und OIDC: erlaubte Redirects, state, nonce und PKCE
• Rollenvergabe und Kontoverknüpfung

Sitzungen

• Wechsel und Bindung der Sitzung bei Anmeldung, Rechteänderung und Mandantenwechsel
• Session Fixation
• Ablauf, Inaktivitätsgrenzen, Abmelden und serverseitiger Widerruf von Tokens
• Lebenszyklus von Refresh-Tokens und Wiederverwendung alter Tokens
• Signatur, Aussteller, Zielgruppe und Ablauf von Tokens
• Gleichzeitige Sitzungen und Trennung zwischen Browserprofilen

APIs und Nachrichten

• Rechte auf Objekte, Funktionen und einzelne Felder, auch bei Export und Download
• Serverseitige Mandantenzuordnung statt Vertrauen in Angaben aus dem Browser
• Zu viele zurückgelieferte Daten und Mass Assignment
• REST, GraphQL, Batch und ältere API-Versionen mit ihren jeweiligen Rechten
• WebSockets: Anmeldung, Origin-Prüfung und Rechte je Nachricht und Abonnement
• Erneute Rechteprüfung bei Reconnect, Abmelden und Mandantenwechsel
• Anmeldung und Objektbindung bei Gäste-, Freigabe-, Download- und Chat-APIs
• Missbrauchsanfällige oder kostenpflichtige Funktionen und ihre Limits
• Webhook- und Partner-Schnittstellen und sichere Fehlerbehandlung

DNS und E-Mail

Braucht: nur deine Freigabe. Mail-Header von dir machen die DKIM-Prüfung genauer.

• A-, AAAA-, CNAME-, NS-, MX- und relevante TXT-Einträge
• SPF: Syntax, Fehlerursachen und tatsächliche Mail-Nutzung
• DMARC: Policy und relevante Absenderdomains
• DKIM anhand bekannter Selektoren oder echter Mail-Header
• Verwaiste CNAME-Einträge und Hinweise auf nicht mehr zugeordnete Ressourcen
• Hinweise aus Certificate Transparency und bekannte Altsysteme, zur Abstimmung des Umfangs
• Registrierungsdaten über RDAP, wenn nötig
• DNSSEC, CAA, MTA-STS und TLS-RPT
• DNS- und Mail-Konfiguration und ihre Zuständigkeit (mit Einblick)

Offene Dateien und Komponenten

Braucht: nur deine Freigabe. Abhängigkeitsdateien brauchen Einblick.

• Öffentlich ausgelieferte Konfigurations- und Umgebungsdateien und Repository-Metadaten
• Backups, Logs und Exporte, nur als kleine Stichprobe und nie als Komplettabzug
• Verzeichnislisten, Debug-Ausgaben, Stacktraces und sensible Fehlerdetails
• Öffentlich auffindbare private Dokument-, Gäste- und Freigabe-URLs
• Unbeabsichtigt öffentliche Cloud-Speicher im vereinbarten Umfang
• CMS, Frameworks, Plugins und SDKs, die sich öffentlich erkennen lassen
• Bekannte Lücken dieser Komponenten laut Hersteller: betroffene Version, Backports und Voraussetzungen
• Abhängigkeitsdateien und Konfiguration (mit Einblick)
• Sicherheitskontakt und security.txt
• Sitemap, robots.txt und Metadaten auf sicherheitsrelevante Hinweise

Zugriffsrechte

Braucht: Testkonten und Testobjekte. Ohne sie bleibt dieser Bereich eine Prüflücke.

• Testkonto A auf das eigene Objekt, Testkonto B und Anonym auf dasselbe Objekt
• Zweiter Testmandant auf ein Objekt des ersten
• Gast auf Mitarbeiterfunktionen, Mitarbeiter auf nicht erlaubte Mandanten
• Lesen, Download, Export, Vorschau, Suche und ältere API-Versionen
• Einzelne sensible Felder an sonst öffentlichen Objekten
• Schreibrechte, nur an freigegebenen Testobjekten
• Freigabe-, Gäste-, QR- und Dokument-Links: Reichweite, Datenumfang, Ablauf, Widerruf und Token-Lecks
• Trennung im Cache, geprüft mit eigenen Testdaten
• Manipulation von Mandant, Besitzer und Objektreferenz aus dem Browser

Eingaben und Verarbeitung

Braucht: nur deine Freigabe. Gespeicherte Eingaben brauchen ein isoliertes Testobjekt. Wir arbeiten mit harmlosen Markern.

• Reflected und DOM XSS, Stored XSS nur im isolierten Testobjekt
• SQL- und NoSQL-Injection und Template-Verarbeitung, ohne belastende Abfragen und ohne Datenextraktion
• PHP-spezifische Schwächen
• Doppelte Parameter und unterschiedliche Auslegung durch Parser
• Open Redirects und erlaubte Weiterleitungsziele
• Header- und CRLF-Verarbeitung
• Download- und Pfadparameter, mit einer bereitgestellten harmlosen Testdatei
• SSRF-Flächen: URL-Import, Bild-Proxy, PDF- und Screenshot-Erzeugung, Websuche und Link-Vorschau
• XML-Verarbeitung, wenn vorhanden und erlaubt
• Verwendung von Host- und Forwarded-Headern

Request Smuggling, Cache Poisoning und Nachweise zu Remote Code Execution führen wir nicht ungefragt auf gemeinsam genutzter Produktivinfrastruktur aus. Gibt es einen konkreten Hinweis, dokumentieren wir den Verdacht und stimmen eine isolierte Prüfung mit dir ab.

Buchung, Zahlung, Dateien, Tracking

Braucht: freigegebene Testumgebung oder Testhandlungen. Consent und Tracking prüfen wir auch von außen. Wir lösen keine echte Buchung, Zahlung oder Stornierung aus.

Geschäftsabläufe

• Serverseitige Berechnung von Zeitraum, Belegung, Anzahl, Leistungen, Preis, Steuern und Währung
• Bindung von Angebot, Gast, Hotel oder Destination, Mandant und Buchung
• Gültigkeit von Angeboten, Gutscheinen und Einmalaktionen
• Reihenfolge von Anfrage, Reservierung, Bestätigung und Zahlung
• Rechte für Änderung, Stornierung, Rechnung, Gästekarte, Voucher, Export und Reisedokument
• Negative oder widersprüchliche Werte in synthetischen Abläufen
• Schutz gegen automatisches Blockieren von Inventar
• Zeitabhängige Regeln und Zeitzonen

Zahlung und Integrationen

• Bindung von Betrag, Währung, Buchung und serverseitig bestätigtem Zahlungsstatus
• Webhooks: Echtheit, Zielmandant, Frische, Replay-Schutz und Idempotenz
• Widersprüchliche, verspätete und wiederholte Ereignisse in der Sandbox
• Ob Rückkehrparameter aus dem Browser allein eine Zahlung bestätigen können
• Partnerparameter und Verfügbarkeitsschnittstellen im vereinbarten Umfang
• Konkurrierende Anfragen (Race Conditions), nur in der Testumgebung und mit wenigen Anfragen

Upload und Download

• Anmeldung, Objekt- und Mandantenrechte, Links und Vorschauen
• Dateityp, MIME, Inhalt, Name, Pfadbehandlung und Auslieferungsheader
• Aktive Inhalte, öffentliche Erreichbarkeit, Metadaten und Ablage außerhalb ausführbarer Bereiche
• Größen- und Anzahllimits, über Konfiguration oder kleine Testdateien
• Vorhandene Malware- und Inhaltsprüfung, über Dokumentation oder ein ungefährliches Testverfahren
• Parser, Bild- und PDF-Verarbeitung und nachgelagerte KI-Verarbeitung
• CSRF bei erlaubten Upload-Aktionen

Consent und Tracking

• Datenübertragungen vor und nach Zustimmung, Ablehnung und Widerruf
• Gäste-, Buchungs- und Freigabewerte in URLs, Analytics, Tag-Manager und bei Drittanbietern

Wir zeigen dir die technischen Datenflüsse. Eine rechtliche Beurteilung oder ein Datenschutz-Zertifikat ist das nicht.

KI-Assistenten und Chatbots

Braucht: Freigabe der Chat-Nutzung. Gibt es bei dir einen Chatbot, prüfen wir ihn immer mit, sofern du ihn freigibst. Tiefe Punkte brauchen Testdaten, eine Testumgebung oder Einblick.

Oberfläche und Fähigkeiten

• Widget, Route, Skript-Herkunft und Chat-Endpunkt
• Eigene Anwendung, Proxy oder eingebetteter Dienst
• Was der Bot wirklich kann: lesen, suchen, hochladen, sich erinnern, Angebote, Buchungen, Mail und Zahlung

Chat-API und Sitzungstrennung

• Trennung von Chat-, Verlaufs-, Export-, Anhang- und Streaming-IDs zwischen Testkonten und Mandanten
• Reconnect, neue Unterhaltung, Abmelden, Kontowechsel und Cache
• Ob das Backend Bot-, Wissensbasis-, Rollen-, Mandanten- oder Modellangaben aus dem Browser ungeprüft übernimmt

Prompt Injection und Wissensquellen

• Offenlegung von Anweisungen und direkte Injection, in wenigen begründeten Varianten
• Indirekte Injection über Quellen aus URL-Import, RAG, Upload, Tool-Antworten oder OCR, nur mit einer kontrollierten Testquelle
• Quellenrechte, Mandantentrennung und Cache nach Rechteentzug

Persistenz und Lieferkette

• Ob Eingaben spätere Sitzungen, andere Nutzer oder andere Mandanten dauerhaft beeinflussen, nur in isolierten Testdaten
• Quellenherkunft, Freigabe von Wissensänderungen und Rücknahme von Testeinträgen
• Versionen und Herkunft von SDKs, Tools, Modellen, Prompts und Ingestion-Pipelines (mit Einblick)

Offenlegung und Ausgabe

• Trennung synthetischer privater Testdaten von anderen Nutzern, Mandanten und öffentlichen Quellen
• Darstellung von HTML, Markdown, Links, Bildern und Downloads und automatische externe Abrufe
• Datenabfluss mit harmlosen Markern zu ausdrücklich erlaubten Zielen
• Sensible Inhalte in Streaming-Fragmenten, auch wenn die Endantwort sie ausblendet
• Fehlerdetails und sensible Logs (mit Einblick)

Tools und Aktionen

• Unabhängige serverseitige Rechteprüfung, minimale Tool-Rechte, Mandantenzuordnung und feste Eingabeformate
• Schutz vor Rollenbehauptungen im Chat
• Bestätigung vor folgenreichen Aktionen und ihre Bindung an Empfänger, Objekt und Betrag
• Unterschied zwischen Modellaussage, vorgeschlagenem Aufruf, abgewiesenem Aufruf und echter Wirkung

Aussagen des Bots

• Preis, Verfügbarkeit, Rabatt, Storno und Leistungen im Vergleich mit einer datierten maßgeblichen Quelle
• Sicherheitsrelevante Aussagen zu Wegen, Öffnungen, Wetter und Lawinen, Badefreigaben und Barrierefreiheit

Kosten und Grenzen

• Limits für Eingabe, Ausgabe, Dateigröße und Kontext
• Quoten, Kostenalarm, Länge von Tool-Ketten, Timeouts und begrenzte Wiederholungen (mit Einblick)
• Verhalten bei Abbruch und Fehlern (mit Einblick)

Backend und Überwachung

Braucht: Einblick in Code, Konfiguration und bereinigte Logs.

• Serverseitige Rollen- und Mandantenprüfung und Datenzugriffsschicht
• Parametrisierte Abfragen, Kontextkodierung und Prüfung der Geschäftsregeln
• Verwaltung von Secrets, minimal berechtigte Dienstkonten, Schlüsselrotation und Token-Lebenszyklus
• Abhängigkeiten, SDK- und Plugin-Versionen, Herkunft in der Lieferkette und Herstellerhinweise
• Webhook-Signaturen, Frische, Idempotenz und Transaktionsgrenzen
• Netzwerk- und Egress-Regeln für URL-Abrufe und Tools
• Fehlerbehandlung, fehlgeschlagene Teilaktionen, Fail-closed, Timeouts und begrenzte Wiederholungen
• Audit-Ereignisse für Login, Rechteänderungen, private Exporte und Tools
• Logs ohne Secrets, Alarmierung, Korrelations-IDs und Mandantenkontext
• Dokumentierte Sicherungs-, Wiederherstellungs- und Incident-Prozesse

So bewerten wir

Jeder Eintrag im Bericht hat eine stabile ID und fällt in genau eine dieser Gruppen. Nur die erste zählt als bestätigte Schwachstelle.

• Bestätigte Schwachstelle: belegt und reproduzierbar, eingestuft als Kritisch, Hoch, Mittel oder Niedrig
• Härtungshinweis: sinnvolle Verbesserung ohne belegte Sicherheitsverletzung
• Offener Verdachtsfall: konkrete Beobachtung, bei der der Nachweis noch fehlt, und was dafür nötig wäre
• Positivfeststellung: getestete Schutzmaßnahme, die gehalten hat
• Prüflücke: was nicht geprüft werden konnte, und warum

Jede Maßnahme bekommt zusätzlich eine Priorität von P0 bis P3, eine Zuständigkeit und ein Retest-Kriterium.

Standards

Daran orientieren wir uns. Das ist keine Zertifizierung und keine Bestätigung, dass deine Website einen dieser Standards erfüllt.

• OWASP ASVS 5.0.0
• OWASP WSTG 4.2
• OWASP Top 10:2025
• OWASP API Security Top 10:2023
• OWASP LLM Top 10:2025
• FIRST CVSS v4.0

Pentest anfragen