Zum Inhalt

Technische Web-Analyse

Prüfe deine Web-App.Verstehe jeden Befund.

Technische Beobachtungen mit nachvollziehbarer Evidenz. Damit du weißt, wo du ansetzen kannst.

Beispielbericht ansehenAnalysen entdecken

Beispieldaten · Kein pauschales Sicherheitsurteil

VLDX7AnalyseübersichtDEMO

demo.example

Illustrative Beispieldaten – keine echte Prüfung.

Hinweis

MIME-Sniffing-Schutz fehlt

  1. HTTP-RequestGET /
  3. HTTP-Response200 OK
  5. HTTP-HeaderPrüfung

Evidenz

X-Content-Type-OptionsNicht in der Antwort vorhanden

Nächster Schritt

Header auf nosniff setzen und erneut prüfen.

Befund öffnen

Keine Aussage über die Sicherheit der gesamten Anwendung. Prüfe den Header in deiner Server- oder Hostingkonfiguration und teste die Funktion nach der Änderung.

Die Beobachtung gilt für die gezeigte HTTP-Antwort.

01 / Vom Signal zur Maßnahme

Nachvollziehbar bis ins Detail.

BeobachtungHeader fehlt

HandlungKonfiguration prüfen

Von der eigenen URL
zur begründeten Maßnahme.

  1. Projekt bestätigen

    Freigeschaltetes Konto nutzen, eigenes Projekt anlegen und die Domain per DNS bestätigen.

  2. Begrenzt prüfen

    Der Website-Prüflauf beobachtet Erreichbarkeit, HTTPS und Antwortzeit sowie die vorgesehenen Module. Kein vollständiger Crawl oder Lasttest.

  3. Befunde einordnen

    Schwere, Evidenz und Abdeckung gemeinsam lesen. Ein regelbasierter Score ist kein Prozentsatz für Sicherheit oder Rechtskonformität.

  4. Verbesserung prüfen

    Maßnahmen umsetzen und abgeschlossene Scans vergleichen: hinzugekommene, behobene, geänderte und unveränderte Befunde.

Sechs Perspektiven.
Klar abgegrenzte Aussagen.

Was wird untersucht, was erhältst du und wo endet die Aussagekraft? Der Analysekatalog macht den vorgesehenen Leistungsumfang nachvollziehbar. Vollständige Leistungsbeschreibung lesen.

PrivacyShieldAccessAPIRepoAI

Privacy

Datenverarbeitung sichtbar machen.

Core · Pro · Agency

Was wird geprüft?
Datenschutzhinweis-Links, Cookie- und Storage-Signale, eingebundene Drittanbieter, Einwilligungssteuerungen und Formularfeldkategorien. Eine ausgeführte Browsermessung ergänzt Beobachtungen zu Consent, Drittanbietern und Speicher.
Wozu?
Du findest konkrete Prüfpunkte für Websitebetrieb und Datenschutzverantwortliche, statt aus einem Banner auf rechtskonforme Verarbeitung zu schließen.
Was erhältst du?
Einzelbefunde mit Messstatus, technischer Evidenz und Empfehlungen in den Scandetails und im JSON-Scanexport. Informationsbeobachtungen sind nicht automatisch Fehler.
Wo endet die Prüfung?
Statische Hinweise beweisen keine Ausführung. Die Browserbeobachtung umfasst nur ein begrenztes Zeitfenster und begrenzte Consent-Interaktionen. Keine rechtliche Bewertung, kein vollständiges Cookieinventar, kein Formularversand.
Was tust du danach?
Sichtbare Dienste und Speicherzwecke inventarisieren. Annehmen, Ablehnen und Einstellungen manuell prüfen; optionale Dienste und Datenschutzhinweise fachlich bewerten lassen.
Illustratives Beispiel (keine echte Messung): Kein Link zu Datenschutzhinweisen beobachtet.

Illustratives Beispiel — keine echte VLDX7-Messung.

Nächste Handlung: Einen klar bezeichneten Link im Footer ergänzen und dessen Inhalt rechtlich prüfen lassen.

Shield

Sicherheitsregeln konkret prüfen.

Core · Pro · Agency

Was wird geprüft?
HTTPS und Sicherheitsheader: HSTS, Content Security Policy, MIME-Sniffing-Schutz, Referrer-Policy, Schutz vor fremder Einbettung, Cross-Origin-Opener-Policy und Permissions-Policy.
Wozu?
Dein Entwicklungs- oder Hostingteam erkennt häufige Konfigurationslücken und kann gezielt entscheiden, welche Browserregeln zur Anwendung passen.
Was erhältst du?
Befunde mit Schweregrad, redigierter Header-Evidenz und konkreter Empfehlung in den Scandetails und im JSON-Scanexport.
Wo endet die Prüfung?
Konfigurationsprüfung, kein Penetrationstest, kein Exploitnachweis und kein SQLi-Testangebot. Eine strengere Regel kann gewünschte Integrationen beeinträchtigen.
Was tust du danach?
Benötigte Ressourcen und Integrationen festlegen, passende Header konfigurieren und anschließend Funktion sowie neue Messung prüfen.
Illustratives Beispiel (keine echte Messung): MIME-Sniffing ist nicht wirksam deaktiviert.

Illustratives Beispiel — keine echte VLDX7-Messung.

Nächste Handlung: X-Content-Type-Options: nosniff setzen und die Antwort erneut prüfen.

Access

Barrieren finden. Abdeckung mitlesen.

Core · Pro · Agency · Browsermessung erforderlich

Was wird geprüft?
Die geladene Zielseite wird im isolierten Browser mit axe-core geprüft, vor der automatischen Consent-Interaktion. Verletzte, unklare, bestandene und nicht anwendbare Regeln werden unterschieden.
Wozu?
Regelbezogene Hinweise etwa zu Beschriftung oder Kontrast geben der Entwicklung einen konkreten Einstieg in die Verbesserung der Zugänglichkeit.
Was erhältst du?
Access-Messzusammenfassung mit Status, Prüfregeln und Abdeckungsgrenzen sowie Einzelbefunde und JSON-Export. Null Befunde bleiben von einer nicht erfolgten Messung unterscheidbar.
Wo endet die Prüfung?
Eine geladene Seite, kein Crawl, Login oder Formularprozess. Blockierte Ressourcen, unzugängliche Frames, Timeouts und ausgelassene Regeln begrenzen die Abdeckung. Kein WCAG-, BFSG- oder Rechtskonformitätszertifikat.
Was tust du danach?
Betroffene Regeln beheben und erneut messen. Tastatur- und Screenreaderprüfungen manuell ergänzen; auch ein vollständiger automatischer Lauf ersetzt sie nicht.
Illustratives Beispiel (keine echte Messung): Ein Formularfeld hat keine zugeordnete Beschriftung.

Illustratives Beispiel — keine echte VLDX7-Messung.

Nächste Handlung: Ein sichtbares, programmatisch verknüpftes Label ergänzen und mit Tastatur sowie Screenreader prüfen.

API

Den Schnittstellenvertrag verstehen.

Pro · Agency

Was wird geprüft?
Eine öffentliche OpenAPI-3.0- oder -3.1-JSON-Beschreibung unter /openapi.json derselben Origin: Operationen, Antwortverträge, Erfolgs- und Fehlerfälle, IDs, Beschreibungen und deklarierte Authentifizierung.
Wozu?
Dokumentationslücken werden sichtbar, bevor Entwicklungsteams oder Integrationspartner auf unklare Verträge treffen.
Was erhältst du?
API-Befunde mit Versions- und Operationsinformationen, Dokumentationslücken und Handlungsempfehlungen in Scandetails und JSON-Scanexport.
Wo endet die Prüfung?
Dokumentprüfung, kein API-Funktionstest: kein Nachweis realer Authentifizierungswirkung, Lastfestigkeit oder Geschäftslogik. Eine fehlende oder geschützte Beschreibung bedeutet nicht gemessen, nicht erfolgreich geprüft.
Was tust du danach?
Eine unterstützte Beschreibung bereitstellen und Antwortfälle, IDs und Sicherheitsanforderungen ergänzen. Das reale Verhalten der Endpunkte separat testen.
Illustratives Beispiel (keine echte Messung): Fehlerantworten sind nicht vollständig dokumentiert.

Illustratives Beispiel — keine echte VLDX7-Messung.

Nächste Handlung: Erwartete 4xx- und 5xx-Antworten im OpenAPI-Vertrag ergänzen.

Repo

Projektgrundlagen nachvollziehen.

Pro · Agency · Separater Abruf

Was wird geprüft?
Öffentliche GitHub-Projektinformationen: Identität und Default Branch, Root-Manifeste und Lockdateien, Dokumentationsdateien, Verzeichnisstruktur, Automations- und Deploymentkonfigurationen sowie letzte CI-Aktivität.
Wozu?
Du erkennst sichtbare Grundlagen für Wartung, Übergabe und Zusammenarbeit — und siehst, welche Voraussetzungen genauer geprüft werden sollten.
Was erhältst du?
Eigenständige Zusammenfassung mit nachvollziehbarer Quelle, sichtbar im Projektbereich auf bewussten Abruf. Kein Scan und nicht im Scanexport; kein eigener Download vorgesehen.
Wo endet die Prüfung?
Nur öffentliche GitHub-Repositories. Vorhandene Dateinamen beweisen keine Inhaltsqualität. Kein Quellcodeaudit, keine CVE-, Secret- oder Lizenzkonformitätsprüfung. Ein fehlender CI-Lauf ist kein erfolgreicher Build.
Was tust du danach?
Repository und Branch bestätigen. Fehlende Dokumentationsgrundlagen ergänzen, Konfigurationen manuell prüfen und fehlgeschlagene CI-Läufe beim Provider untersuchen.
Illustratives Beispiel (keine echte Messung): Keine Security Policy im Repository beobachtet.

Illustratives Beispiel — keine echte VLDX7-Messung.

Nächste Handlung: Einen nachvollziehbaren Meldeweg für Sicherheitsprobleme dokumentieren.

AI

Deklarierte Fähigkeiten einordnen.

Pro · Agency · Separate Abfrage

Was wird geprüft?
Nach deiner Einrichtung und bewussten Freigabe wird die öffentliche A2A-Agent-Card deiner Anwendung gelesen: deklarierte Schnittstellen, Kommunikationsformen, angebotene Fähigkeiten und Sicherheitssignale.
Wozu?
Du verstehst, was ein Agent über seine Integration deklariert, bevor du einen passenden Client oder einen separaten Funktionstest planst.
Was erhältst du?
Ein begrenztes Capability-Ergebnis im Projektbereich. Nur vorübergehende Anzeige; keine Speicherung als Capability-Historie und kein Export. Technische Verbindungs- und Fehlerprotokolle sind davon getrennt. Vorhandene Signaturen werden nicht verifiziert.
Wo endet die Prüfung?
Kein Modellaufruf, kein Prompttest, keine Skill-Ausführung und kein Halluzinations-, Bias- oder Qualitätsbenchmark. Die Agent Card deklariert Fähigkeiten; sie beweist keine Funktionsfähigkeit. Nicht verfügbar ist kein Capability-Nachweis.
Was tust du danach?
Bindings und Clientanforderungen abgleichen. Deklarierte Funktionen und Signaturen anschließend separat prüfen.
Illustratives Beispiel (keine echte Messung): Streaming ist in der Agent Card deklariert.

Illustratives Beispiel — keine echte VLDX7-Messung.

Nächste Handlung: Den tatsächlichen Streamingfluss bei der separaten Integration testen.

Nicht alles landet
im selben Bericht.

Die Ausgabeform gehört zum Leistungsumfang. Ein JSON-Download ist kein PDF-Bericht oder Zertifikat.

Website-Scans
Die fünf neuesten Scans je Projekt mit Status und Zeitpunkt. Aufklappbare Befunde, technische Details, Access-Zusammenfassung, Scanvergleich und JSON-Export mit VLDX7-Herkunftsangabe. Nur vorhandene Messungen werden exportiert.
Repo-Evidence
Eigenständige strukturierte Antwort und Anzeige im Projektbereich. Nicht Teil der Scanbefunde oder des JSON-Scanexports.
AI-Capabilities
Separates, temporäres Ergebnis. Keine dauerhafte Capability-Historie und kein Download.

Erst den Umfang kennen.
Dann das Paket wählen.

Die Pakete im Vergleich. Alle Leistungen und Konditionen sind für das künftige Angebot vorgesehen — noch kein aktivierbarer Zahlungsanspruch.

Unser Angebot richtet sich ausschließlich an Unternehmer im Sinne des § 14 BGB in Ausübung ihrer geschäftlichen Tätigkeit, nicht an Verbraucher. Die Pakete werden derzeit vorgestellt. Kauf und Testabo sind noch nicht verfügbar. Bestehende freigeschaltete Konten können sich weiterhin anmelden.

Ausschließlich Geschäftskunden (B2B). Alle Pakete: noch nicht buchbar. Kein Kaufabschluss, kein Testabo und keine Zusatzscan-Bestellung auf dieser Seite.

Core

Für eine Webanwendung und ihre technischen Grundlagen.

39 €

netto pro Monat · zzgl. gesetzlicher MwSt.

1 Projekt · 5 Scans

Scankontingent pro Monat vorgesehen

  • Privacy · Shield · Access
  • Scanbefunde und Messabdeckung
  • Scanvergleich und JSON-Scanexport

Zusatzscan: 9 € netto zzgl. gesetzlicher MwSt.

Access setzt eine ausgeführte Browsermessung voraus.

Pro

Für Produkte mit API, öffentlichem Repository oder Agent-Schnittstelle.

99 €

netto pro Monat · zzgl. gesetzlicher MwSt.

3 Projekte · 25 Scans

Scankontingent pro Monat vorgesehen

  • Alle sechs Module
  • Alle vorgesehenen Core-Ausgaben
  • Repo-Evidence und temporäre AI-Anzeige separat

Zusatzscan: 7 € netto zzgl. gesetzlicher MwSt.

Repo und AI werden getrennt vom Website-Scan abgerufen.

Agency

Vorgesehen für mehrere Kundenprojekte und Zusammenarbeit.

249 €

netto pro Monat · zzgl. gesetzlicher MwSt.

10 Projekte · 100 Scans

Scankontingent pro Monat vorgesehen

  • Alle sechs Module
  • Alle vorgesehenen Pro-Ausgaben
  • Kundenprojekte und Teamzugang geplant

Zusatzscan: 5 € netto zzgl. gesetzlicher MwSt.

Agency bleibt gesperrt, bis der Teamzugang funktioniert. White-Label ist nicht enthalten.

Vorgesehene reguläre Konditionen

Monatliche Abrechnung. Sieben Tage Testphase mit Zahlungsmittel bereits zu Beginn. Kündigung zum Ende des Abrechnungszeitraums. Die genaue Laufzeitgestaltung und ein verhältnismäßiger Umgang mit Zahlungsausfällen sind noch in Prüfung. Auch einzelne Zusatzscans sind noch nicht kaufbar.

Ein Scan ist ein Website-Prüflauf, nicht automatisch die Prüfung sämtlicher Seiten. Repo- und AI-Abrufe sind getrennte Vorgänge; aus „alle Module“ lässt sich keine Anrechnung auf das monatliche Scankontingent ableiten.

Beta ist kein Kaufplan.

Ein kostenloser Zugang auf Einladung bietet den Pro-Modulumfang. Er ist kein öffentlich buchbares Abo. Eine monatliche Erneuerung des Beta-Kontingents wird nicht zugesagt.

Fragen zum vorgesehenen Umfang

Bereits freigeschaltet?

Melde dich mit deinem freigeschalteten Konto an, lege dein Projekt an und bestätige die Domain per DNS.

Die öffentliche Registrierung bleibt geschlossen. Der Login ist kein Kauf und aktiviert keinen Tarif.

Konto wird geladen …

Prüfbare Signale. Sichtbare Grenzen. Begründete Entscheidungen.

Zurück zum Anfang