# Betreiber-Fix-Guides fuer kinderaerzte-im-netz.de

kinderaerzte-im-netz.de: 13 priorisierte Betreiber-Guide(s) aus 36 Befund(en).

> Automatisch aus SaferPage-Scan-Evidenz und Betreiber-Guides abgeleitet. Betreiber müssen Umsetzung, Rechtsgrundlagen, interne Systeme und Re-Scan-Nachweise fachlich freigeben.

## Phasen
- **Triage** (0-48 Stunden): Hoch priorisierte Befunde reproduzieren, Owner bestätigen, Exportpaket sichern.
- **Fix umsetzen** (0-14 Tage): Consent-, Anbieter-, Notice-, Cookie-, Formular- oder Header-Änderungen umsetzen und versionieren.
- **Nutzertexte synchronisieren** (parallel): Datenschutzhinweis, Cookie-Erklärung, Anbieterregister und TrustHub an reale Technik anpassen.
- **Re-Scan und Freigabe** (nach Deployment): Erstaufruf, Ablehnen, Akzeptieren, GPC, Mobilansicht und priorisierte Unterseiten erneut prüfen.

## Guide-Streams
### Sichtbare Versionen und CVE-Hinweise beheben
- Priorität: hoch / Owner: IT/Security / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/sichtbare-versionen-und-cves-beheben
- Befund: PHP-Version ist nicht mehr upstream unterstuetzt - PHP auf eine aktuell unterstuetzte Version migrieren. Upstream-Sicherheitsfixes gibt es laut php.net nur noch fuer PHP 8.2 bis 8.5; alte 7.x/8.0/8.1-Header sind kritisch, sofern kein Distribution-Backport nachweisbar ist.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Generator-, Header- und Bibliothekssignale erneut prüfen.

### PII- und URL-Datenlecks vermeiden
- Priorität: hoch / Owner: Webentwicklung/IT / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/pii-und-url-datenlecks-vermeiden
- Befund: Formular mit personenbezogenen Feldern nutzt GET - Formulare mit personenbezogenen Daten per POST senden und sicherstellen, dass Werte nicht in URL, Referrer oder Analytics auftauchen.
- Befund: Dateneingabe und datenschutzrelevante Drittanbieter im selben Browseraufruf - Tracking, Werbung und Session-Replay auf Seiten mit Dateneingabe nur nach Einwilligung auslösen und keine Formularwerte an Tags übergeben.
- Befund: PII, URL-Parameter & Datenleck-Schutz - Personenbezogene Werte nicht in URLs, GET-Formularen, Referrern, Logs oder Tracking-Tags transportieren.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: URLs, Referrer, Logs und Drittanbieter-Requests auf personenbezogene Werte prüfen.

### Google-Dienste datenschutzfreundlich einbinden
- Priorität: hoch / Owner: Marketing/IT / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/google-dienste-datenschutzfreundlich-einbinden
- Befund: Google Consent Mode Default nicht erkannt - Vor dem ersten Google-Tag Consent-Defaults setzen, typischerweise ad_storage, analytics_storage, ad_user_data und ad_personalization auf denied.
- Befund: Google-Dienste & Drittanbieter - Google-Dienste einzeln prüfen, Consent Mode sauber setzen und Fonts möglichst lokal ausliefern.
- Befund: Google-Dienste - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Google-Requests vor und nach Consent vergleichen.

### Tracking-Pixel und Beacons begrenzen
- Priorität: hoch / Owner: Marketing/IT / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/tracking-pixel-und-beacons-begrenzen
- Befund: Tracking-Pixel oder pixelnahe Requests erkannt - Pixel von Matomo erst nach Einwilligung laden, Zweck erklären und unnötige Bild-Tracker entfernen.
- Befund: Tracking-Pixel & Beacons - Pixel, sendBeacon, keepalive-Fetch und Link-Pings auf Consent, Zweck, Anbieter und Datenminimierung prüfen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Pixel-, ping-, beacon- und keepalive-Ziele erneut exportieren.

### Referrer- und URL-Leaks vermeiden
- Priorität: hoch / Owner: Webentwicklung/IT / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/referrer-und-url-leaks-vermeiden
- Befund: Seiten-URL wird in Drittanbieter-Requests übertragen - Tracking-/Tag-Parameter für Anbieter wie Matomo so konfigurieren, dass keine unnötigen Pfade, Suchparameter oder Formularumfelder gesendet werden.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Referrer-Header und Query-Parameter in Request-Samples kontrollieren.

### SEO-Spam und Cloaking bereinigen
- Priorität: hoch / Owner: Webbetrieb/SEO/Security / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/seo-spam-und-cloaking-bereinigen
- Befund: Canonical zeigt auf fremde Domain - Canonical-Tags sollten nur bewusst auf fremde Domains zeigen; sonst kann Traffic/Ranking umgeleitet werden.
- Befund: Sehr viele externe Links erkannt - Prüfen, ob die Seite als Linkfarm, Affiliate-Brücke oder Spam-Seite dient.
- Befund: SEO-Integrität & Cloaking - Versteckte Inhalte, Canonical-Missbrauch und Googlebot-Abweichungen entfernen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Normaler Browser, SaferPage-Crawler und Suchmaschinenansicht vergleichen.

### Security-Header setzen
- Priorität: hoch / Owner: IT/Security / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/security-header-setzen
- Befund: HSTS fehlt - Header `strict-transport-security` setzen und nach Deployment erneut prüfen.
- Befund: Content-Security-Policy fehlt - Header `content-security-policy` setzen und nach Deployment erneut prüfen.
- Befund: X-Frame-Options fehlt - Header `x-frame-options` setzen und nach Deployment erneut prüfen.
- Befund: Sicherheit, TLS & Header - HTTPS, Zertifikat, HSTS, CSP, zentrale Security-Header und externe Skriptquellen sauber konfigurieren.
- Befund: Security-Header, Referrer-Policy und Browser-Schutz setzen - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- Befund: Cross-Origin-Embedder-Policy fehlt - Header `cross-origin-embedder-policy` setzen und nach Deployment erneut prüfen.
- Befund: Cross-Origin-Opener-Policy fehlt - Header `cross-origin-opener-policy` setzen und nach Deployment erneut prüfen.
- Befund: Cross-Origin-Resource-Policy fehlt - Header `cross-origin-resource-policy` setzen und nach Deployment erneut prüfen.
- Befund: Referrer-Policy fehlt - Header `referrer-policy` setzen und nach Deployment erneut prüfen.
- Befund: Permissions-Policy fehlt - Header `permissions-policy` setzen und nach Deployment erneut prüfen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Header, TLS, CSP und Referrer-Policy nach Deployment erneut scannen.

### Drittanbieter im Datenschutz erklären
- Priorität: hoch / Owner: Legal/Vendor Owner / Phase: 0-7 Tage
- Guide: https://saferpage.de/guides/drittanbieter-datenschutz-erklaeren
- Befund: Anbieterakten, AVV/DPA und Transfers priorisiert schließen - Top-Anbieter mit Zweck, Rolle, AVV/DPA, TOMs, Subprozessoren und Transfergrundlage dokumentieren.
- Befund: Browser-Nachweis - Unnötige Drittanbieter reduzieren und die verbleibenden Kontakte in Datenschutz und Consent abbilden.
- Befund: Datenschutzrelevante Drittanbieter im Browseraufruf - Prüfen, ob Anbieter wie Matomo in der Datenschutzerklärung und Cookie-Auswahl verständlich erklärt werden.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Drittanbieter-Liste gegen neue Requests und Cookies abgleichen.

### Barrierefreiheit bei Bannern und Formularen prüfen
- Priorität: mittel / Owner: UX/Content/IT / Phase: 7-30 Tage
- Guide: https://saferpage.de/guides/barrierefreiheit-cookie-banner-formulare
- Befund: Barrierefreiheit & Usability - Alt-Texte, Formularlabels, Button-Namen, lang-Attribut und Überschriftenstruktur für Nutzer und Screenreader prüfen.
- Befund: Cookie-Banner, Formulare und mobile Nutzung barriereärmer machen - Befund mit Betreiber-Guide beheben und danach erneut scannen.
- Befund: Bilder ohne Alternativtext - Inhaltliche Bilder mit alt-Text versehen; dekorative Bilder mit leerem alt oder aria-hidden kennzeichnen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Tastatur, Screenreader, Kontrast und Mobilansicht manuell prüfen.

### Tracking und Consent reparieren
- Priorität: mittel / Owner: Marketing/IT/Datenschutz / Phase: 7-30 Tage
- Guide: https://saferpage.de/guides/tracking-und-consent-reparieren
- Befund: Datenschutz, Cookies & Consent - Tracking, Werbung und nicht notwendige Cookies vor Zustimmung blockieren und verständlich erklären.
- Befund: Datenschutzrelevante Kontakte trotz GPC-Signal - Bei aktivem Global Privacy Control sollten Anbieter wie Matomo besonders begründet oder blockiert werden.
- Befund: Consent-Zustand: GPC mit Tracking-Hinweisen - GPC-Aufruf auf Datenschutz-Drittanbieter, Drittanbieter-Cookies und Storage-IDs prüfen.
- Befund: Keine gängige CMP-/TCF-API im Browser erkannt - Bei Tracking prüfen, ob Consent technisch nachvollziehbar gesetzt, widerrufen und dokumentiert wird.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Erstaufruf, Ablehnen, Akzeptieren und GPC getrennt scannen.

### Formulare und Zahlungen absichern
- Priorität: mittel / Owner: Webentwicklung/Datenschutz / Phase: 7-30 Tage
- Guide: https://saferpage.de/guides/formulare-datenschutzkonform-absichern
- Befund: Formulare, Login & Zahlung - Bei Formularen Zweck, Pflichtfelder, Datenschutzkontext, HTTPS und Zahlungsanbieter klar machen.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Formularseite, Ziel-URL, Pflichtfelder, Referrer und Tracking erneut prüfen.

### Externe Skripte und SRI absichern
- Priorität: niedrig / Owner: IT/Webentwicklung / Phase: quartalsweise
- Guide: https://saferpage.de/guides/externe-skripte-und-sri-absichern
- Befund: Meta-Description fehlt - Eine kurze Beschreibung setzen, die den Zweck der Seite erklärt.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Externe Skripte, SRI, CSP und Consent-Auslösung erneut prüfen.

### Performance und mobile Nutzbarkeit verbessern
- Priorität: niedrig / Owner: Webentwicklung/UX / Phase: quartalsweise
- Guide: https://saferpage.de/guides/performance-und-mobile-usability-verbessern
- Befund: Viele potenziell blockierende Assets - Skripte/CSS bündeln, defer/async nutzen und kritisches CSS priorisieren.
- [ ] Befund reproduzieren: SaferPage-Report, betroffene URL, Consent-Zustand und Request-/Cookie-/Header-Evidence sichern.
- [ ] Ursache beheben: Konfiguration, Tag, Inhalt, Anbieter, Header oder Formular gemäß Guide ändern und Änderung versionieren.
- [ ] Nutzertext aktualisieren: Datenschutzhinweis, Cookie-Liste, Anbieterregister oder Trust-Dokumentation an die reale Technik anpassen.
- [ ] Re-Test und Abschluss: Mobilansicht, Asset-Größen und Ladeverhalten erneut prüfen.

## Tracker- und Service-Mapping
- matomo.kinderaerzte-im-netz.de (vendor): Zweck, Rolle, AVV/DPA, Region, Transfer und Consent-Kategorie bestätigen.
- matomo.kinderaerzte-im-netz.de (browser_request): Request einem Dienst, Zweck und Consent-Zustand zuordnen oder blockieren.
