Datenschutzerklärung

Nicht festgestellt

In den geprüften app-eigenen Oberflächen gibt es keine zusätzliche Marketing- oder Tracking-Integration, kein Pixel und keinen Consent-Cookie. Eine framework-eigene Analytics-Oberfläche ist vorhanden; ihre Aktivierung im Produktivbetrieb muss separat bestätigt werden.

Browser-Speicher

Die Darstellung wird über next-themes gesteuert. Bei unveränderter Standardkonfiguration wird die Auswahl im Browser unter dem localStorage-Schlüssel theme gehalten. Der genaue Schlüssel und die Deploy-Konfiguration sind vor Veröffentlichung zu prüfen. Für sessionStorage wurde in den app-eigenen Oberflächen keine Verwendung gefunden.

Anmeldung

Bei Login/Signup verwendet Better Auth eine technisch erforderliche Sitzung mit serverseitiger Konten- und Sitzungsverwaltung. Cookie-Name, Laufzeit, Flags und Löschkonzept sind framework-/deployabhängig und müssen bestätigt werden.

Serverdaten

Kontaktanfragen und Produktprüfungen werden in der Datenbank gespeichert. Beim Checker wird nicht das abgerufene HTML gespeichert, sondern eine URL, ein Prüfzeitpunkt, der Befund, erkannte Lücken und ein SHA-256-Hash des Quell-HTMLs.

Die folgende Liste nennt die im Projekt erkennbaren Speicherorte. Sie ist eine technische Bestandsaufnahme und ersetzt nicht die noch offene Bestätigung von Zweck, Rechtsgrundlage und Speicherdauer.

Sitzungs-Cookie

Wird nur im Zusammenhang mit der Better-Auth-Anmeldung erwartet, damit eine angemeldete Person erkannt und der geschützte Befundbereich geladen werden kann. Der genaue Cookie-Name, seine Attribute, Laufzeit und Löschung sind zu bestätigen.

localStorage

next-themes speichert die gewählte helle oder dunkle Darstellung clientseitig. Die Präferenz wird für die Anzeige verwendet und nicht als Produktbefund verarbeitet.

sessionStorage

Keine Verwendung in den geprüften app-eigenen Komponenten oder Routen gefunden.

Nicht erforderlich

Keine bestätigten Marketing-, Profiling- oder Analyse-Cookies in den app-eigenen Produktflächen. Die framework-eigene Analytics-Komponente benötigt eine Produktionsprüfung, bevor daraus eine endgültige Aussage über externe Requests werden kann.

Die Rechtsseiten selbst sind statische Server-Component-Oberflächen: Sie lesen im Rendern keine Datenbank und rufen keine externe Datenquelle ab. Die globale Navigation prüft clientseitig den Better-Auth-Sitzungsstatus; dabei kann der Sitzungs-Cookie an eine gleich-originige Anfrage gehen. Ein Seitenaufruf erreicht außerdem die Hosting-/Webserver-Infrastruktur. Welche technischen Zugriffsdaten dort wie lange in Logs oder Monitoring landen, ist aus dem Repository nicht belastbar ersichtlich.

Für eine Prüfung sendet die Person eine öffentliche Produktseiten-URL an /api/product-check. Der Server validiert nur http/https-Ziele, lehnt Zugangsdaten sowie lokale und reservierte Ziele ab, folgt höchstens drei Weiterleitungen, wartet höchstens acht Sekunden und liest höchstens 512 KiB HTML. Aus dem HTML werden Titel, strukturierte Daten, Text- und Linkhinweise für die Befundregeln extrahiert.

Nach der Prüfung wird die Rohantwort nicht als HTML-Bestand in der Lückenlot-Datenbank abgelegt. Persistiert werden die eingereichte URL, der Prüfzeitpunkt, der Gesamtstatus, die erkannten Lücken mit Begründung sowie ein 64-stelliger SHA-256-Hash des Quell-HTMLs. Bei aktiver Sitzung wird der Befund der User-ID zugeordnet; ohne Sitzung bleibt diese Zuordnung leer. Der Hash dient der Wiedererkennung gleicher Prüfgrundlagen und ist nicht der Quelltext selbst.

Das öffentliche Formular übermittelt Name, E-Mail-Adresse und Nachricht an /api/contact. Eine gültige Nachricht wird in der Datenbank als ContactMessage gespeichert. Danach wird sie über den installierten E-Mail-Proxy an die bestätigte Firmenadresse weitergeleitet; zusätzlich wird eine Eingangsbestätigung an die absendende E-Mail-Adresse versendet.

Wird das Formular aus einem Checker-Ergebnis geöffnet, ergänzt die Oberfläche die geprüfte URL als „Bezug“ im Nachrichteninhalt. Diese URL wird dann zusammen mit der Nachricht gespeichert und weitergeleitet.

Für Login und Signup ist Better Auth installiert. Konten und Sitzungen werden serverseitig verwaltet; eine Sitzung wird im Browser technisch wiedererkannt. Der eingeloggte Befundbereich ruft nur Befunde ab, die der aktuellen User-ID zugeordnet sind. Der Befund-Endpoint ist nicht öffentlich und liefert ohne Sitzung keinen Befundbestand.

Aus dem Code und der installierten Modulbelegung ergeben sich folgende technischen Kontaktpunkte. Der tatsächliche Produktionsbetrieb, die Rollen als Verantwortlicher oder Auftragsverarbeiter, Vertragsgrundlagen und Drittlandtransfers sind nicht allein aus dem Repository ableitbar.

Zielseite des Checkers

Vom Nutzer angegebene Website; erhält die serverseitige HTML-Prüfanfrage und kann sie selbst protokollieren. Notwendig für die Kernfunktion.

Polsia E-Mail-Proxy

Erhält gültige Kontaktinhalte zur Weiterleitung an lckenlot@polsia.app und zur Eingangsbestätigung an die absendende Person. Anbieter-, Speicher- und Transferdetails müssen bestätigt werden.

Hosting / Datenbank

Verarbeitet die serverseitig persistierten Konten, Sitzungen, Kontaktanfragen und Befunde sowie möglicherweise technische Logs. Betreiber und Fristen sind offen.

API-Ursprung (bedingt)

Standardmäßig laufen die Browser-Anfragen an die gleich-originigen /api-Routen. Falls im Produktivbetrieb NEXT_PUBLIC_API_URL gesetzt ist, gehen diese Anfragen an den konfigurierten externen API-Ursprung. Wert, Anbieter und Transferdetails sind zu bestätigen.

Stripe (bedingt)

Im Repository ist ein generischer Hosted-Checkout über das Stripe-Billing-Modul vorbereitet, im sichtbaren Lückenlot-Produktfluss aber kein aktiver Zahlungs-CTA bestätigt. Nutzung, Umfang und Datenschutzhinweis müssen vor einem Live-Einsatz geprüft werden. Kartendaten werden bei Hosted Checkout nicht als eigenes App-Feld verarbeitet.

Analytics (offen)

Kein zusätzlich installiertes Analytics-Modul und keine app-eigene Tracking-Integration gefunden. Die framework-eigene Analytics-Oberfläche und eine mögliche Aktivierung im Deploy sind zu bestätigen.

Externe Dienste können eigene Datenschutzinformationen und Protokollierungen haben. Vor Veröffentlichung müssen die tatsächlich eingesetzten URLs, Anbieter und Transfers mit dem Produktionssetup abgeglichen werden.

Es wird ausdrücklich keine DSGVO-, BFSG- oder WCAG-Zertifizierung behauptet. Ebenso werden keine Betreiber-, Fristen-, Transfer- oder Rechtsgrundlagenangaben ergänzt, solange sie nicht vom Eigentümer beziehungsweise der Rechtsprüfung freigegeben sind.

Siehe auch das Impressum.