Webseiten und Webanwendungen mit KI entwickeln

Was technisch, rechtlich und organisatorisch beherrscht werden muss – von der eigenen Website bis zum verantworteten Kundenprojekt

Fakten- und Recherchestand: 8. August 2026 Version: 1.0 Autor: Andreas Rüdiger Räumlicher Schwerpunkt: Deutschland / Europäische Union; technische Standards international Zielgruppe: Unternehmer, Selbstständige, Agenturen, Vibe Coder, Entwickler, Berater und Projektverantwortliche Quellenbasis: 221 dokumentierte Rechts-, Behörden-, Standard-, Forschungs- und offizielle Technikquellen Vorgesehener Dateiname: 15_webseiten-und-webanwendungen-mit-ki-entwickeln-faktendossier_2026-08-08

Auftrag, Reichweite und Leselogik

AUFTRAGSRAHMEN: Dieses Dossier behandelt den vollständigen Lebenszyklus von Webseiten und Webanwendungen: Bedarf, Wahl des Webtyps, Domain und Hosting, Inhalte, Recht, Datenschutz, Barrierefreiheit, Sicherheit, SEO, E-Commerce, Entwicklung, Prüfung, Launch, Betrieb, Übergabe und Stilllegung. ^{[S-002; S-001; S-004; S-076; S-074; S-107; S-031]}

RÄUMLICHE UND RECHTLICHE GRENZE: Der Schwerpunkt liegt auf Deutschland und der Europäischen Union. Technische Standards und Sicherheitsverfahren sind international. Rechtsaussagen beschreiben den belegten Stand am 8. August 2026 und ersetzen keine Einzelfallprüfung. ^{[S-076; S-080; S-099; S-074; S-126]}

KI-EINORDNUNG: KI wird als Entwicklungs- und Inhaltswerkzeug behandelt, nicht als verantwortliche Stelle. Sie kann Entwürfe, Code, Tests und Dokumentation unterstützen; Betreiber, Auftragnehmer und Kunde müssen tatsächliche Datenflüsse, Rechte, Sicherheit, Abnahme und Betrieb selbst beherrschen. ^{[S-010; S-006; S-211; S-213]}

Drei technisch unterschiedliche Ausgangspunkte

Abbildung: Abbildung 1: Auswahl des Webtyps nach Zweck, Änderungsbedarf, Systemkomplexität und Betriebsverantwortung.

Quellen- und Statuslogik

• 110 von 221 Quellen sind im Register als Primärquelle markiert.
• Gesetze und amtliche Normtexte werden gegenüber Blogzusammenfassungen bevorzugt.
• Offizielle Herstellerdokumentation belegt Konfiguration oder Produktstand, nicht automatisch Wirksamkeit oder rechtliche Zulässigkeit.
• Jede Quellen-ID führt im Register zu Herausgeber, Titel, Datum, Status, Relevanz, Refresh-Priorität und direkter URL.

Was dieses Dossier nicht behauptet

• Nicht jede öffentliche Website benötigt dieselben Rechtstexte, dieselben Cookies oder denselben Barrierefreiheitsnachweis. ^{[S-077; S-080; S-099]}
• Ein CMS ist nicht automatisch sicherer oder unsicherer als Individualsoftware; entscheidend sind Umfang, Konfiguration und Betrieb. ^{[S-196; S-031; S-009]}
• Ein Cookie-Banner macht eine unzulässige oder technisch falsch aktivierte Verarbeitung nicht nachträglich zulässig. ^{[S-081; S-085]}
• Eine Lighthouse-, Scanner- oder KI-Prüfung ist keine vollständige Abnahme. ^{[S-172; S-030; S-107]}
• Ein Kundenauftrag überträgt nicht automatisch sämtliche Betreiber-, Inhalts-, Datenschutz- und Wartungsaufgaben auf eine Seite; die tatsächliche Rollen- und Vertragslage entscheidet. ^{[S-086; S-002; S-004]}

Management Summary

1. Die Kernentscheidung: Die kleinste Lösung wählen, die Nutzeraufgabe, Änderungsbedarf, Daten, Verfügbarkeit und Wartung dauerhaft trägt. ^{[S-002; S-001]}

2. Der wichtigste Grenzsprung: Mit Login, Zahlungen, sensiblen Daten oder irreversiblen Aktionen wird aus einer Inhaltsseite ein dauerhaft zu schützendes Fachsystem. ^{[S-074; S-031; S-131]}

3. Die Kundenverantwortung: Bei Kundenprojekten müssen Inhaberschaft, Leistung, Mitwirkung, Freigaben, Wartung, Support, Datenexport und Vertragsende schriftlich geklärt sein. ^{[S-002; S-004; S-086]}

4. Die Kontenregel: Domain, Registrar, Hosting, Repository, E-Mail und Zahlungsanbieter gehören grundsätzlich in kontrollierte Organisationskonten, nicht in private Agenturzugänge. ^{[S-155; S-156; S-158]}

5. Die Datenschutzregel: Erst reale Daten- und Technologien inventarisieren, dann Rechtsgrundlagen, Hinweise und gegebenenfalls Einwilligung bestimmen. ^{[S-074; S-080; S-081]}

6. Die Cookie-Regel: Nicht jede Website braucht ein Banner; einwilligungsbedürftige Technik darf aber nicht vor wirksamer Auswahl starten. ^{[S-080; S-081; S-085]}

7. Die Barrierefreiheitsregel: Accessibility ist eine Eigenschaft der gesamten Nutzerkette und kann seit 28. Juni 2025 für bestimmte private Dienstleistungen gesetzlich relevant sein. ^{[S-099; S-104; S-107]}

8. Die Sicherheitsregel: Authentisierung, Autorisierung, Eingabeprüfung, Uploadschutz, Browserrichtlinien und Lieferkettenkontrolle müssen serverseitig und testbar umgesetzt werden. ^{[S-031; S-032; S-009]}

9. Die E-Commerce-Regel: Preis, Produktinformation, Bestellschritt, Zahlung, Bestätigung, Widerruf und Erstattung müssen als zusammenhängender Prozess funktionieren. ^{[S-116; S-119; S-121; S-131]}

10. Die SEO-Regel: Crawlbarkeit, stabile URLs, hilfreiche Inhalte, saubere Migration und reale Nutzerqualität sind belastbarer als Rankingversprechen. ^{[S-163; S-164; S-170]}

11. Die Betriebsregel: Go-live startet Updates, Monitoring, Backups, Restore, Support und Incident Response; er beendet sie nicht. ^{[S-050; S-014; S-012]}

12. Die KI-Regel: Generierter Code erhält keine Sonderbehandlung: Er braucht Verständnis, Review, Tests, Dependency- und Secretprüfung sowie klar begrenzte Wirkung. ^{[S-010; S-213; S-211]}

13. Die Übergaberegel: Quellcode ohne Buildweg, Domain ohne Registrarzugang oder Backup ohne getesteten Restore ist keine vollständige Übergabe. ^{[S-004; S-156; S-014]}

14. Die Abschaltregel: Stilllegung umfasst Export, Löschung, Domain, Weiterleitungen, Zugänge, Verträge, Zertifikate und Nutzerkommunikation. ^{[S-074; S-157; S-015]}

15. Die Schlussfolgerung: Wer für Kunden baut, verkauft nicht nur Seiten. Er übernimmt definierte Verantwortung für Wirkung, Nachweis, Übergabe und gegebenenfalls laufenden Betrieb. ^{[S-003; S-004; S-086]}

Minimaldefinition eines verantworteten Webprojekts

Verantwortungsmodell: eigene Website, Kundenprojekt und Betrieb

VERANTWORTUNGSSYNTHESE: Die Verantwortung wächst nicht allein mit dem Codeumfang. Entscheidend sind Öffentlichkeit, fremde Marke, personenbezogene Daten, Nutzerkonten, Zahlungen, Geschäftsprozesse, Integrationen und die Frage, wer das System nach der Übergabe tatsächlich betreibt. ^{[S-003; S-074; S-031; S-004]}

Abbildung: Abbildung 2: Verantwortung wächst mit Wirkung, Daten, Kundenbezug und Betriebsübernahme.

Verantwortungsmatrix für Kundenprojekte

Abbildung: Abbildung 3: Der Web-Lebenszyklus reicht von Bedarf und Auswahl bis Übergabe oder Stilllegung.

Was eine Kundenfreigabe nicht leistet

• Sie macht eine bekannte Sicherheitslücke nicht technisch ungefährlich. ^{[S-009; S-031]}
• Sie macht eine nicht passende Datenschutzrolle oder Datenverarbeitung nicht automatisch richtig. ^{[S-086; S-074]}
• Sie ersetzt keine Warnung vor erkannten fachlichen, rechtlichen oder betrieblichen Risiken. ^{[S-003; S-002]}
• Sie überträgt Domain, Zugang, Quellcode oder Nutzungsrechte nur, soweit das tatsächlich geregelt und umgesetzt wurde. ^{[S-156; S-096; S-004]}
• Sie ersetzt weder Restoretest noch technische Übergabe. ^{[S-014; S-004]}

84 belastbare Kernaussagen

LESEHINWEIS: Die folgenden Aussagen verbinden den Rechts- und Technikstand mit ausdrücklich gekennzeichneten Praxis- und Architektursynthesen. Jede Aussage verweist auf mindestens eine Quelle im Register. ^{[S-002; S-076; S-074; S-031]}

Die kleinste tragfähige Lösung ist meist die beste Architektur

ARCHITEKTUR-SYNTHESE: Eine redaktionelle Präsenz, ein CMS und eine individuelle Webanwendung lösen unterschiedliche Probleme. Die Auswahl muss aus Nutzeraufgabe, Änderungsfrequenz, Datenverarbeitung, Rollen, Integrationen, Verfügbarkeit und Wartungsfähigkeit folgen - nicht aus dem Wunsch, möglichst viel Technik einzusetzen. ^{[S-002; S-001; S-005]}

Eine Website und eine Webanwendung sind keine scharfen Rechtskategorien

RECHTLICHE EINORDNUNG: Technisch reicht das Spektrum von statischen Dokumenten bis zu transaktionalen Anwendungen mit Login und Fachlogik. Rechtliche Pflichten knüpfen nicht allein an die Bezeichnung, sondern unter anderem an Anbieterrolle, Datenverarbeitung, Inhalt, Zielgruppe und konkrete Dienstleistung an. ^{[S-076; S-074; S-099; S-126]}

KI erzeugt Artefakte, übernimmt aber keine Betreiberverantwortung

VERANTWORTUNGSGRUNDSATZ: Generierter Code, Text, Bild oder Konfiguration muss von einer verantwortlichen Person oder Organisation geprüft, freigegeben, betrieben und gepflegt werden. Modelloutput ist weder Abnahmeprotokoll noch Sicherheitsnachweis noch Rechtsprüfung. ^{[S-010; S-006; S-211; S-213]}

Der Go-live ist ein Betriebsbeginn und kein Projektende

LEBENSZYKLUSGRUNDSATZ: Nach Veröffentlichung entstehen dauerhafte Aufgaben: Zertifikate, Domains, Abhängigkeiten, Inhalte, Rechte, Backups, Monitoring, Datenschutzanfragen, Sicherheitsupdates und Wiederherstellung. Produktionsqualität umfasst daher ausdrücklich Zuverlässigkeit, Sicherheit und Wartbarkeit. ^{[S-001; S-050; S-014; S-009]}

Kundenprojekte erhöhen die Nachweis- und Übergabepflicht

PRAXIS-SYNTHESE: Sobald eine Website für Dritte gebaut wird, müssen Leistungsumfang, Mitwirkung, Freigaben, Kontoinhaberschaft, Wartung, Support, Datenmigration, Rechteübertragung und Projektende nachvollziehbar geregelt werden. Welche konkrete Pflicht besteht, hängt vom Vertrag und der tatsächlichen Rollenverteilung ab. ^{[S-002; S-004; S-086; S-074]}

Domain, Hosting und Administrationskonten sind kritische Vermögenswerte

PRAXIS-SYNTHESE: Wer Registrar-, DNS-, Hosting-, Repository- oder E-Mail-Konten kontrolliert, kann Erreichbarkeit, Zertifikate, Daten und Änderungen wesentlich beeinflussen. Für Kundenprojekte ist eine dokumentierte Inhaberschaft mit geregeltem Notfall- und Übergabezugriff deshalb ein zentrales Kontrollziel. ^{[S-155; S-156; S-158; S-011]}

DNS ist Teil der Sicherheits- und Verfügbarkeitsarchitektur

TECHNISCHE GRUNDLAGE: Fehlerhafte oder kompromittierte DNS-Konfiguration kann Website, E-Mail und Zertifikatsausstellung betreffen. DNSSEC schützt die Authentizität signierter DNS-Antworten; CAA kann festlegen, welche Zertifizierungsstellen Zertifikate ausstellen dürfen. Beides ersetzt keine sichere Kontoverwaltung. ^{[S-142; S-143; S-144; S-145]}

TLS schützt die Übertragung, nicht automatisch die Anwendung

SICHERHEITSGRUNDSATZ: TLS verschlüsselt und authentisiert die Transportverbindung. Es verhindert weder fehlerhafte Autorisierung noch SQL-Injection, XSS, kompromittierte Endgeräte oder unsichere Geschäftslogik. Zertifikatsautomatisierung und sichere Protokollkonfiguration müssen mit Anwendungskontrollen kombiniert werden. ^{[S-137; S-141; S-162; S-193]}

HSTS ist wirksam, aber migrationssensibel

TECHNISCHE GRUNDLAGE: HTTP Strict Transport Security weist Browser an, eine Domain nur über HTTPS aufzurufen. Fehler bei Subdomain-Abdeckung oder Zertifikatsbetrieb können die Erreichbarkeit beeinträchtigen; Einführung und Preload-Entscheidung benötigen daher eine kontrollierte Rollout- und Rückfallplanung. ^{[S-140; S-161; S-051]}

Cloudhosting folgt einem Modell geteilter Verantwortung

BETRIEBSGRUNDSATZ: Ein Cloudanbieter schützt nicht automatisch Anwendungscode, Identitäten, Datenklassifizierung, Konfiguration und Inhalte. Die konkrete Aufteilung hängt vom Dienstmodell ab; Betreiber müssen ihre verbleibenden Aufgaben ausdrücklich inventarisieren. ^{[S-195; S-011; S-016]}

Ein CMS reduziert Redaktionsaufwand, erhöht aber die laufende Angriffsfläche

CMS-BEFUND: Themes, Plugins, Laufzeit, Datenbank und Administrationsoberfläche schaffen Erweiterbarkeit und zugleich Abhängigkeiten. Sichere CMS-Nutzung verlangt kontrollierte Erweiterungsauswahl, zeitnahe Updates, minimale Rechte, Backups und Wiederherstellungstests. ^{[S-196; S-197; S-198; S-199]}

Plugins sind Softwarelieferanten im eigenen Produkt

LIEFERKETTENGRUNDSATZ: Ein Plugin kann Daten lesen, Inhalte verändern, externe Dienste laden und Sicherheitslücken einführen. Anzahl, Herkunft, Berechtigungen, Wartungsstatus und Ablösbarkeit müssen deshalb wie andere Softwareabhängigkeiten bewertet werden. ^{[S-199; S-009; S-043; S-067]}

Statische Websites haben meist weniger Laufzeitkomplexität, aber keine Pflichtenfreiheit

ARCHITEKTUR-SYNTHESE: Ohne serverseitige Fachlogik und Datenbank entfallen bestimmte Fehlerklassen. Inhalte, Drittressourcen, Formulare, DNS, TLS, Barrierefreiheit, Anbieterinformationen, Urheberrechte und Deployment bleiben dennoch verantwortlich zu gestalten. ^{[S-133; S-077; S-107; S-137]}

Individuelle Webanwendungen brauchen explizite fachliche Datenregeln

ENGINEERING-GRUNDSATZ: Datenbankschemata, Constraints, Mandanten- und Rollenmodelle dürfen nicht allein aus generierter Oberfläche entstehen. Verbindliche Geschäftsdaten benötigen ein führendes System, definierte Zustände, Migrationen und überprüfbare Integritätsregeln. ^{[S-002; S-001; S-063; S-023]}

Authentisierung und Autorisierung sind getrennte Kontrollen

SICHERHEITSGRUNDSATZ: Authentisierung klärt die Identität; Autorisierung entscheidet über erlaubte Aktionen und Ressourcen. Ein erfolgreicher Login beweist nicht, dass ein Nutzer jeden Datensatz lesen, ändern oder löschen darf. ^{[S-174; S-036; S-184]}

Berechtigungsprüfungen gehören auf die vertrauenswürdige Serverseite

SICHERHEITSGRUNDSATZ: Ausgeblendete Buttons und clientseitige Routen sind Bedienlogik, keine verlässliche Zugriffskontrolle. Jede geschützte Aktion muss serverseitig anhand von Identität, Ressource, Rolle und Kontext geprüft werden. ^{[S-036; S-033; S-031]}

Passwörter dürfen nicht reversibel gespeichert werden

SICHERHEITSGRUNDSATZ: Passwortspeicherung benötigt dafür geeignete, adaptive Passwort-Hashverfahren mit Salt und angemessenen Parametern. Verschlüsselung mit späterer Entschlüsselung ist kein gleichwertiger Ersatz für Passwortverifikation. ^{[S-185; S-174]}

Phishing-resistente Authentisierung ist für privilegierte Zugänge besonders wertvoll

SICHERHEITSGRUNDSATZ: WebAuthn-basierte kryptografische Authentikatoren können an die echte Website gebunden werden und reduzieren bestimmte Phishingrisiken. Kritische Administrations-, Hosting- und Registrarzugänge sollten nach Risiko stärker geschützt werden als gewöhnliche Lesekonten. ^{[S-151; S-174; S-044]}

OAuth ist ein Autorisierungsrahmen und kein fertiges Identitätssystem

TECHNISCHE GRUNDLAGE: Sicherer Einsatz verlangt passende Flows, präzise Redirect-URI-Prüfung, PKCE, State- und Tokenkontrollen sowie serverseitige Validierung. Ein JWT oder ein Social-Login-Button macht eine Integration nicht automatisch sicher. ^{[S-175; S-176; S-177; S-178]}

Sessions brauchen einen vollständigen Lebenszyklus

SICHERHEITSGRUNDSATZ: Session-IDs müssen ausreichend zufällig, geschützt übertragen, bei Zustandswechseln erneuert und bei Logout oder Ablauf invalidiert werden. Cookie-Attribute, Sitzungsdauer und parallele Sitzungen sind risikobasiert festzulegen. ^{[S-146; S-183; S-184]}

Eingabevalidierung und kontextsensitive Ausgabe sind verschiedene Aufgaben

SICHERHEITSGRUNDSATZ: Eingaben müssen gegen fachlich zulässige Formate und Grenzen geprüft werden. XSS-Abwehr erfordert zusätzlich zur Validierung die zum Ausgabekontext passende Kodierung oder sichere DOM-APIs; eine einzige globale Filterfunktion genügt nicht. ^{[S-179; S-180; S-133]}

Parametrisierte Datenbankzugriffe sind der Standard gegen SQL-Injection

SICHERHEITSGRUNDSATZ: Nutzereingaben dürfen nicht per Stringverkettung in SQL-Befehle gelangen. Prepared Statements beziehungsweise parameterisierte Abfragen trennen Daten von Befehlsstruktur; zusätzliche minimale Datenbankrechte begrenzen Folgen. ^{[S-181; S-031]}

Dateiuploads sind eine eigene Hochrisikofunktion

SICHERHEITSGRUNDSATZ: Dateiname, Erweiterung und Content-Type des Browsers sind nicht vertrauenswürdig. Erforderlich sind unter anderem erlaubte Typen, Größenlimits, neu erzeugte Dateinamen, isolierte Speicherung, Malware- beziehungsweise Inhaltsprüfung nach Risiko und kontrollierte Auslieferung. ^{[S-186; S-031]}

SSRF kann aus einer harmlosen URL-Funktion einen internen Zugriffskanal machen

SICHERHEITSGRUNDSATZ: Funktionen zum Abruf externer URLs, Webhooks, Bildimporte oder KI-Tools können interne Netze und Metadatenendpunkte erreichen. Zielprüfung, Allowlisting, Netzsegmentierung und kontrollierte Resolver-/Redirect-Behandlung sind zentrale Gegenmaßnahmen. ^{[S-187; S-032; S-037]}

CORS ist keine Autorisierung

TECHNISCHE GRUNDLAGE: CORS steuert, ob Browser JavaScript-Antworten fremder Origins zugänglich machen. Direkte Serveranfragen und bereits berechtigte Browseraktionen werden dadurch nicht grundsätzlich verhindert; API-Rechte müssen unabhängig geprüft werden. ^{[S-135; S-188; S-191]}

CSRF-Schutz bleibt bei cookiebasierten Sitzungen relevant

SICHERHEITSGRUNDSATZ: Wenn der Browser Anmeldedaten automatisch mitsendet, können fremde Seiten unerwünschte Aktionen auslösen. SameSite-Cookies helfen, ersetzen aber je nach Anwendung nicht Origin-Prüfung, CSRF-Token und sichere HTTP-Methodensemantik. ^{[S-182; S-146; S-025]}

Browser-Sicherheitsheader bilden eine zusätzliche Schutzschicht

SICHERHEITSGRUNDSATZ: CSP, HSTS, Referrer-Policy und Permissions-Policy können Angriffs- und Datenabflussflächen begrenzen. Sie müssen zur Anwendung passen, getestet und überwacht werden; Fehlkonfiguration kann Funktionen blockieren oder Scheinsicherheit erzeugen. ^{[S-147; S-149; S-150; S-189]}

Subresource Integrity schützt nur passende externe Ressourcenpfade

TECHNISCHE GRUNDLAGE: SRI kann den Browser prüfen lassen, ob eine eingebundene Ressource dem erwarteten Hash entspricht. Es hilft nicht bei dynamisch wechselnden Antworten ohne passende Integritätswerte und ersetzt keine Kontrolle über Drittanbieter, CSP oder Datenschutz. ^{[S-148; S-147; S-087]}

Webhooks müssen wie externe, potenziell feindliche Eingaben behandelt werden

INTEGRATIONSGRUNDSATZ: Signatur oder vergleichbarer Herkunftsnachweis, Replay-Schutz, Zeitgrenzen, Schema- und Größenprüfung sowie idempotente Verarbeitung sind zentrale Kontrollen. Eine öffentlich bekannte Webhook-URL ist kein Authentisierungsmerkmal. ^{[S-194; S-047; S-026]}

Retries ohne Idempotenz können Zahlungen, E-Mails und Datensätze duplizieren

RELIABILITY-GRUNDSATZ: Netzfehler lassen oft offen, ob eine Aktion ausgeführt wurde. Wiederholbare Schnittstellen benötigen Idempotenzschlüssel, deduplizierbare Ereignisse oder fachliche Transaktionsregeln; exponentielles Backoff reduziert zusätzliche Last. ^{[S-046; S-047; S-048]}

Ein Kontaktformular ist ein Datenprozess und kein bloßes Designelement

DATENSCHUTZ-SYNTHESE: Felder, Pflichtangaben, Empfänger, Transport, Speicherung, Spamabwehr, Aufbewahrung und Löschung müssen bestimmt werden. Datensparsame Formulare reduzieren Rechts-, Sicherheits- und Bearbeitungsrisiken. ^{[S-074; S-087; S-209; S-112]}

Spam-Schutz darf nicht unbemerkt neue Datenflüsse schaffen

DATENSCHUTZ-SYNTHESE: CAPTCHA- und Bot-Abwehrdienste können externe Skripte, Geräteinformationen und Drittanbieterübermittlungen einführen. Alternativen, Barrierefreiheit, Datenfluss und Rechtsgrundlage müssen vor Integration geprüft werden. ^{[S-114; S-210; S-081; S-074]}

E-Mail-Zustellung braucht Domainauthentisierung und Betriebskontrolle

TECHNISCHE GRUNDLAGE: SPF, DKIM und DMARC adressieren unterschiedliche Teile der Absenderauthentisierung und Richtliniendurchsetzung. Sie verbessern Zustellbarkeit und Missbrauchsschutz, ersetzen aber weder sicheren Inhaltstransport in allen Fällen noch Schutz kompromittierter Konten. ^{[S-204; S-205; S-206; S-209]}

MTA-STS und TLS Reporting ergänzen den Schutz zwischen Mailservern

TECHNISCHE GRUNDLAGE: MTA-STS kann für unterstützende Absender eine TLS-Policy veröffentlichen; TLS Reporting liefert Berichte zu Zustellproblemen. Die Verfahren schützen nicht den Inhalt nach Zustellung und setzen korrekte DNS- und Webbereitstellung voraus. ^{[S-207; S-208]}

Nicht jede Website braucht einen Cookie-Banner

RECHTSSTAND: Entscheidend ist nicht das Vorhandensein einer Website, sondern ob Informationen in Endeinrichtungen gespeichert oder ausgelesen werden und ob eine Ausnahme des § 25 TDDDG greift. Die anschließende Verarbeitung personenbezogener Daten ist zusätzlich nach DSGVO zu bewerten. ^{[S-080; S-081; S-084; S-074]}

Ein Cookie-Banner heilt keine unzulässige Voreinstellung

RECHTSSTAND: Einwilligungsbedürftige Technologien dürfen nicht bereits vor wirksamer Auswahl aktiviert werden. Einwilligung muss informiert, spezifisch, freiwillig und widerruflich sein; manipulative Gestaltung kann die Wirksamkeit beeinträchtigen. ^{[S-085; S-089; S-093; S-081]}

TDDDG und DSGVO beantworten zwei verschiedene Prüffragen

RECHTSSTAND: Der Zugriff auf oder die Speicherung in einem Endgerät wird zunächst nach § 25 TDDDG beurteilt. Werden dabei personenbezogene Daten verarbeitet, braucht auch die weitere Verarbeitung eine DSGVO-Rechtsgrundlage und muss Informations-, Zweckbindungs- und Sicherheitsanforderungen erfüllen. ^{[S-080; S-081; S-074]}

Datenschutzrollen folgen der tatsächlichen Entscheidungsmacht

RECHTSSTAND: Ob Kunde, Agentur, Hostinganbieter oder Toolanbieter Verantwortlicher, gemeinsam Verantwortlicher oder Auftragsverarbeiter ist, folgt aus den tatsächlich festgelegten Zwecken und Mitteln. Eine Vertragsüberschrift kann die reale Rollenverteilung nicht beliebig ändern. ^{[S-086; S-074]}

Drittlandtransfer ist eine Architekturfrage

RECHTSSTAND: Externe Fonts, Analytics, Support, Payment, CDN oder KI-APIs können Empfänger außerhalb des EWR einbeziehen. Angemessenheitsbeschluss, Standardvertragsklauseln und ergänzende Prüfungen müssen zum konkreten Empfänger und Datenfluss passen. ^{[S-091; S-090; S-092; S-074]}

Serverlogs haben keinen pauschalen gesetzlichen Universalzeitraum

DATENSCHUTZ-SYNTHESE: Zweck, Datenumfang, Zugriff und Aufbewahrung sind systemspezifisch festzulegen. Sicherheits- und Betriebsinteressen können Protokollierung rechtfertigen; unbegrenzte Vorratsspeicherung ohne Zweck- und Löschkonzept ist damit nicht automatisch begründet. ^{[S-074; S-035; S-012]}

Impressumsangaben beruhen heute auf dem DDG, nicht mehr dem TMG

RECHTSSTAND: Für geschäftsmäßige, in der Regel gegen Entgelt angebotene digitale Dienste gelten die allgemeinen Informationspflichten des § 5 DDG. Je nach redaktionellem Inhalt können zusätzliche medienrechtliche Angaben hinzukommen. ^{[S-076; S-077; S-095]}

Alte Verweise auf TMG, TTDSG und die EU-OS-Plattform müssen geprüft werden

AKTUALITÄTSBEFUND: Das DDG ersetzte das TMG, das TDDDG trägt die heutige Bezeichnung des früheren TTDSG und die europäische ODR-Plattform wurde eingestellt. Vorlagen und Footertexte aus älteren Projekten können daher sachlich oder rechtlich überholt sein. ^{[S-076; S-079; S-124]}

Bilder, Texte, Logos und generierte Inhalte brauchen eine Rechteprüfung

RECHTSSTAND: Technische Abrufbarkeit oder KI-Erzeugung beweist keine Nutzungsberechtigung. Urheber-, Bildnis- und Kennzeichenrechte sowie Lizenzbedingungen müssen für konkrete Nutzung, Bearbeitung, Dauer, Medien und Weitergabe geprüft werden. ^{[S-096; S-097; S-098]}

Barrierefreiheit beginnt bei Semantik und Bedienlogik

ACCESSIBILITY-GRUNDSATZ: Überschriftenstruktur, Beschriftungen, Tastaturbedienung, Fokus, Alternativtexte, Fehlermeldungen und ausreichende Wahrnehmbarkeit müssen im Entwurf und Code berücksichtigt werden. Ein späteres Overlay ist kein belastbarer Ersatz für zugängliche Komponenten. ^{[S-107; S-112; S-113; S-110]}

ARIA ergänzt HTML und repariert kein beliebiges Markup

TECHNISCHE GRUNDLAGE: Native HTML-Elemente bringen Semantik und Verhalten mit. ARIA kann Rollen, Zustände und Beziehungen ergänzen, erfordert aber korrekte Implementierung und darf die native Semantik nicht unnötig ersetzen. ^{[S-133; S-110; S-111]}

WCAG 2.2 ist ein technischer Referenzstandard, aber nicht pauschal die alleinige Rechtsnorm

RECHTLICHE EINORDNUNG: Welche Anforderungen rechtlich verbindlich sind, hängt vom anwendbaren Gesetz, der Dienstleistung, dem Vertrag und gegebenenfalls referenzierten Normen ab. WCAG 2.2 liefert international anerkannte Erfolgskriterien und Testgrundlagen. ^{[S-107; S-109; S-099; S-106]}

Das BFSG gilt nicht unterschiedslos für jede Website

RECHTSSTAND: Das Gesetz erfasst bestimmte Produkte und Dienstleistungen, darunter E-Commerce-Dienstleistungen. Kleinstunternehmen, die Dienstleistungen anbieten, sind nach § 3 BFSG ausgenommen; konkrete Reichweite und Übergangsregeln sind im Einzelfall zu prüfen. ^{[S-099; S-100; S-101; S-104]}

Barrierefreie Authentisierung und Zahlung sind Teil des E-Commerce-Prozesses

RECHTSSTAND: Die BFSG-Verordnung adressiert bei E-Commerce-Dienstleistungen unter anderem Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen. Ein zugänglicher Produkttext allein reicht daher nicht, wenn Checkout oder Login unbedienbar bleiben. ^{[S-103; S-104; S-107]}

SEO beginnt mit crawlbaren, verständlichen und nützlichen Inhalten

ANBIETERDOKUMENTATION: Suchmaschinen benötigen erreichbare URLs, eindeutige Inhalte, interne Verlinkung und verarbeitbares Markup. JavaScript kann indexierbar sein, erhöht aber Rendering- und Fehlerkomplexität; wichtige Inhalte und Links sollten robust bereitgestellt werden. ^{[S-163; S-166; S-133; S-134]}

robots.txt ist keine Zugriffskontrolle

TECHNISCHE GRUNDLAGE: Das Robots Exclusion Protocol gibt kooperierenden Crawlern Hinweise. Es verhindert weder direkten Zugriff noch Indizierung über andere Signale in jedem Fall und darf keine geheimen Pfade schützen. ^{[S-152; S-167; S-036]}

Eine Sitemap garantiert keine Indexierung

ANBIETERDOKUMENTATION: Sitemaps informieren Suchmaschinen über URLs und Metadaten. Aufnahme in den Index und Ranking bleiben von Crawling, Qualität, Duplikaten, technischen Signalen und Suchmaschinenentscheidungen abhängig. ^{[S-153; S-168; S-163]}

Strukturierte Daten müssen sichtbaren Inhalt korrekt beschreiben

ANBIETERDOKUMENTATION: Schema.org stellt Vokabular bereit; Suchmaschinen definieren zusätzliche Darstellungsregeln. Markup darf keine erfundenen Bewertungen, Preise oder Eigenschaften enthalten und garantiert keine Rich Results. ^{[S-154; S-169; S-164]}

KI-generierter Inhalt ist nicht automatisch Suchmaschinen-Spam

ANBIETERDOKUMENTATION: Nach aktueller Google-Dokumentation ist der Einsatz von Automatisierung oder KI nicht grundsätzlich regelwidrig. Problematisch ist vor allem massenhaft erzeugter Inhalt, der primär Rankings manipulieren soll; Qualität, Originalität und Nutzerwert bleiben entscheidend. ^{[S-165; S-164; S-163]}

Core Web Vitals sind Nutzersignale, kein vollständiges Qualitätsmodell

MESSGRUNDSATZ: LCP, INP und CLS adressieren Laden, Interaktivität und visuelle Stabilität. Sicherheit, Barrierefreiheit, fachliche Korrektheit, Conversion, Serverzuverlässigkeit und Inhaltsqualität müssen zusätzlich gemessen werden. ^{[S-170; S-171; S-172; S-001]}

Lighthouse ist ein Diagnosewerkzeug und keine Abnahme allein

MESSGRUNDSATZ: Labortests liefern reproduzierbare Hinweise, bilden aber reale Geräte, Netzwerke, Datenmengen und Nutzerpfade nur begrenzt ab. Feldmessung, manuelle Prüfung und fachliche Tests müssen automatisierte Scores ergänzen. ^{[S-172; S-170; S-028]}

Search Console zeigt Suchsystemdaten, nicht den gesamten Geschäftserfolg

MESSGRUNDSATZ: Impressionen, Klicks, Indexierungs- und technische Hinweise helfen im Betrieb. Leads, Umsatz, qualifizierte Anfragen, Nutzerzufriedenheit und Offline-Erfolg benötigen eigene Messung und Datenschutzbewertung. ^{[S-173; S-074; S-001]}

E-Commerce braucht mehr als Produktseite und Warenkorb

RECHTSSTAND: Vorvertragliche Informationen, Bestellschritt, Preisangaben, Widerruf, Zahlungsprozess, Produktsicherheit, Streitbeilegungsinformationen und Nachweis der Bestellung bilden ein zusammenhängendes System. Der konkrete Pflichtenkatalog hängt von Angebot und Zielgruppe ab. ^{[S-115; S-116; S-119; S-121; S-125]}

Der Bestellbutton ist rechtlich und technisch ein kritischer Kontrollpunkt

RECHTSSTAND: Bei zahlungspflichtigen Verbraucherverträgen im elektronischen Geschäftsverkehr verlangt § 312j BGB eine eindeutige Gestaltung des Bestellvorgangs. UI-Text, Zusammenfassung, Preisberechnung und ausgelöste Transaktion müssen konsistent sein. ^{[S-116; S-119; S-127]}

Widerrufslogik gehört in Datenmodell und Prozess

RECHTSSTAND: Information, Fristbeginn, Ausnahmen, Erklärung und Erstattung können vom Leistungs- und Liefermodell abhängen. Die Website muss nicht nur Text anzeigen, sondern erforderliche Bestell- und Kommunikationsnachweise für den Prozess bereitstellen. ^{[S-117; S-118; S-119; S-120]}

Die frühere EU-OS-Verlinkung ist kein aktueller Standardbaustein mehr

RECHTSSTAND: Die Verordnung zur ODR-Plattform wurde aufgehoben und die Plattform eingestellt. Unabhängig davon können Informationspflichten nach dem Verbraucherstreitbeilegungsgesetz fortbestehen; beide Themen dürfen nicht vermischt werden. ^{[S-124; S-122; S-123]}

Online-Produktangebote müssen die Produktsicherheitsinformationen mitdenken

RECHTSSTAND: Die GPSR enthält für Fernabsatzangebote konkrete Informationsanforderungen, etwa zur Identifikation des Produkts und zu Hersteller- beziehungsweise verantwortlichen Wirtschaftsakteuren. Shopdatenmodell und Lieferantenprozess müssen diese Angaben tragen können. ^{[S-125; S-128]}

Starke Kundenauthentifizierung ist Teil des Zahlungsökosystems

RECHTSSTAND: PSD2 und die technische Regulierungsnorm setzen Anforderungen an starke Kundenauthentifizierung und sichere Kommunikation. Händler integrieren dies meist über Zahlungsdienstleister, bleiben aber für korrekte Checkout- und Vertragslogik verantwortlich. ^{[S-129; S-130; S-116]}

Ausgelagerte Zahlungsseiten können den PCI-Umfang reduzieren, nicht jede Verantwortung beseitigen

SICHERHEITSGRUNDSATZ: Wie stark PCI-DSS-Pflichten reduziert werden, hängt vom Integrationsmodell und den tatsächlich berührten Kartendaten ab. Manipulierte Shopseiten, Zugangsdaten, Weiterleitungen und Drittanbieter-Skripte bleiben relevante Risiken. ^{[S-131; S-132; S-032]}

APIs brauchen Verträge, Fehlerformate und Versionsregeln

INTEGRATIONSGRUNDSATZ: OpenAPI und JSON Schema können Request- und Response-Strukturen dokumentieren. HTTP-Status, Problem Details, Idempotenz und Kompatibilität müssen zusätzlich fachlich definiert und getestet werden. ^{[S-023; S-024; S-025; S-026]}

GraphQL verschiebt, aber beseitigt API-Risiken nicht

SICHERHEITSGRUNDSATZ: Flexible Abfragen können Datenübertragung verbessern, schaffen aber Risiken durch komplexe Queries, übermäßige Datenfreigabe und objektbezogene Autorisierung. Schema, Tiefen- und Kostenlimits sowie Rechteprüfung bleiben notwendig. ^{[S-192; S-033; S-036]}

Backups sind erst nach einem erfolgreichen Restore belegt

BETRIEBSGRUNDSATZ: Eine vorhandene Datei oder Providerfunktion beweist nicht, dass Daten, Schlüssel, Konfiguration und Abhängigkeiten innerhalb des benötigten Zeitfensters wiederhergestellt werden können. Restore-Tests und dokumentierte Wiederanlaufziele sind unverzichtbar. ^{[S-014; S-015; S-063; S-203]}

Ein Code-Rollback setzt Daten und externe Wirkungen nicht automatisch zurück

BETRIEBS-SYNTHESE: Datenbankmigrationen, versandte E-Mails, Zahlungen und Drittanbieteraktionen können irreversibel oder nur kompensierbar sein. Releases benötigen deshalb Vorwärts-/Rückwärtskompatibilität, Sicherung und fachliche Kompensationspfade. ^{[S-051; S-048; S-064]}

Logs müssen nützlich sein, ohne Geheimnisse und unnötige personenbezogene Daten zu sammeln

OBSERVABILITY-GRUNDSATZ: Sicherheits- und Betriebsanalyse braucht Zeitstempel, Ereigniskontext und Korrelation. Passwörter, Tokens, vollständige Zahlungsdaten und sensible Inhalte gehören nicht in Logs; Zugriff, Integrität, Aufbewahrung und Löschung sind zu regeln. ^{[S-035; S-060; S-074]}

Monitoring muss Nutzerwirkung und nicht nur Serverzustand erfassen

BETRIEBSGRUNDSATZ: Eine grüne CPU-Anzeige beweist nicht, dass Login, Checkout, Formularversand oder Drittanbieterintegration funktionieren. Serviceindikatoren, synthetische Nutzerpfade, Fehlerbudgets und fachliche Ereignisse müssen zusammengeführt werden. ^{[S-052; S-053; S-057]}

Sicherheitsupdates brauchen Inventar und Testpfad

WARTUNGSGRUNDSATZ: Ohne Kenntnis von Laufzeiten, Plugins, Bibliotheken, Images und Diensten lässt sich Betroffenheit nicht zuverlässig bewerten. Automatisierte Hinweise helfen, müssen aber mit Staging, Tests, Freigabe und Notfallpatching verbunden sein. ^{[S-066; S-067; S-068; S-009]}

Unterstützte Laufzeitversionen sind ein bewegliches Betriebsziel

REFRESH-BEFUND: PHP-, Node.js-, Browser- und CMS-Versionen wechseln ihren Supportstatus. Ein Produkt braucht deshalb eine regelmäßig aktualisierte Kompatibilitätsmatrix statt einer einmaligen Versionsangabe im Projektabschluss. ^{[S-200; S-201; S-198; S-202]}

Automatisierte Security-Scans ersetzen keine manuelle und fachliche Prüfung

TESTGRUNDSATZ: Scanner finden bestimmte Muster und bekannte Schwachstellen. Geschäftslogik, Autorisierungsgrenzen, Mandantentrennung, Datenschutzfluss und missbräuchliche Prozessketten benötigen gezielte Tests und Review. ^{[S-030; S-031; S-013; S-033]}

KI kann Entwicklung beschleunigen und zugleich Fehler plausibel verpacken

FORSCHUNGSBEFUND: Studien zeigen unterschiedliche Effekte je nach Aufgabe, Erfahrung und Setting. Sicherheitsforschung dokumentiert unsichere Vorschläge; eine aktuelle kontrollierte Studie mit erfahrenen Open-Source-Entwicklern fand in ihrem Setting sogar längere Bearbeitungszeiten. Pauschale Produktivitätsversprechen sind daher nicht belastbar. ^{[S-212; S-213; S-211; S-214]}

Generierter Code braucht dieselben Qualitätsgates wie menschlicher Code

ENGINEERING-GRUNDSATZ: Review, Tests, Abhängigkeitsprüfung, Secret-Scanning, Sicherheitsanforderungen und nachvollziehbare Freigabe dürfen nicht entfallen, weil der Code von einem Modell stammt. Bei unklarem Verständnis muss der Änderungsumfang reduziert oder verworfen werden. ^{[S-010; S-009; S-018; S-213]}

KI-Funktionen erweitern das Webbedrohungsmodell

KI-SICHERHEIT: Ein Chatbot oder Agent verarbeitet potenziell feindliche Inhalte, kann interne Daten abrufen und Tools auslösen. Prompt Injection, Datenabfluss, übermäßige Berechtigungen, unkontrollierte Ausgaben und Kostenlimits müssen als eigene Risiken behandelt werden. ^{[S-037; S-038; S-094; S-010]}

Nutzer müssen bei bestimmten KI-Interaktionen transparent informiert werden

RECHTSSTAND: Artikel 50 AI Act enthält Transparenzpflichten für bestimmte Systeme, darunter direkte Interaktion mit natürlichen Personen, soweit keine offensichtliche Erkennbarkeit oder Ausnahme greift. Seit 2. August 2026 ist dieser Teil der Verordnung grundsätzlich anwendbar; konkrete Rollen und Ausnahmen sind zu prüfen. ^[S-075]

Eine KI-generierte Datenschutzerklärung ist kein belastbares Dateninventar

DATENSCHUTZ-SYNTHESE: Datenschutzhinweise müssen den tatsächlichen Diensten, Zwecken, Empfängern, Rechtsgrundlagen, Speicherdauern und Betroffenenrechten entsprechen. Diese Tatsachen können nur aus realer Konfiguration, Verträgen und Prozessen erhoben werden. ^{[S-074; S-086; S-081]}

Abnahme muss sichtbares Verhalten und Betriebsnachweise umfassen

ABNAHMEGRUNDSATZ: Screenshots und eine Demo reichen bei dynamischen Systemen nicht. Abnahmekriterien sollten unter anderem Browser- und Gerätepfade, Rechte, Fehlerfälle, Performance, Barrierefreiheit, Datenschutzkonfiguration, Backup/Restore und Übergabedokumentation abdecken. ^{[S-002; S-001; S-031; S-107]}

Kundenfreigabe ersetzt keine fachkundige Warnung vor erkannten Risiken

PRAXIS-SYNTHESE: Freigaben dokumentieren Entscheidungen, beseitigen aber nicht automatisch technische oder rechtliche Risiken. Erkannte Sicherheits-, Datenschutz- oder Funktionsmängel sollten konkret beschrieben, mit Folgen versehen und entweder behoben oder ausdrücklich eskaliert werden. ^{[S-003; S-009; S-011]}

Wartung muss als Leistung und Grenze ausdrücklich vereinbart werden

PRAXIS-SYNTHESE: Ohne Regelung bleibt unklar, wer Updates bewertet, Backups prüft, Zertifikate überwacht, Inhalte ändert, Incidents bearbeitet und Drittanbieteränderungen auffängt. Ein einmaliger Werkumfang und ein laufender Betriebsservice sind organisatorisch zu trennen. ^{[S-004; S-054; S-056; S-198]}

Übergabe muss echte Kontrolle und Wiederherstellbarkeit übertragen

ÜBERGABEGRUNDSATZ: Quellcode ohne Buildanweisung, Domain ohne Registrarzugang oder Backup ohne Schlüssel ist keine vollständige Übergabe. Erforderlich sind Konten, Rollen, Dokumentation, Datenexport, Secrets-Transfer, Lizenzübersicht, offene Risiken und ein geprüfter Start- beziehungsweise Restorepfad. ^{[S-004; S-022; S-014; S-156]}

Stilllegung ist ein geplanter Lebenszyklusabschnitt

LEBENSZYKLUSGRUNDSATZ: Am Projektende müssen Domain, Weiterleitungen, Datenexport, Aufbewahrung, Löschung, Zugänge, Zertifikate, Zahlungs- und Drittanbieterverträge sowie Nutzerkommunikation geregelt werden. Einfaches Abschalten kann Datenverlust, Sicherheitsrisiken und geschäftliche Unterbrechung verursachen. ^{[S-074; S-015; S-157; S-004]}

Reale Vorfälle zeigen wiederkehrende Muster statt exotischer Einzelfehler

FALLSYNTHESE: Die dokumentierten Fälle reichen von ungepatchter Software und Drittanbieter-Skripten über fehlerhafte Zertifikatsprüfung bis zu Datenlöschung und problematischen Rollouts. Wiederkehrende Lehre ist die Kombination aus Inventar, Begrenzung, Tests, Monitoring, Restore und klarer Verantwortung. ^{[S-216; S-219; S-220; S-069]}

Technische Perfektion ist kein realistischer Abnahmemaßstab

SCHLUSSBEFUND: Ein verantwortetes System braucht bekannte Risiken, priorisierte Kontrollen und dokumentierte Restunsicherheit. Ziel ist nicht Fehlerfreiheit, sondern ein zur Wirkung passendes, überprüfbares und wiederherstellbares Qualitätsniveau. ^{[S-003; S-001; S-011; S-050]}

33 Praxisfelder von Anforderung bis Stilllegung

PRAXISRAHMEN: Jedes Praxisfeld enthält Ziel, belastbare Grundsätze, Mindestnachweise und Warnsignale. Die Mindestnachweise sind kein universeller Rechtskatalog, sondern ein risikobasierter Arbeitsstandard für verantwortete Projekte. ^{[S-003; S-001; S-031; S-050]}

Anforderung und Wahl des Webtyps

Die erste Architekturentscheidung ist nicht das Framework, sondern die Frage, ob Information, redaktionelle Pflege oder eine transaktionale Fachanwendung benötigt wird. Risiko und Betriebsaufwand steigen typischerweise mit Daten, Rollen, Integrationen und irreversiblen Aktionen. ^{[S-002; S-001; S-003]}

Grundsätze

• Anforderungen als beobachtbare Nutzeraufgaben, Datenflüsse und Qualitätsziele formulieren. ^{[S-002; S-001]}
• Regelmäßig prüfen, ob eine statische Lösung oder vorhandene Standardsoftware den Zweck erfüllt. ^{[S-005; S-003]}

Mindestnachweis

• Zielgruppe, Inhalte, Änderungsfrequenz, Rollen, Datenarten, Integrationen und Verfügbarkeitsbedarf dokumentieren. ^[S-002]
• Für jede Wunschfunktion Nutzen, Fehlerfolge, Betreiber und Wartungsbedarf benennen. ^{[S-003; S-050]}

Warnsignale

• Technologie wird vor dem Problem festgelegt oder ausschließlich nach KI-Demo gewählt. ^{[S-006; S-211]}
• Login, Zahlung oder personenbezogene Daten werden als nachträgliches Detail behandelt. ^{[S-074; S-031]}

Informationsarchitektur, Inhalte und redaktionelle Verantwortung

Navigation, Seitenstruktur, Benennung und Inhaltsverantwortung bestimmen Nutzbarkeit, Auffindbarkeit und rechtliche Aktualität. KI kann Varianten erzeugen, aber keine gültigen Unternehmensdaten oder Nutzungsrechte garantieren. ^{[S-133; S-163; S-107; S-096]}

Grundsätze

• Inhalte nach Nutzeraufgaben und nicht nach interner Organisationsstruktur ordnen. ^{[S-163; S-107]}
• Für jede Seite einen fachlichen Owner, Prüftermin und Archivierungsweg festlegen. ^{[S-004; S-074]}

Mindestnachweis

• Überschriftenhierarchie, Linktexte, Alternativtexte und Kontaktwege semantisch korrekt anlegen. ^{[S-133; S-113; S-107]}
• Quelle, Lizenz, Freigabe und Aktualitätsstand von Texten, Bildern und Logos dokumentieren. ^{[S-096; S-097; S-098]}

Warnsignale

• Platzhalter, erfundene Referenzen oder ungeprüfte KI-Aussagen gelangen in Produktion. ^{[S-165; S-096]}
• Rechtstexte und Ansprechpartner haben keinen Aktualisierungsverantwortlichen. ^{[S-077; S-074]}

Statische Website und statischer Site-Generator

Eine statische Website liefert vorerzeugte Dokumente und kann Laufzeitkomplexität reduzieren. Formulare, Suche, Analytics und Drittinhalte können dennoch dynamische Datenflüsse und Betriebsabhängigkeiten einführen. ^{[S-133; S-136; S-025; S-074]}

Grundsätze

• Dynamik nur dort ergänzen, wo sie einen nachweisbaren Nutzer- oder Geschäftsprozess trägt. ^{[S-001; S-003]}
• Build, Deployment und externe Ressourcen reproduzierbar dokumentieren. ^{[S-022; S-041]}

Mindestnachweis

• HTTPS, Fehlerseiten, Redirects, Sitemap, robots.txt und Monitoring konfigurieren. ^{[S-137; S-168; S-152; S-052]}
• Kontakt- und Newsletterprozesse als separate Datenflüsse erfassen. ^{[S-074; S-209]}

Warnsignale

• Statisch wird fälschlich mit wartungsfrei oder rechtlich risikolos gleichgesetzt. ^{[S-077; S-107]}
• Build-Abhängigkeiten bleiben jahrelang ungepflegt, weil der Server keinen Anwendungscode ausführt. ^{[S-067; S-066]}

CMS, Themes und Plugins

Ein CMS eignet sich für häufige redaktionelle Änderungen und Rollen, bringt aber eine dauerhaft zu wartende Softwarelieferkette mit. Jede Erweiterung kann Daten, Oberfläche und Sicherheitsmodell verändern. ^{[S-196; S-197; S-198; S-199]}

Grundsätze

• So wenig Erweiterungen wie möglich und so viele wie fachlich nötig einsetzen. ^{[S-199; S-009]}
• Redaktions-, Administrations- und Deploymentrechte trennen. ^{[S-197; S-036]}

Mindestnachweis

• Updatekanal, Staging, Backup, Restoretest und Wartungsfenster definieren. ^{[S-198; S-014]}
• Plugininventar mit Zweck, Anbieter, Datenflüssen, Lizenz, Version und Ersatzoption führen. ^{[S-009; S-074]}

Warnsignale

• Ungepflegte Premiumplugins ohne Updatezugang oder unbekannte Downloadquellen. ^{[S-066; S-196]}
• Produktionsänderungen direkt im Theme-Editor ohne Versionierung und Rückfallweg. ^{[S-007; S-017]}

Individuelle Webanwendung und Fachlogik

Eine individuelle Anwendung ist gerechtfertigt, wenn Standardsoftware zentrale Prozesse nicht ausreichend abbildet. Sie erzeugt volle Verantwortung für Datenmodell, Autorisierung, Fehlerfälle, Migrationen, Schnittstellen und Support. ^{[S-002; S-001; S-023; S-031]}

Grundsätze

• Fachliche Zustände und erlaubte Übergänge explizit modellieren. ^{[S-002; S-024]}
• Verbindliche Regeln deterministisch implementieren; KI nur für passende unstrukturierte Teilaufgaben verwenden. ^{[S-010; S-001]}

Mindestnachweis

• Datenmodell, Mandanten-, Rollen- und Löschkonzept vor dem UI-Feinschliff prüfen. ^{[S-074; S-036]}
• Fehlerobjekte, Timeouts, Retry- und Kompensationspfade spezifizieren. ^{[S-026; S-046; S-047]}

Warnsignale

• Die Datenbank entsteht ausschließlich aus automatisch generiertem CRUD-Code. ^{[S-002; S-032]}
• Es gibt keinen Owner für Betrieb, Incident und Datenmigration. ^{[S-012; S-054]}

Domain, Registrar und DNS

Domainkontrolle bestimmt Erreichbarkeit, Zertifikatsvalidierung, E-Mail und Markenwirkung. Kundenprojekte brauchen dokumentierte Inhaberschaft, sichere Zugänge und einen transferfähigen Notfallweg. ^{[S-155; S-156; S-157; S-158]}

Grundsätze

• Die wirtschaftlich berechtigte Organisation soll die Domainkontrolle nachvollziehbar halten. ^{[S-158; S-155]}
• DNS-Änderungen wie Produktionsänderungen behandeln: Review, Dokumentation und Rückfall. ^{[S-142; S-011]}

Mindestnachweis

• Registrar-MFA, Wiederherstellungskontakte und aktuelle Organisationsdaten einrichten. ^{[S-174; S-155]}
• Zonenexport, TTL-Plan, CAA/DNSSEC-Entscheidung und Providerwechsel dokumentieren. ^{[S-144; S-145; S-156]}

Warnsignale

• Domain läuft privat auf einen freien Mitarbeiter oder eine nicht mehr zugängliche Agenturmail. ^{[S-157; S-158]}
• DNS-Einträge werden ohne Inventar oder Vier-Augen-Prüfung geändert. ^{[S-011; S-003]}

Hosting, Cloud und Umgebungen

Hosting umfasst mehr als Speicherplatz: Regionen, Backups, Netzwerk, Identitäten, Protokolle, Skalierung, Support und Ausstieg müssen zum Risiko passen. Provider und Betreiber teilen sich Aufgaben. ^{[S-195; S-016; S-011; S-015]}

Grundsätze

• Verantwortungsmatrix für Plattform, Anwendung, Daten, Identitäten und Backups erstellen. ^{[S-195; S-011]}
• Entwicklung, Staging und Produktion technisch und mit Daten trennen. ^{[S-020; S-009]}

Mindestnachweis

• Region, Unterauftragnehmer, Servicegrenzen, Export und Löschung dokumentieren. ^{[S-074; S-086]}
• Ressourcenlimits, Statusüberwachung und Notfallzugang konfigurieren. ^{[S-052; S-014]}

Warnsignale

• Ein Managed Service wird als vollständig verantwortungsfrei behandelt. ^[S-195]
• Testsystem nutzt echte Kundendaten ohne Notwendigkeit und Schutzkonzept. ^{[S-074; S-087]}

TLS, Zertifikate und Browsertransport

HTTPS ist die Mindestbasis für vertrauliche Webkommunikation. Betrieb umfasst Zertifikatsausstellung, Erneuerung, sichere Protokolle, Redirects, HSTS und Überwachung. ^{[S-137; S-141; S-161; S-162]}

Grundsätze

• Zertifikate automatisiert erneuern, aber Ablauf und Fehler dennoch überwachen. ^{[S-141; S-159]}
• TLS-Konfiguration regelmäßig gegen aktuelle Empfehlungen prüfen. ^{[S-161; S-162]}

Mindestnachweis

• HTTP konsequent auf HTTPS umleiten und gemischte Inhalte beseitigen. ^{[S-140; S-193]}
• CAA- und HSTS-Einsatz kontrolliert testen; Subdomains berücksichtigen. ^{[S-145; S-140]}

Warnsignale

• Zertifikate liegen auf Einzelpersonen-Konten ohne Alarmierung oder Übergabe. ^{[S-011; S-004]}
• HTTPS wird als Beweis für sichere Anwendung und Datenschutzkonformität dargestellt. ^{[S-032; S-074]}

Datenmodell, Datenbank und Migration

Das Datenmodell trägt Geschäftsregeln, Rechte und Aufbewahrung. Schemaänderungen müssen mit Anwendungsversion, Datenmigration, Rückfall und Sicherung abgestimmt werden. ^{[S-002; S-063; S-064; S-008]}

Grundsätze

• Constraints und Transaktionen dort nutzen, wo Datenintegrität verbindlich ist. ^{[S-001; S-063]}
• Migrationen klein, versioniert und mit Vorwärts-/Rückwärtsstrategie planen. ^{[S-007; S-051]}

Mindestnachweis

• Vor riskanten Migrationen Backup und Restore beziehungsweise PITR prüfen. ^{[S-064; S-014]}
• Datenklassifizierung, Löschung und Export im Schema mitdenken. ^{[S-074; S-087]}

Warnsignale

• Produktionsschema wird manuell verändert, ohne Migrationshistorie. ^{[S-009; S-007]}
• KI-generierte Migration wird ohne Test auf reale Datenverteilung ausgeführt. ^{[S-010; S-211]}

Login, Identität und Kontowiederherstellung

Ein sicherer Login umfasst Registrierung, Verifikation, Authentisierung, Rate Limits, Sitzungen, MFA, Recovery, Sperre und Löschung. Der Recovery-Weg ist häufig der schwächste Zugang. ^{[S-174; S-184; S-183; S-151]}

Grundsätze

• Authentisierungsstärke am Schadenspotenzial des Kontos ausrichten. ^{[S-174; S-003]}
• Recovery mindestens so kontrolliert gestalten wie den normalen Login. ^{[S-184; S-174]}

Mindestnachweis

• Passwörter sicher hashen, Loginversuche begrenzen und Sessionwechsel korrekt behandeln. ^{[S-185; S-183]}
• Administratoren und Betreiberzugänge mit phishing-resistenter MFA schützen, soweit praktikabel. ^{[S-151; S-174]}

Warnsignale

• Passwort-Reset offenbart, ob eine E-Mail registriert ist, oder setzt ohne zusätzliche Kontrolle zurück. ^[S-184]
• Gemeinsam genutzte Administratorkonten verhindern individuelle Nachvollziehbarkeit. ^{[S-035; S-016]}

Autorisierung, Mandanten und Objektzugriff

Autorisierung muss für jede geschützte Aktion und jedes Objekt serverseitig geprüft werden. Mehrmandantenfähigkeit verschärft die Anforderungen an Filter, Schlüssel und Tests. ^{[S-036; S-033; S-031]}

Grundsätze

• Deny-by-default und minimale Rechte als Ausgangspunkt verwenden. ^{[S-036; S-016]}
• Mandantenkontext nicht allein aus vom Client kontrollierten Parametern übernehmen. ^{[S-033; S-179]}

Mindestnachweis

• Cross-Tenant-Tests für Lesen, Ändern, Export, Suche, Dateien und Hintergrundjobs automatisieren. ^{[S-030; S-031]}
• Privilegierte Aktionen mit Auditkontext und gegebenenfalls erneuter Bestätigung versehen. ^{[S-035; S-174]}

Warnsignale

• UI versteckt Funktionen, API akzeptiert aber beliebige Objekt-IDs. ^[S-033]
• Administrator bedeutet pauschal Zugriff auf alle Kundendaten ohne Zweckbegrenzung. ^{[S-074; S-036]}

Formulare, Leadprozesse und E-Mail

Formulare verbinden Browser, Webserver, E-Mail und oft CRM. Jede Station beeinflusst Datenschutz, Zustellbarkeit, Spamrisiko und Nachvollziehbarkeit. ^{[S-074; S-209; S-204; S-112]}

Grundsätze

• Nur Daten abfragen, die für Bearbeitung und Anschlussprozess erforderlich sind. ^{[S-074; S-087]}
• Nutzer erhalten klare Erfolg-, Fehler- und Datenschutzinformationen. ^{[S-112; S-107]}

Mindestnachweis

• Serverseitige Validierung, Rate Limits, Spamkontrolle und sichere Empfängerlogik implementieren. ^{[S-179; S-210; S-031]}
• SPF, DKIM, DMARC und Bounce-/Fehlerüberwachung für Versanddomain betreiben. ^{[S-204; S-205; S-206]}

Warnsignale

• Formulardaten werden nur per unverschlüsselter oder falsch adressierter E-Mail weitergereicht. ^[S-209]
• Erfolgsmeldung erscheint, obwohl CRM oder E-Mail-Auftrag fehlgeschlagen ist. ^{[S-026; S-058]}

Dateiuploads und Dokumentverarbeitung

Uploads führen fremde Binärdaten in die Infrastruktur. Vorschau, OCR, Konvertierung und KI-Analyse erweitern die Verarbeitungskette und mögliche Angriffsfläche. ^{[S-186; S-187; S-010; S-074]}

Grundsätze

• Uploads außerhalb ausführbarer Webpfade und mit neuem internen Namen speichern. ^[S-186]
• Verarbeitung asynchron, begrenzt und isoliert ausführen. ^{[S-027; S-187]}

Mindestnachweis

• Typ, Größe, Anzahl, Entpacktiefe und erlaubte Inhalte begrenzen. ^{[S-186; S-179]}
• Aufbewahrung, Zugriff, Löschung und fehlgeschlagene Verarbeitung dokumentieren. ^{[S-074; S-087]}

Warnsignale

• Originaldateiname bestimmt direkt Speicherpfad oder Downloadheader. ^[S-186]
• Dokumentinhalt wird ungeprüft als vertrauenswürdige Instruktion an einen KI-Agenten gegeben. ^{[S-037; S-038]}

APIs, Webhooks und Drittintegrationen

Integrationen koppeln Verfügbarkeit, Datenqualität, Berechtigungen und Versionen mehrerer Systeme. Verträge und Fehlerpfade sind wichtiger als die reine Happy-Path-Demo. ^{[S-023; S-024; S-026; S-194]}

Grundsätze

• Schnittstellen minimal, versioniert und mit klaren Verantwortungsgrenzen entwerfen. ^{[S-023; S-008]}
• Externe Antworten und Ereignisse immer als untrusted input validieren. ^{[S-179; S-194]}

Mindestnachweis

• Timeout, Retry, Idempotenz, Rate Limit und Dead-Letter-/Fehlerprozess definieren. ^{[S-046; S-047; S-026]}
• Secrets, Scopes und Widerruf pro Integration trennen. ^{[S-034; S-177]}

Warnsignale

• API-Schlüssel wird im Browser oder Repository ausgeliefert. ^{[S-034; S-019]}
• Webhookfehler führen still zu Datenverlust ohne Alarm und Wiederholung. ^{[S-058; S-053]}

Cookies, Local Storage und Consent Management

Endgerätezugriffe umfassen mehr als Cookies. Consent Management muss tatsächliche Skripte blockieren, Wahl dokumentieren und Widerruf technisch umsetzen. ^{[S-080; S-084; S-081; S-082]}

Grundsätze

• Technologien nach Zweck und technischer Notwendigkeit klassifizieren, nicht nach Anbieternamen. ^{[S-081; S-084]}
• TDDDG-Prüfung und DSGVO-Folgeprüfung getrennt dokumentieren. ^{[S-080; S-074]}

Mindestnachweis

• Einwilligungsbedürftige Ressourcen vor Zustimmung blockieren und Widerruf leicht zugänglich machen. ^{[S-085; S-089]}
• Bannerkonfiguration bei jeder Skript- oder Anbieteränderung erneut testen. ^{[S-081; S-030]}

Warnsignale

• Alle Cookies werden pauschal als technisch notwendig bezeichnet. ^[S-081]
• Ablehnen ist schwerer als Zustimmen oder Einwilligung wird durch Scrollen angenommen. ^{[S-089; S-093]}

Analytics, Tag Manager und Drittinhalte

Analytics, Karten, Videos, Fonts und Chatdienste können Cookies, Gerätezugriffe, personenbezogene Daten und Drittlandtransfers auslösen. Ein Tag Manager erhöht Veränderungsgeschwindigkeit und Governancebedarf. ^{[S-074; S-080; S-091; S-092]}

Grundsätze

• Datenerhebung aus einer konkreten Entscheidungsfrage ableiten und minimieren. ^{[S-074; S-087]}
• Drittressourcen möglichst kontrolliert und mit dokumentierter Freigabe einbinden. ^{[S-147; S-148]}

Mindestnachweis

• Datenfluss, Empfänger, Region, Aufbewahrung und Rechtsgrundlage je Dienst dokumentieren. ^{[S-074; S-090; S-091]}
• Tag- und Consent-Konfiguration versionieren und in Staging testen. ^{[S-007; S-081]}

Warnsignale

• Marketing kann ohne Code-Review beliebige Skripte produktiv schalten. ^{[S-147; S-009]}
• Datenschutzerklärung listet Dienste, die technisch anders oder gar nicht konfiguriert sind. ^{[S-074; S-081]}

Datenschutzrollen, AVV und Drittlandtransfer

Webprojekte verbinden Kunde, Agentur, Hoster, Newsletter-, Support-, Payment- und KI-Anbieter. Rollen und Verträge müssen den tatsächlichen Zwecken, Mitteln und Zugriffen entsprechen. ^{[S-086; S-074; S-090; S-091]}

Grundsätze

• Pro Datenprozess Verantwortlichen, Empfänger, Auftragsverarbeiter und Unterauftragnehmer bestimmen. ^{[S-086; S-074]}
• Technische Architektur und Vertragslage gemeinsam prüfen. ^{[S-087; S-090]}

Mindestnachweis

• AVV, TOM, Löschung, Supportzugriffe und Exit-Regelung dokumentieren, sofern einschlägig. ^{[S-074; S-094]}
• Drittlandmechanismus und ergänzende Maßnahmen für konkrete Empfänger prüfen. ^{[S-092; S-091; S-090]}

Warnsignale

• Ein Anbieter wird allein wegen eines EU-Rechenzentrums automatisch als transferfrei eingestuft. ^{[S-092; S-074]}
• Agenturkonten mischen Daten mehrerer Kunden ohne Trennung und Rollenmodell. ^{[S-036; S-074]}

Anbieterkennzeichnung, Medienrecht und Inhaltsrechte

Unternehmenswebsite, redaktionelles Angebot und kommerzielle Kommunikation können unterschiedliche Informationspflichten auslösen. Inhalte benötigen außerdem belegte Nutzungsrechte. ^{[S-077; S-078; S-095; S-096]}

Grundsätze

• Aktuelle Rechtsgrundlage und reale Unternehmensdaten verwenden. ^{[S-076; S-077]}
• Redaktionelle Verantwortlichkeit und Werbung erkennbar gestalten, soweit einschlägig. ^{[S-095; S-078]}

Mindestnachweis

• Impressum, Kontakt, Register-, Aufsichts- und Berufsangaben nach tatsächlichem Anbieter prüfen. ^[S-077]
• Lizenz- und Freigabenachweis für Texte, Bilder, Videos, Fonts und Marken führen. ^{[S-096; S-097; S-098]}

Warnsignale

• Alte TMG-Vorlage wird ungeprüft übernommen oder Fantasiedaten werden als Platzhalter veröffentlicht. ^{[S-076; S-077]}
• KI-Bild wird allein wegen seiner Erzeugung als frei von Rechten Dritter angenommen. ^{[S-097; S-098]}

Barrierefreiheit und BFSG

Barrierefreiheit ist eine Qualitäts- und je nach Angebot Rechtsanforderung. Sie betrifft Inhalt, Komponenten, Formulare, Medien, Authentisierung, Zahlung und Support. ^{[S-107; S-099; S-103; S-104]}

Grundsätze

• Native, semantische HTML-Komponenten und Tastaturbedienung priorisieren. ^{[S-133; S-110; S-111]}
• Automatisierte Tests durch manuelle Tastatur-, Screenreader- und Inhaltsprüfung ergänzen. ^{[S-107; S-108]}

Mindestnachweis

• Zielstandard und anwendbare Rechtsgrundlage im Projekt festlegen. ^{[S-099; S-106; S-109]}
• Fehler, Fokus, Labels, Kontraste, Zoom, Reflow und Medienalternativen testen. ^{[S-107; S-112; S-113]}

Warnsignale

• Ein Overlay wird als vollständige Nachrüstung der Anwendung verkauft. ^{[S-107; S-110]}
• Checkout und Login bleiben unzugänglich, obwohl Startseite gute Scores erreicht. ^{[S-104; S-107]}

SEO, Crawling und strukturierte Daten

Technische Auffindbarkeit entsteht aus stabilen URLs, Statuscodes, interner Verlinkung, Canonicals, Sitemaps, robots.txt und verständlichem Inhalt. Strukturierte Daten ergänzen, ersetzen aber sichtbaren Inhalt nicht. ^{[S-163; S-152; S-153; S-154]}

Grundsätze

• Wichtige Seiten serverseitig oder robust renderbar und intern verlinkt bereitstellen. ^{[S-166; S-133]}
• Weiterleitungen und Canonical-Entscheidungen bei Relaunch planen. ^{[S-025; S-163]}

Mindestnachweis

• Sitemap, robots.txt, Statuscodes, Metadaten und strukturierte Daten automatisiert prüfen. ^{[S-168; S-167; S-169]}
• Search Console und Serverlogs für Crawl-/Indexierungsfehler beobachten. ^{[S-173; S-060]}

Warnsignale

• robots.txt soll vertrauliche Inhalte schützen. ^{[S-152; S-036]}
• KI erzeugt Tausende nahezu identische Seiten ohne belegten Nutzerwert. ^{[S-164; S-165]}

Performance und Nutzererlebnis

Leistung wird durch Netzwerk, Server, JavaScript, Bilder, Fonts, Drittanbieter, Caching und Gerät beeinflusst. Laborwerte und Felddaten beantworten unterschiedliche Fragen. ^{[S-170; S-171; S-172; S-138; S-139]}

Grundsätze

• Performancebudgets und kritische Nutzerpfade vor dem Feinschliff festlegen. ^{[S-001; S-170]}
• Drittanbieter nach Nutzen, Gewicht, Blockierverhalten und Ausfallwirkung bewerten. ^{[S-172; S-052]}

Mindestnachweis

• LCP, INP und CLS im Feld beobachten und mit fachlichen Kennzahlen verbinden. ^{[S-170; S-171]}
• Bilder, Cache, Kompression und JavaScript-Ausführung systematisch optimieren. ^{[S-172; S-025]}

Warnsignale

• Ein einmaliger Desktop-Lighthouse-Score wird als reale Gesamtleistung ausgegeben. ^{[S-172; S-170]}
• Marketingtags dürfen jedes Performancebudget ungeprüft überschreiten. ^{[S-052; S-001]}

Secure Development Lifecycle und Tests

Sicherheit muss in Anforderungen, Design, Implementierung, Review, Test, Deployment und Wartung integriert sein. Der aktuelle OWASP Top 10 und ASVS liefern unterschiedliche, ergänzende Perspektiven. ^{[S-009; S-032; S-031; S-030]}

Grundsätze

• Bedrohungs- und Missbrauchsfälle vor Implementierung kritischer Funktionen erfassen. ^{[S-013; S-003]}
• Sicherheitsanforderungen als prüfbare Gates in CI und Abnahme umsetzen. ^{[S-018; S-031]}

Mindestnachweis

• SAST, Dependency-, Secret- und dynamische Tests mit manueller Prüfung kombinieren. ^{[S-009; S-030]}
• Autorisierung, Upload, Zahlungs- und Adminpfade gezielt negativ testen. ^{[S-036; S-186; S-132]}

Warnsignale

• Nur Happy-Path-E2E-Test und keine Tests für Rollen oder Fehlerfälle. ^{[S-028; S-031]}
• KI-generierte Änderungen werden wegen Zeitgewinn ohne Review gemergt. ^{[S-010; S-017]}

Abhängigkeiten, Laufzeiten und Updates

Frameworks, CMS, Plugins, Packages, Actions und Images verändern sich. Wartbarkeit verlangt Inventar, Versionierung, Supportbeobachtung, Tests und kontrollierte Aktualisierung. ^{[S-008; S-202; S-200; S-201]}

Grundsätze

• Versionsbereiche und Lockdateien bewusst einsetzen; Änderungen nachvollziehbar halten. ^{[S-202; S-042]}
• Supportende und bekannte aktive Ausnutzung getrennt überwachen. ^{[S-200; S-201; S-066]}

Mindestnachweis

• Automatische Updatevorschläge in Staging testen und priorisieren. ^{[S-067; S-068; S-018]}
• Notfallprozess für kritisch ausgenutzte Komponenten festlegen. ^{[S-066; S-012]}

Warnsignale

• Unbegrenzte Major-Versionen werden automatisch produktiv installiert. ^{[S-008; S-051]}
• Kein Inventar, welche Kundeninstanz welches Plugin oder Runtime-Release nutzt. ^{[S-009; S-011]}

Backup, Restore und Geschäftskontinuität

Backups müssen Datenbank, Dateien, Konfiguration, Schlüssel und externes Wissen passend abdecken. Wiederanlauf hängt zusätzlich von DNS, Providerkonten, Dokumentation und Personalzugang ab. ^{[S-014; S-015; S-063; S-203]}

Grundsätze

• RPO und RTO aus Geschäftsfolgen ableiten, nicht aus Providerwerbung. ^{[S-014; S-015]}
• Backups getrennt schützen und regelmäßig wiederherstellen. ^{[S-203; S-064]}

Mindestnachweis

• Restoretest mit Zeit, Verantwortlichem, Ergebnis und offenen Lücken protokollieren. ^[S-014]
• Domain, DNS, Secrets und Drittanbieterzugänge in den Notfallplan aufnehmen. ^{[S-156; S-034]}

Warnsignale

• Backup befindet sich nur im selben Konto und derselben Fehlersphäre wie Produktion. ^{[S-203; S-069]}
• Restore wurde noch nie durchgeführt oder Schlüssel fehlen. ^{[S-014; S-071]}

Monitoring, Logging und Incident Response

Betrieb benötigt erkennbare Nutzerfehler, technische Signale, Sicherheitsereignisse und klare Reaktion. Logs, Metriken und Traces ergänzen sich. ^{[S-057; S-060; S-059; S-058; S-012]}

Grundsätze

• Für kritische Nutzerpfade messbare SLOs und alarmierbare Symptome definieren. ^{[S-052; S-053]}
• Korrelation über Browser, Backend, Queue und Drittanbieter ermöglichen. ^{[S-061; S-058]}

Mindestnachweis

• On-call beziehungsweise erreichbare Verantwortliche, Runbooks und Eskalation festlegen. ^{[S-054; S-012]}
• Nach Vorfällen Ursachen, beitragende Faktoren und neue Kontrollen dokumentieren. ^{[S-055; S-011]}

Warnsignale

• Alarmiert wird jede technische Abweichung, aber kein Nutzerpfad. ^[S-053]
• Logs enthalten Tokens, Passwörter oder sensible Formulardaten. ^{[S-035; S-074]}

E-Commerce, Vertragsschluss und Verbraucherinformationen

Shopfunktionen bilden einen rechtlich relevanten Prozess von Produktdarstellung und Preis bis Bestellung, Bestätigung, Widerruf und Streitfall. Daten und UI müssen konsistent sein. ^{[S-115; S-116; S-119; S-121]}

Grundsätze

• Pflichtinformationen in Datenmodell und Checkoutlogik einbauen statt nur in statische Texte. ^{[S-119; S-121]}
• Bestellung, Preis, Steuern, Versand, Verfügbarkeit und Bestätigung transaktional konsistent halten. ^{[S-116; S-001]}

Mindestnachweis

• Button, Zusammenfassung, AGB-/Widerrufsinformation und E-Mail-Bestätigung testen. ^{[S-116; S-117; S-118]}
• VSBG-Hinweise und Einstellung der ODR-Plattform aktuell bewerten. ^{[S-122; S-123; S-124]}

Warnsignale

• Preis oder Versandkosten ändern sich zwischen Übersicht und finaler Bestellung. ^{[S-121; S-127]}
• Veralteter OS-Link wird als Pflichtbestandteil jeder Shopseite behandelt. ^[S-124]

Zahlungsintegration und PCI

Zahlungsanbieter reduzieren Eigenbau, aber Checkout, Weiterleitung, Webhooks, Zugangsschutz und Betrugsfolgen bleiben zu verantworten. Kartendatenkontakt bestimmt den PCI-Umfang. ^{[S-131; S-132; S-129; S-130]}

Grundsätze

• Kartendaten nach Möglichkeit nicht durch eigene Systeme leiten. ^{[S-132; S-131]}
• Zahlungsstatus nur aus verifiziertem Server-zu-Server-Ereignis ableiten. ^{[S-194; S-048]}

Mindestnachweis

• Webhooksignatur, Idempotenz und Abgleich mit Betrag, Währung und Bestellung prüfen. ^{[S-194; S-047]}
• SCA-/3DS- und Abbruchpfade mit dem Zahlungsdienstleister testen. ^{[S-130; S-129]}

Warnsignale

• Browser-Rückleitung allein markiert Bestellung als bezahlt. ^{[S-048; S-194]}
• Zahlungsskripte und Adminzugänge werden nicht in Securitytests einbezogen. ^{[S-132; S-030]}

KI-generierter Code, Inhalte und Funktionen

KI kann Entwurf, Übersetzung, Code und Analyse beschleunigen. Qualität, Rechte, Sicherheit und tatsächliche Funktionsweise bleiben jedoch kontextabhängig und müssen evaluiert werden. ^{[S-006; S-212; S-211; S-213]}

Grundsätze

• KI-Aufgaben klein, testbar und mit klaren Annahmen formulieren. ^{[S-010; S-002]}
• Nur Änderungen übernehmen, die das Team versteht und warten kann. ^{[S-005; S-211]}

Mindestnachweis

• Tests, Review, Security- und Rechteprüfung unabhängig vom Erzeugungsweg durchführen. ^{[S-009; S-096; S-031]}
• KI-Funktionen mit Evals, Datenrechten, Toolrechten und Kostenlimits betreiben. ^{[S-039; S-040; S-037]}

Warnsignale

• Modellantwort wird als sichere Rechts-, SEO- oder Securityprüfung verkauft. ^{[S-074; S-165; S-213]}
• Agent erhält Schreib-, Lösch- oder Zahlungsrechte ohne Freigabe und Abbruchgrenzen. ^{[S-037; S-038]}

Kundenvertrag, Abnahme und Änderungssteuerung

Kundenprojekte benötigen eine klare Grenze zwischen Werkumfang, Mitwirkung, Fremdleistungen und laufendem Betrieb. Abnahme und Änderungen müssen anhand prüfbarer Kriterien erfolgen. ^{[S-002; S-004; S-003]}

Grundsätze

• Annahmen, Ausschlüsse und Kundenzulieferungen ausdrücklich dokumentieren. ^[S-002]
• Rechtliche Spezialprüfung dort anfordern, wo das Projektteam keine belastbare Kompetenz besitzt. ^{[S-003; S-074]}

Mindestnachweis

• Abnahmematrix für Funktionen, Inhalte, Browser, Rechte, Datenschutz, A11y und Betrieb vereinbaren. ^{[S-001; S-107; S-031]}
• Change Requests mit Auswirkung auf Preis, Termin, Risiko und Wartung freigeben. ^{[S-003; S-008]}

Warnsignale

• „Komplette rechtssichere Website“ wird ohne definierte Leistungen versprochen. ^{[S-077; S-074; S-099]}
• Kundeneinwilligung in einen Screenshot ersetzt die technische Abnahme. ^{[S-002; S-013]}

Übergabe, Dokumentation und Eigentum

Eine belastbare Übergabe umfasst die Fähigkeit, System zu betreiben, zu ändern und wiederherzustellen. Konten, Daten, Code, Lizenzen und offene Risiken müssen zusammengeführt werden. ^{[S-004; S-007; S-014; S-156]}

Grundsätze

• Kunde erhält reale Kontrolle über vereinbarte Vermögenswerte und nicht nur Agenturzugriff. ^{[S-158; S-155]}
• Dokumentation auf konkrete Betriebsaufgaben ausrichten. ^{[S-004; S-054]}

Mindestnachweis

• Konten-/Rollenliste, Repository, Build/Deploy, Datenexport, Backups, Secrets-Transfer und Lizenzinventar übergeben. ^{[S-022; S-034; S-014]}
• Offene Mängel, Restunsicherheit und nächste Wartungstermine schriftlich kennzeichnen. ^{[S-003; S-066]}

Warnsignale

• Domain, Hosting oder Quellcode bleiben ohne Vereinbarung an persönlichem Agenturkonto hängen. ^{[S-157; S-158]}
• Passwörter werden unverschlüsselt in einem Abschluss-PDF versendet. ^{[S-034; S-209]}

Wartung, Support und Servicegrenzen

Nach Übergabe verändern sich Browser, Recht, Inhalte, APIs, Plugins und Laufzeiten. Wartung ist deshalb eine eigenständige Leistung mit Reaktions- und Entscheidungsregeln. ^{[S-198; S-200; S-201; S-054]}

Grundsätze

• Wartungsumfang nach Komponenten und Verantwortung definieren. ^{[S-056; S-004]}
• Sicherheitsvorfälle, Funktionsfehler und Inhaltsänderungen getrennt priorisieren. ^{[S-012; S-055]}

Mindestnachweis

• Inventar, Updatefrequenz, SLA/SLO, Supportkanal und Kostenregelung festlegen. ^{[S-011; S-052]}
• Provider- und Rechtsänderungen mit hoher Refresh-Priorität beobachten. ^{[S-076; S-102; S-200]}

Warnsignale

• „Wartungsfrei“ trotz CMS, Plugins, Formularen und Drittanbieter-APIs. ^{[S-198; S-066]}
• Kunde erwartet Rund-um-die-Uhr-Support, Vertrag enthält aber keine Erreichbarkeit. ^{[S-054; S-002]}

Relaunch, Migration und Weiterleitungen

Ein Relaunch verändert URLs, Inhalte, Tracking, Formulare, Daten und oft Verantwortlichkeiten. Der sichere Weg braucht Inventar, Mapping, Parallelprüfung und Rückfall. ^{[S-025; S-163; S-065; S-051]}

Grundsätze

• Altbestand und Zielsystem vollständig inventarisieren. ^{[S-002; S-173]}
• Migration als Daten- und Betriebsprojekt behandeln, nicht nur als Designwechsel. ^{[S-065; S-015]}

Mindestnachweis

• URL-Mapping, Redirects, Canonicals, Metadaten, Formulare und Analytics testen. ^{[S-025; S-163; S-081]}
• Backups, Freeze-Fenster, Delta-Migration und Rollback festlegen. ^{[S-064; S-051]}

Warnsignale

• Alte URLs werden pauschal auf Startseite umgeleitet. ^{[S-163; S-025]}
• Neues System geht live, bevor Login, Zahlung oder Formulare mit Produktionsintegration geprüft sind. ^{[S-050; S-030]}

Stilllegung, Export und Vertragsende

Websysteme brauchen einen geordneten Endzustand. Daten, Domain, Weiterleitungen, Konten, Subscriptions und Nachweise dürfen nicht zufällig verbleiben. ^{[S-074; S-157; S-015; S-004]}

Grundsätze

• Exit-Anforderungen bereits bei Auswahl von Plattform und Anbieter berücksichtigen. ^{[S-195; S-003]}
• Datenlöschung und gesetzliche Aufbewahrung getrennt behandeln. ^{[S-074; S-015]}

Mindestnachweis

• Exportformat, Frist, Verantwortlicher, Löschbestätigung und Zugangsentzug festlegen. ^{[S-074; S-086]}
• Domain- und E-Mail-Übergang mit Weiterleitungen und Nutzerkommunikation planen. ^{[S-156; S-206]}

Warnsignale

• Agentur löscht oder sperrt Produktionszugang unmittelbar bei Vertragsstreit ohne Notfallplan. ^{[S-003; S-015]}
• Verwaiste Subdomains, API-Schlüssel und Adminnutzer bleiben nach Projektende aktiv. ^{[S-034; S-011]}

25 Rechts-, Standard- und Technikprofile

Die Profile erklären, was ein Regelwerk oder Standard für Webprojekte praktisch bedeutet und wo seine Aussagegrenze liegt.

DDG und Anbieterkennzeichnung

TDDDG § 25 und DSK-Orientierung

DSGVO für Webprojekte

EU-US Data Privacy Framework und Standardvertragsklauseln

BFSG und BFSGV

WCAG 2.2

EN 301 549, BITV und öffentlicher Bereich

HTML, ARIA und WAI-Komponentenpraxis

OWASP Top 10:2025

OWASP ASVS 5.0.0

OWASP API Security Top 10:2023

NIST SP 800-63B-4

OAuth 2.0 Security Best Current Practice

TLS 1.3, ACME und Serverkonfiguration

CSP und ergänzende Browserrichtlinien

DNSSEC und CAA

Google Search Essentials und Spam Policies

Web Vitals und Lighthouse

PCI DSS 4.0.1 und E-Commerce-Hinweise

Verbrauchervertrag, Preis und Widerruf

GPSR für Online-Produktangebote

VSBG und Ende der ODR-Plattform

NIST SSDF und Secure by Design

AI Act Artikel 50 für Web-KI

Cyber Resilience Act

Zusammenspiel der wichtigsten Ebenen

Abbildung: Abbildung 4: Vereinfachter Datenfluss einer Website mit getrennten Prüfungen für Endgerätezugriff und personenbezogene Verarbeitung.

Abbildung: Abbildung 5: Schutzschichten einer verantworteten Webanwendung von Oberfläche bis Governance.

Wichtige Trennung: Rechtstext, Consent-Banner, Security-Header, Barrierefreiheitstest und Backup lösen jeweils nur einen Teil des Problems. Ein belastbares Websystem entsteht erst durch ihr abgestimmtes Zusammenspiel. ^{[S-074; S-080; S-107; S-031; S-014]}

12 dokumentierte Vorfälle und Lessons Learned

FALLLOGIK: Die Fälle werden nicht als Beweis dafür verwendet, dass jede Website gleich gefährdet ist. Sie zeigen wiederkehrende Fehlermuster: ungepatchte Systeme, Drittanbieter-Code, fehlende Erkennung, fehlerhafte Konfiguration, ungetestete Wiederherstellung und unklare Kontrolle. ^{[S-215; S-216; S-219; S-069]}

British Airways: großer Datenschutzvorfall

Ticketmaster: kompromittiertes Drittanbieter-Skript

CNIL: Cookie-Bußgelder gegen Google und Amazon

CNIL: Ablehnen von Cookies unnötig erschwert

Drupalgeddon 2: kritische Remote-Code-Ausführung

Let's Encrypt: CAA-Rechecking-Fehler

MOVEit: massenhafte Ausnutzung einer Webanwendung

Equifax: ungepatchte bekannte Schwachstelle

GitLab: Produktionsdatenbank versehentlich gelöscht

Atlassian: Wiederherstellung dauerte für einige Kunden Wochen

Cloudflare 2019: fehlerhafte Regel verursachte globalen Ausfall

CrowdStrike 2024: problematischer Inhaltsupdate-Rollout

18 Referenzszenarien

ARCHITEKTURHINWEIS: Die Szenarien sind keine fertigen Baupläne. Sie zeigen, wie Systemtyp, Kontrollen, KI-Rolle und bewusst nicht mit KI gelöste Teile voneinander getrennt werden. ^{[S-002; S-001; S-010]}

Solo-Selbstständiger: Informationsseite mit Kontakt

Lokaler Handwerksbetrieb: redaktionelle Website

Agenturprojekt: Kunden-CMS mit Übergabe

Lead-Landingpage mit Kampagnenmessung

Kundenportal mit Login und Dokumenten

Online-Terminbuchung

Bewerbungsformular mit Dateiupload

Mitgliederbereich für Schulungsinhalte

Außendienst-PWA mit Offlinefunktion

Kleiner B2C-Onlineshop

B2B-Angebotskonfigurator

Marktplatz oder Nutzerplattform

Datensparsame Reichweitenmessung

Marketingseite mit vielen Drittanbietern

Mehrsprachige Unternehmenswebsite

Website-Chatbot mit Unternehmenswissen

CRM-Integration: Formular zu Angebot

Relaunch einer älteren WordPress-Seite

56-stufiger Umsetzungsweg

UMSETZUNGSRAHMEN: Der Weg ist als Nachweiskette aufgebaut. Jede Phase erzeugt Ergebnisse, die für die nächste Phase und für spätere Übergabe, Betrieb oder Prüfung verwendet werden. ^{[S-002; S-004; S-009; S-050]}

Phase 1 - Auftrag, Wirkung und Verantwortung

Phase 2 - Inhalte, Recht und Daten

Phase 3 - Architektur und Sicherheitsdesign

Phase 4 - Kontrollierter Bau

Phase 5 - Prüfung und Abnahme

Phase 6 - Launch

Phase 7 - Betrieb und Verbesserung

Phase 8 - Übergabe, Wechsel und Stilllegung

Projekt-, Go-live-, Übergabe- und Betriebschecklisten

Vor Angebot und Vertragsabschluss

• Anbieter, Zielgruppe, Nutzeraufgabe, Inhalte, Webtyp und bewusst ausgeschlossene Funktionen sind klar. ^{[S-002; S-001]}
• Datenarten, Login, Zahlungen, Verträge, Uploads, KI, Drittanbieter und mögliche Schäden sind inventarisiert. ^{[S-074; S-003; S-031]}
• Kunde und Auftragnehmer haben Mitwirkung, Inhalte, Rechte, Freigaben, Abnahme, Wartung, Support und Fremdleistungen beschrieben. ^{[S-002; S-004]}
• Domain, Hosting, Repository, E-Mail, Payment und sonstige Konten werden auf Inhaberschaft und Exit geprüft. ^{[S-155; S-156; S-158]}
• BFSG/öffentlicher Bereich, Datenschutzrollen, E-Commerce- und branchenspezifische Pflichten sind im Scope geprüft. ^{[S-099; S-106; S-086; S-116]}
• Budget enthält nicht nur Erstellung, sondern Tests, Content, Migration, Monitoring, Backups, Updates und Übergabe. ^{[S-050; S-014; S-004]}

Technische Mindestprüfung vor Go-live

Abnahme und Übergabe

• Abnahmekriterien werden gegen produktionsnahe Nutzerpfade und Fehlerfälle getestet. ^{[S-002; S-030]}
• Offene Mängel enthalten Wirkung, Priorität, Workaround, Eigentümer und Termin. ^[S-003]
• Kunde erhält Organisationszugänge, Rollen, Domain-/Registrarzugriff, Repository, Build- und Deploymentweg. ^{[S-156; S-004]}
• Datenexport, Backup und Restore sind nicht nur vorhanden, sondern praktisch verifiziert. ^[S-014]
• Lizenzen, Inhalte, Unterauftragnehmer, Subscriptions, Secrets und bekannte Risiken sind dokumentiert. ^{[S-096; S-009; S-034]}
• Wartung, Support, Updates, Sicherheitsmeldungen und Vertragsende sind ausdrücklich geregelt. ^{[S-004; S-066; S-074]}

Laufender Quartalscheck

• Domains, Zertifikate, Registrar- und Adminzugänge funktionieren; MFA und Notfallzugriff sind aktuell. ^{[S-141; S-158]}
• CMS, Runtime, Plugins, Pakete und Images sind unterstützt; KEV und Security Advisories wurden bewertet. ^{[S-198; S-200; S-201; S-066]}
• Drittanbieter, Cookies, Transfers, Datenschutztexte und Consentverhalten stimmen noch überein. ^{[S-081; S-091; S-074]}
• Backups wurden erfolgreich wiederhergestellt und RPO/RTO bleiben passend. ^{[S-014; S-064]}
• Kritische Nutzerpfade, Accessibility und Web Vitals zeigen keine schleichende Verschlechterung. ^{[S-107; S-170; S-052]}
• Owner, Support, Incidentkontakte, Vertrags- und Exitinformationen sind aktuell. ^{[S-012; S-004]}

KI-gestützte Entwicklung: zulässige Rolle und Qualitätsgates

FORSCHUNGS- UND SICHERHEITSBEFUND: KI kann Entwürfe und Implementierungen beschleunigen. Ihre Vorschläge können zugleich veraltet, unnötig komplex oder sicherheitskritisch falsch sein. Die zulässige Rolle wird deshalb nach Wirkung und Prüfbarbarkeit begrenzt. ^{[S-006; S-211; S-213; S-010]}

Harte Annahmeregel: Code oder Konfiguration, deren Wirkung niemand im Projekt erklären, testen und im Fehlerfall zurücknehmen kann, darf nicht allein deshalb produktiv gehen, weil eine KI ihn erzeugt hat. ^{[S-010; S-009; S-003]}

„Wann brauche ich keine KI?“

• Statische Inhalte, Navigation, Formulare und bekannte Geschäftsregeln lassen sich häufig deterministisch und günstiger umsetzen. ^{[S-002; S-001]}
• Preise, Steuern, Rechte, Zahlungszustände und verbindliche Vertragslogik gehören in Regeln und Datenmodelle. ^{[S-116; S-121; S-131]}
• Authentisierung, Autorisierung, Mandantentrennung, Löschung und Backup sind klassische Sicherheits- und Datenfunktionen. ^{[S-036; S-174; S-014]}
• Ein Chatbot ersetzt keine gut strukturierte Website, Suchfunktion, FAQ oder Kontaktstrecke. ^{[S-163; S-107]}
• Eine kleine Website benötigt keine Agentenarchitektur, wenn das Problem mit wenigen Seiten und einem kontrollierten Formular gelöst ist. ^{[S-001; S-003]}

20 Mythenprüfungen

Jede Website braucht einen Cookie-Banner

Urteil: FALSCH. Maßgeblich sind die tatsächlich eingesetzten Endgerätezugriffe und die Ausnahmen des § 25 TDDDG. Eine rein technisch notwendige, trackingfreie Website kann ohne Einwilligungsbanner auskommen; die konkrete Konfiguration entscheidet. ^{[S-080; S-081]}

HTTPS bedeutet, dass die Website sicher ist

Urteil: FALSCH. TLS schützt die Verbindung. Autorisierungsfehler, XSS, Injection, unsichere Uploads, kompromittierte Konten und fehlerhafte Geschäftslogik bleiben möglich. ^{[S-137; S-032]}

Ein CMS ist immer sicherer als Eigenentwicklung

Urteil: ZU PAUSCHAL. Ein gepflegtes Standardsystem kann viele ausgereifte Funktionen bieten; Plugins, Fehlkonfiguration und verzögerte Updates schaffen zugleich Risiken. Eigenentwicklung kann enger sein, verlangt aber eigene Engineering- und Betriebskompetenz. ^{[S-196; S-198; S-009]}

Eine statische Website ist wartungsfrei

Urteil: FALSCH. Domain, TLS, Build-Abhängigkeiten, Inhalte, Rechte, Formulare, Drittressourcen und Deployment bleiben zu pflegen. ^{[S-141; S-067; S-077]}

Das Impressum steht noch im TMG

Urteil: VERALTET. Die aktuelle deutsche Rechtsgrundlage ist das DDG; alte Vorlagen müssen überprüft werden. ^{[S-076; S-077]}

Das frühere TTDSG ist unverändert der aktuelle Gesetzesname

Urteil: VERALTET. Das Gesetz heißt heute TDDDG; ältere URLs und Dokumente können aus historischen Gründen noch die frühere Abkürzung enthalten. ^[S-079]

Der Link zur EU-OS-Plattform gehört weiterhin in jeden Shop

Urteil: VERALTET. Die Plattform wurde eingestellt und die zugrunde liegende Verordnung aufgehoben. VSBG-Informationspflichten sind separat zu prüfen. ^{[S-124; S-122]}

WCAG 2.2 gilt automatisch als identisches Gesetz für jede private Website

Urteil: FALSCH. WCAG ist ein technischer W3C-Standard. Welche rechtliche Pflicht gilt, hängt unter anderem von BFSG, öffentlichem Bereich, Dienstleistung und Vertrag ab. ^{[S-107; S-099; S-106]}

Ein Accessibility-Overlay macht eine Website barrierefrei

Urteil: NICHT BELEGT. Barrierefreiheit hängt von Semantik, Tastaturbedienung, Fokus, Inhalten, Formularen und Prozesslogik ab. Eine nachgelagerte Schicht kann strukturelle Fehler nicht pauschal beheben. ^{[S-107; S-110; S-112]}

robots.txt schützt geheime Bereiche

Urteil: FALSCH. robots.txt ist ein Protokoll für kooperative Crawler und keine Authentisierung oder Autorisierung. ^{[S-152; S-036]}

Eine Sitemap garantiert gute Rankings

Urteil: FALSCH. Sie erleichtert die URL-Entdeckung, garantiert aber weder Indexierung noch Ranking. ^{[S-153; S-168]}

KI-Texte sind grundsätzlich schädlich für SEO

Urteil: FALSCH. Google verbietet KI-Nutzung nicht pauschal. Manipulative Skalierung und inhaltsarme Massenproduktion können gegen Spamrichtlinien verstoßen; Qualität und Nutzerwert bleiben entscheidend. ^{[S-165; S-164]}

Ein hoher Lighthouse-Score beweist eine gute Website

Urteil: FALSCH. Lighthouse ist ein Labordiagnosewerkzeug. Reale Nutzerleistung, Sicherheit, Recht, Barrierefreiheit, Inhalte und Geschäftserfolg benötigen weitere Nachweise. ^{[S-172; S-170; S-001]}

Ein Login schützt automatisch alle Daten dahinter

Urteil: FALSCH. Nach der Authentisierung muss jede Aktion und jedes Objekt autorisiert werden. Fehlende Objektberechtigungen gehören zu den zentralen API-Risiken. ^{[S-036; S-033]}

CORS schützt eine API vor unberechtigtem Zugriff

Urteil: FALSCH. CORS begrenzt bestimmte Browserzugriffe. Server-zu-Server-Anfragen und fehlende API-Autorisierung werden dadurch nicht behoben. ^{[S-135; S-188; S-191]}

Ein Backup ist vorhanden, also ist Wiederherstellung gesichert

Urteil: FALSCH. Nur ein erfolgreicher Restore mit vollständigen Daten, Schlüsseln und Konfiguration belegt Wiederherstellbarkeit. ^{[S-014; S-063; S-069]}

Gehostete Zahlung beseitigt jede PCI- und Sicherheitsverantwortung

Urteil: FALSCH. Sie kann den Umfang reduzieren. Shopseite, Skripte, Weiterleitungen, Zugangsschutz und Integrationsmodell bleiben relevant. ^{[S-131; S-132]}

KI-generierter Code muss weniger geprüft werden, weil das Modell Best Practices kennt

Urteil: FALSCH. Forschung dokumentiert unsichere Vorschläge und stark kontextabhängige Produktivität. Generierter Code braucht dieselben oder bei mangelndem Verständnis stärkere Gates. ^{[S-213; S-211; S-010]}

Die Agentur ist automatisch für alles verantwortlich, was sie gebaut hat

Urteil: ZU PAUSCHAL. Verantwortung folgt aus Vertrag, tatsächlicher Rolle, Kontrolle, Betreiberstellung und jeweiligem Rechtsgebiet. Eine pauschale Aussage ist ohne Projektkontext nicht belastbar. ^{[S-002; S-086; S-074]}

Mit der Übergabe des Quellcodes ist das Kundenprojekt vollständig übergeben

Urteil: FALSCH. Betrieb erfordert zusätzlich Konten, Domain, Daten, Build/Deploy, Secrets, Lizenzen, Backups, Dokumentation und bekannte Risiken. ^{[S-004; S-156; S-014]}

20 offene Rechts-, Technik- und Praxisfragen

Offene Punkte werden als projektspezifische oder noch veränderliche Fragen ausgewiesen. Das Dossier ersetzt Unsicherheit nicht durch Pauschalbehauptungen.

Glossar — 93 Begriffe

Abnahme

Formale oder vertraglich relevante Feststellung, dass definierte Anforderungen erfüllt sind; sie benötigt prüfbare Kriterien. ^[S-002]

ACME

Protokoll zur automatisierten Ausstellung und Erneuerung von Zertifikaten. ^[S-141]

Administrationskonto

Konto mit erweiterten Rechten für Konfiguration, Nutzer, Inhalte oder Betrieb; besonders schutzbedürftig. ^[S-036]

AI Act

Verordnung (EU) 2024/1689 über künstliche Intelligenz mit risikobasierten und weiteren Pflichten. ^[S-075]

API

Programmierschnittstelle mit definierten Requests, Responses, Authentisierung und Fehlern. ^{[S-023; S-025]}

ARIA

W3C-Spezifikation für zusätzliche Rollen, Zustände und Eigenschaften zur Zugänglichkeit dynamischer Inhalte. ^[S-110]

Authentisierung

Prüfung einer behaupteten Identität. ^[S-174]

Autorisierung

Entscheidung, ob eine identifizierte Entität eine Aktion auf einer Ressource ausführen darf. ^[S-036]

Backup

Sicherung von Daten und gegebenenfalls Konfiguration für eine spätere Wiederherstellung. ^[S-014]

BFSG

Deutsches Barrierefreiheitsstärkungsgesetz für bestimmte Produkte und Dienstleistungen. ^[S-099]

Browser

Clientsoftware, die Webressourcen abruft, HTML/CSS/JavaScript verarbeitet und Sicherheitsrichtlinien umsetzt. ^{[S-133; S-135]}

CAA

DNS-Record, mit dem festgelegt werden kann, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. ^[S-145]

Cache

Zwischenspeicher zur Reduktion von Latenz oder Last; benötigt korrekte Invalidierung und Datenschutzprüfung. ^{[S-025; S-074]}

Canonical URL

Als bevorzugt deklarierte URL für inhaltlich gleiche oder ähnliche Seiten; Suchmaschinenhinweis, kein Zugriffsschutz. ^[S-163]

CDN

Verteilte Infrastruktur zur Auslieferung von Inhalten nahe am Nutzer; wird Teil von Datenfluss und Verfügbarkeit. ^{[S-195; S-074]}

CI/CD

Automatisierte Integration, Prüfung und Auslieferung von Änderungen. ^{[S-018; S-020]}

CMS

Content-Management-System für strukturierte Erstellung, Verwaltung und Veröffentlichung von Inhalten. ^[S-196]

Consent Management

Technische und organisatorische Steuerung von Einwilligung, Blockierung, Auswahl, Nachweis und Widerruf. ^{[S-081; S-082]}

Cookie

Von einem Server gesetzter oder vom Browser verwalteter Zustandswert, der nach definierten Regeln mit Requests gesendet werden kann. ^[S-146]

Core Web Vitals

Aktuelle Google-Metriken für zentrale Aspekte realer Nutzererfahrung, darunter LCP, INP und CLS. ^{[S-170; S-171]}

CORS

Browsermechanismus zur Kontrolle bestimmter Cross-Origin-Zugriffe auf Antworten. ^{[S-135; S-188]}

CSP

Content Security Policy; Browserrichtlinie zur Begrenzung zulässiger Ressourcen und Scriptausführung. ^[S-147]

CSRF

Angriff, bei dem ein Browser unerwünschte authentisierte Aktionen an eine Zielanwendung sendet. ^[S-182]

Datenbankmigration

Versionierte Änderung von Schema oder Daten mit kontrollierter Ausführung und Rückfallplanung. ^{[S-063; S-008]}

Datenminimierung

DSGVO-Grundsatz, personenbezogene Daten auf das für den Zweck notwendige Maß zu begrenzen. ^[S-074]

DDG

Digitale-Dienste-Gesetz; aktueller deutscher Rechtsrahmen, der unter anderem Anbieterinformationspflichten enthält. ^{[S-076; S-077]}

Deployment

Überführung eines freigegebenen Artefakts und seiner Konfiguration in eine Zielumgebung. ^[S-020]

DKIM

Kryptografische Signatur von E-Mail-Nachrichten durch eine Domain. ^[S-205]

DMARC

Richtlinien- und Reportingverfahren auf Basis von SPF/DKIM-Ausrichtung. ^[S-206]

DNS

Hierarchisches Namenssystem zur Auflösung von Domains und Veröffentlichung weiterer Diensteinformationen. ^{[S-142; S-143]}

DNSSEC

Erweiterung des DNS zur kryptografischen Validierung signierter DNS-Daten. ^[S-144]

Drittanbieter-Skript

Code, der von einem externen Anbieter geladen oder gesteuert wird und Teil der eigenen Websitewirkung wird. ^{[S-147; S-216]}

Drittlandtransfer

Übermittlung personenbezogener Daten in ein Land außerhalb des EWR beziehungsweise an dortige Empfänger unter den DSGVO-Regeln. ^{[S-074; S-090]}

E-Commerce-Dienstleistung

Im BFSG definierter Dienst im Hinblick auf Abschluss von Verbraucherverträgen über Websites oder mobile Dienste. ^[S-100]

Endgerät

Gerät des Nutzers, auf dessen Informationen § 25 TDDDG beim Speichern oder Auslesen zielen kann. ^{[S-080; S-084]}

Error Budget

Aus SLO und gemessener Zuverlässigkeit abgeleiteter Spielraum für Nichtverfügbarkeit oder Fehler. ^[S-052]

Fetch

Webstandard für Requests, Responses, CORS und verwandte Browsernetzwerklogik. ^[S-135]

Formularvalidierung

Prüfung von Eingaben gegen fachlich zulässige Formate, Werte und Grenzen; serverseitig erforderlich. ^[S-179]

HSTS

HTTP Strict Transport Security; Browseranweisung, eine Domain nur über HTTPS aufzurufen. ^[S-140]

HTML

Semantische Auszeichnungssprache des Webs und Grundlage nativer Bedienelemente. ^[S-133]

HTTP

Protokollsemantik für Webrequests, Antworten, Methoden, Status und Caching. ^[S-025]

HTTP/2

Binäres Multiplexing-Protokoll für HTTP-Kommunikation über eine Verbindung. ^[S-138]

HTTP/3

HTTP-Abbildung auf QUIC mit anderen Transport- und Verbindungsmerkmalen. ^[S-139]

Idempotenz

Eigenschaft, durch die wiederholte gleichartige Requests nicht zu zusätzlichen fachlichen Wirkungen führen. ^{[S-047; S-048]}

Impressum

Gebräuchliche Bezeichnung für gesetzlich erforderliche Anbieter- und gegebenenfalls weitere Verantwortlichkeitsangaben. ^{[S-077; S-095]}

Incident

Ereignis, das Vertraulichkeit, Integrität, Verfügbarkeit oder Geschäftsbetrieb beeinträchtigt und koordiniert bearbeitet werden muss. ^[S-012]

INP

Interaction to Next Paint; Web-Vitals-Metrik zur Reaktionsfähigkeit einer Seite auf Nutzerinteraktionen. ^[S-171]

JWT

Kompaktes Format für signierte beziehungsweise geschützte Claims; sichere Nutzung verlangt strikte Validierung. ^[S-178]

Kleinstunternehmen

Im BFSG definierte Unternehmenskategorie mit weniger als zehn Beschäftigten und begrenztem Umsatz oder Bilanzsumme. ^[S-100]

Lighthouse

Automatisiertes Labortool zur Prüfung verschiedener Websitequalitätsbereiche. ^[S-172]

Local Storage

Browserseitiger Speichermechanismus; kann unter die Endgerätezugriffsprüfung fallen. ^[S-084]

Logging

Aufzeichnung relevanter Ereignisse für Betrieb, Audit und Sicherheit mit Schutz gegen Geheimnis- und Datenlecks. ^[S-035]

Mandantentrennung

Technische und organisatorische Sicherstellung, dass Daten und Aktionen verschiedener Kunden getrennt bleiben. ^{[S-036; S-033]}

MFA

Mehrfaktor-Authentisierung mit Faktoren aus unterschiedlichen Kategorien. ^[S-174]

Migrationsplan

Dokumentierter Ablauf für Daten-, URL-, Domain- oder Plattformwechsel inklusive Prüfungen und Rückfall. ^{[S-065; S-051]}

MTA-STS

Policyverfahren, mit dem Domains TLS-Anforderungen für eingehende E-Mail veröffentlichen können. ^[S-207]

OAuth 2.0

Autorisierungsrahmen zur delegierten Zugriffserteilung auf geschützte Ressourcen. ^[S-175]

OpenAPI

Spezifikation zur Beschreibung von HTTP-APIs. ^[S-023]

OWASP ASVS

Prüfbarer Katalog von Sicherheitsanforderungen für Webanwendungen und Dienste. ^[S-031]

Passkey

Übliche Produktbezeichnung für synchronisierte oder gerätegebundene WebAuthn-/FIDO-Zugangsdaten. ^{[S-151; S-174]}

PCI DSS

Sicherheitsstandard für Umgebungen, die Kartenkontodaten speichern, verarbeiten oder übertragen. ^[S-131]

PITR

Point-in-Time Recovery; Wiederherstellung einer Datenbank zu einem bestimmten Zeitpunkt aus Basisbackup und Änderungsarchiv. ^[S-064]

Plugin

Erweiterung eines CMS oder Systems, die Code, Datenzugriff und externe Abhängigkeiten einführen kann. ^[S-199]

Progressive Web App

Webanwendung, die Browserfähigkeiten wie Installation, Offline- oder Hintergrundfunktionen nutzen kann. ^[S-135]

Rate Limit

Begrenzung von Anfragen, Aktionen oder Ressourcen pro Identität, Zeit oder Kontext. ^{[S-191; S-033]}

Recovery

Wiederherstellung von Konto, Daten oder Dienst nach Verlust, Fehler oder Incident. ^{[S-174; S-014]}

Redirect

HTTP- oder anwendungsseitige Weiterleitung von einer URL zu einer anderen. ^[S-025]

Referrer-Policy

Browserrichtlinie zur Steuerung, welche Herkunfts- beziehungsweise URL-Informationen in Referrer-Headern gesendet werden. ^[S-149]

Restoretest

Praktischer Nachweis, dass ein Backup innerhalb definierter Ziele wiederhergestellt werden kann. ^[S-014]

RPO

Recovery Point Objective; maximal tolerierbarer Datenverlust gemessen als Zeitabstand. ^[S-014]

RTO

Recovery Time Objective; Zielzeit für Wiederherstellung eines Dienstes oder Prozesses. ^[S-014]

Samesite

Cookieattribut zur Begrenzung bestimmter Cross-Site-Sendungen von Cookies. ^{[S-146; S-182]}

Schema.org

Gemeinschaftliches Vokabular für strukturierte Daten auf Webseiten. ^[S-154]

Search Console

Google-Dienst für Suchperformance, Indexierungs- und technische Hinweise einer bestätigten Property. ^[S-173]

Session

Server- und/oder browserseitig verwalteter Anmelde- und Zustandskontext über mehrere Requests. ^[S-183]

Sitemap

XML- oder anderes unterstütztes Format zur Mitteilung relevanter URLs an Suchmaschinen. ^[S-153]

SLO

Service Level Objective; internes messbares Zuverlässigkeitsziel für einen Dienst. ^[S-052]

SPF

DNS-basiertes Verfahren, das berechtigte Mailserver für eine Domain beschreibt. ^[S-204]

SRI

Subresource Integrity; Hashprüfung externer Ressourcen durch den Browser. ^[S-148]

SSRF

Server-Side Request Forgery; Missbrauch einer Serverfunktion zum Abruf unerwünschter interner oder externer Ziele. ^[S-187]

Staging

Produktionsähnliche, getrennte Umgebung für Integration, Prüfung und Freigabe. ^[S-020]

System of Record

Führendes System für einen verbindlichen Datentyp oder Geschäftsstatus. ^[S-002]

TDDDG

Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz; enthält unter anderem § 25 zum Schutz von Endeinrichtungen. ^{[S-079; S-080]}

TLS

Transport Layer Security; Protokoll für vertrauliche und authentisierte Transportverbindungen. ^[S-137]

Tool Calling

KI-Muster, bei dem ein Modell einen strukturierten Werkzeugaufruf vorschlägt; Ausführung muss separat autorisiert und validiert werden. ^{[S-037; S-010]}

Trace

Korrelierte Darstellung eines Requests oder Vorgangs über mehrere Dienste und Schritte. ^{[S-058; S-061]}

URL

Standardisierte Adresse beziehungsweise Kennung einer Webressource. ^[S-134]

VSBG

Verbraucherstreitbeilegungsgesetz mit Informationspflichten für bestimmte Unternehmer und Streitfälle. ^{[S-122; S-123]}

WCAG

Web Content Accessibility Guidelines des W3C mit testbaren Erfolgskriterien. ^[S-107]

Web Vitals

Metriken zur Messung zentraler Aspekte der Nutzererfahrung im Web. ^[S-170]

WebAuthn

Browser-API für kryptografische Public-Key-Anmeldedaten und phishing-resistente Authentisierung. ^[S-151]

Webhook

HTTP-basierte Benachrichtigung eines Systems an einen registrierten Endpunkt über ein Ereignis. ^[S-194]

XSS

Cross-Site Scripting; Einschleusen und Ausführen nicht vertrauenswürdigen Codes im Browserkontext einer Website. ^[S-180]

Quellenmethodik und Belegmatrix

Auswahlprinzip

• Primärrecht, Behördenmaterial, internationale Standards, offizielle technische Spezifikationen, Originalstudien und offizielle Post-Mortems werden bevorzugt.
• Beratungs-, Anbieter- und Communityangaben werden nur für ihren belegbaren Produkt- oder Erfahrungsbereich verwendet und als solche gekennzeichnet.
• Rechtsänderungen, Living Standards, CMS-/Runtime-Support, Suchmaschinen- und Sicherheitsdokumentation erhalten erhöhte Refresh-Priorität.
• Unbekannte Veröffentlichungsdaten werden mit UNKLAR beziehungsweise Prüfstichtag geführt, nicht erfunden.
• Quellenbezug bedeutet nicht, dass jede Praxisempfehlung wörtlich in einer Quelle steht; abgeleitete Aussagen sind als Synthese gekennzeichnet.

Quellenverteilung

Kompakte Belegmatrix

Vollständiges Quellenregister — 221 Einträge

Jeder Eintrag enthält Herausgeber, Titel, Veröffentlichungsdatum beziehungsweise explizit UNKLAR, Dokumenttyp, Status, Relevanz, Refresh-Priorität und direkte URL.

Lebenszyklus und Qualität

^[S-001] ISO/IEC 25010:2023 — Product quality model

• Autor/Herausgeber: ISO / IEC
• Datum: 2023
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Produktqualitätsmodell mit neun Qualitätsmerkmalen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/78176.html](https://www.iso.org/standard/78176.html)

Anforderungen

^[S-002] ISO/IEC/IEEE 29148:2018 — Requirements engineering

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2018; Nachfolgedokument in Entwicklung, geprüft 08.08.2026
• Dokumenttyp: Internationaler Standard
• Status: Gültige Ausgabe am Stichtag
• Relevanz: Anforderungen, deren Eigenschaften und Requirements-Prozesse.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.iso.org/standard/72089.html](https://www.iso.org/standard/72089.html)

Governance und Risiko

^[S-003] ISO/IEC/IEEE 16085:2021 — Life cycle processes — Risk management

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2021
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Risikomanagement über den System- und Softwarelebenszyklus.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/74371.html](https://www.iso.org/standard/74371.html)

Dokumentation

^[S-004] ISO/IEC/IEEE 26514:2022 — Design and development of information for users

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2022
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Nutzerdokumentation als geplanter Bestandteil eines Produkts.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/77451.html](https://www.iso.org/standard/77451.html)

Lebenszyklus und Qualität

^[S-005] Guide to the Software Engineering Body of Knowledge — SWEBOK Guide V4.0

• Autor/Herausgeber: IEEE Computer Society
• Datum: 10.2024
• Dokumenttyp: Fachstandard / Body of Knowledge
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Systematische Wissensgebiete professioneller Softwareentwicklung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.computer.org/education/bodies-of-knowledge/software-engineering](https://www.computer.org/education/bodies-of-knowledge/software-engineering)

Organisation und Messung

^[S-006] State of AI-assisted Software Development 2025

• Autor/Herausgeber: DORA / Google Cloud
• Datum: 09.2025
• Dokumenttyp: Empirischer Branchenforschungsbericht
• Status: Aktueller Jahresbericht
• Relevanz: AI als Verstärker vorhandener organisatorischer Stärken und Schwächen.
• Refresh-Priorität: hoch
• Direkte URL: [https://dora.dev/dora-report-2025/](https://dora.dev/dora-report-2025/)

Versionsverwaltung

^[S-007] Pro Git, Second Edition

• Autor/Herausgeber: Scott Chacon und Ben Straub / Git
• Datum: Living Book; geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuch
• Status: Living Documentation
• Relevanz: Grundlage für verteilte Versionsverwaltung und nachvollziehbare Änderungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2)

Versionierung

^[S-008] Semantic Versioning 2.0.0

• Autor/Herausgeber: Semantic Versioning
• Datum: 2013
• Dokumenttyp: Offene Spezifikation
• Status: Version 2.0.0
• Relevanz: Maschinen- und menschenlesbare Regeln für kompatible und inkompatible Versionsänderungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://semver.org/](https://semver.org/)

Secure SDLC

^[S-009] SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1

• Autor/Herausgeber: NIST
• Datum: 03.02.2022
• Dokumenttyp: Behördenstandard
• Status: Final
• Relevanz: Sicherheitspraktiken, die in unterschiedliche SDLC-Modelle integriert werden können.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/218/final](https://csrc.nist.gov/pubs/sp/800/218/final)

Secure AI Development

^[S-010] SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models

• Autor/Herausgeber: NIST
• Datum: 26.07.2024
• Dokumenttyp: Behördenstandard / Community Profile
• Status: Final
• Relevanz: Ergänzt SSDF 1.1 um Praktiken für KI-Modelle und KI-Systeme.
• Refresh-Priorität: hoch
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/218/a/final](https://csrc.nist.gov/pubs/sp/800/218/a/final)

Cybersecurity-Governance

^[S-011] The NIST Cybersecurity Framework (CSF) 2.0

• Autor/Herausgeber: NIST
• Datum: 26.02.2024
• Dokumenttyp: Behördenrahmenwerk
• Status: Final
• Relevanz: Govern, Identify, Protect, Detect, Respond und Recover als Cyber-Risikofunktionen.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)

Incident Response

^[S-012] SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management

• Autor/Herausgeber: NIST
• Datum: 03.04.2025
• Dokumenttyp: Behördenstandard / Community Profile
• Status: Final
• Relevanz: Incident Response als Teil des laufenden Cyber-Risikomanagements.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/61/r3/final](https://csrc.nist.gov/pubs/sp/800/61/r3/final)

Security Testing

^[S-013] SP 800-115 — Technical Guide to Information Security Testing and Assessment

• Autor/Herausgeber: NIST
• Datum: 09.2008
• Dokumenttyp: Behördenleitfaden
• Status: Final; methodische Grundlage
• Relevanz: Planung und Durchführung technischer Sicherheitsprüfungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/115/final](https://csrc.nist.gov/pubs/sp/800/115/final)

Backup und Notfallbetrieb

^[S-014] SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems

• Autor/Herausgeber: NIST
• Datum: 11.11.2010
• Dokumenttyp: Behördenleitfaden
• Status: Final; älter, aber weiterhin referenziert
• Relevanz: Business Impact Analysis, Wiederanlauf, Übungen und Pflege von Notfallplänen.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

^[S-015] BSI-Standard 200-4 — Business Continuity Management

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik
• Datum: 14.06.2023
• Dokumenttyp: Behördenstandard
• Status: Final
• Relevanz: Praxisrahmen zum Aufbau eines BCMS.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.html](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.html)

Cybersecurity-Governance

^[S-016] ISO/IEC 27001:2022 — Information security management systems — Requirements

• Autor/Herausgeber: ISO / IEC
• Datum: 2022
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Anforderungen an ein Informationssicherheits-Managementsystem.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/27001](https://www.iso.org/standard/27001)

Versionsverwaltung und Review

^[S-017] About protected branches

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schutzregeln, Reviews und Statusprüfungen für zentrale Branches.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)

CI und Qualitätsgates

^[S-018] About status checks

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte Prüfergebnisse als Merge-Bedingung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/pull-requests/reference/status-checks](https://docs.github.com/en/pull-requests/reference/status-checks)

CI/CD-Sicherheit

^[S-019] Secure use reference — GitHub Actions

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Sicherheitskontrollen für CI/CD-Workflows und Umgebungsfreigaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/reference/security/secure-use](https://docs.github.com/en/actions/reference/security/secure-use)

Deployment

^[S-020] Managing environments for deployment

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Deployment-Schutzregeln und getrennte Umgebungssecrets.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/actions/deployment/targeting-different-environments/using-environments-for-deployment](https://docs.github.com/actions/deployment/targeting-different-environments/using-environments-for-deployment)

CI/CD-Sicherheit

^[S-021] OpenID Connect in GitHub Actions

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Kurzlebige föderierte Cloud-Anmeldung statt dauerhaft gespeicherter Zugangsschlüssel.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/concepts/security/openid-connect](https://docs.github.com/en/actions/concepts/security/openid-connect)

Software-Lieferkette

^[S-022] Using artifact attestations to establish provenance for builds

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Provenienz- und Attestierungsfunktionen für Build-Artefakte.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds)

Schnittstellen und Verträge

^[S-023] OpenAPI Specification 3.2.0

• Autor/Herausgeber: OpenAPI Initiative
• Datum: 19.09.2025
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle Fassung am Stichtag
• Relevanz: Maschinenlesbarer Vertrag für HTTP-APIs.
• Refresh-Priorität: hoch
• Direkte URL: [https://spec.openapis.org/oas/v3.2.0.html](https://spec.openapis.org/oas/v3.2.0.html)

^[S-024] JSON Schema — Draft 2020-12 Core

• Autor/Herausgeber: JSON Schema project
• Datum: 31.08.2022
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle stabile Draft-Familie am Stichtag
• Relevanz: Validierung und Beschreibung strukturierter JSON-Daten.
• Refresh-Priorität: mittel
• Direkte URL: [https://json-schema.org/draft/2020-12/json-schema-core](https://json-schema.org/draft/2020-12/json-schema-core)

Schnittstellen und Reliability

^[S-025] RFC 9110 — HTTP Semantics

• Autor/Herausgeber: IETF / Fielding, Nottingham und Reschke
• Datum: 06.2022
• Dokumenttyp: Internetstandard
• Status: Standards Track
• Relevanz: HTTP-Semantik, Methoden, Statuscodes und Idempotenz.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9110.html](https://www.rfc-editor.org/rfc/rfc9110.html)

Schnittstellen und Fehlerbehandlung

^[S-026] RFC 9457 — Problem Details for HTTP APIs

• Autor/Herausgeber: IETF / Nottingham, Wilde und Dalal
• Datum: 07.2023
• Dokumenttyp: Internetstandard
• Status: Standards Track
• Relevanz: Standardisiertes Fehlerformat für HTTP-APIs.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9457.html](https://www.rfc-editor.org/rfc/rfc9457.html)

Ereignisse und Integration

^[S-027] CloudEvents Specification 1.0.2

• Autor/Herausgeber: Cloud Native Computing Foundation
• Datum: 03.02.2022
• Dokumenttyp: Offene Spezifikation
• Status: Version 1.0.2
• Relevanz: Standardisiertes Ereignisformat für verteilte Systeme.
• Refresh-Priorität: mittel
• Direkte URL: [https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md)

Softwaretests

^[S-028] Test Sizes

• Autor/Herausgeber: Google Testing Blog
• Datum: 14.12.2010
• Dokumenttyp: Technischer Fachbeitrag
• Status: Google-Testpraxis; historisch stabil
• Relevanz: Abgrenzung kleiner, mittlerer und großer Tests nach Ressourcen und Laufzeit.
• Refresh-Priorität: niedrig
• Direkte URL: [https://testing.googleblog.com/2010/12/test-sizes.html](https://testing.googleblog.com/2010/12/test-sizes.html)

^[S-029] The Practical Test Pyramid

• Autor/Herausgeber: Martin Fowler
• Datum: 01.02.2018
• Dokumenttyp: Technischer Fachbeitrag
• Status: Praxisreferenz
• Relevanz: Mehrschichtige Teststrategie statt ausschließlicher End-to-End-Tests.
• Refresh-Priorität: niedrig
• Direkte URL: [https://martinfowler.com/articles/practical-test-pyramid.html](https://martinfowler.com/articles/practical-test-pyramid.html)

Security Testing

^[S-030] Web Security Testing Guide

• Autor/Herausgeber: OWASP
• Datum: Version 4.2; Version 5 in Entwicklung, geprüft 08.08.2026
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle veröffentlichte Ausgabe 4.2
• Relevanz: Systematische Webanwendungs-Sicherheitstests.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/www-project-web-security-testing-guide/](https://owasp.org/www-project-web-security-testing-guide/)

^[S-031] Application Security Verification Standard 5.0.0

• Autor/Herausgeber: OWASP
• Datum: 30.05.2025
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Hauptversion
• Relevanz: Prüfbare Sicherheitsanforderungen für Webanwendungen und Services.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/)

^[S-032] OWASP Top 10:2025

• Autor/Herausgeber: OWASP
• Datum: 2025
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe
• Relevanz: Häufige und folgenreiche Risiken in Webanwendungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/Top10/2025/](https://owasp.org/Top10/2025/)

API-Sicherheit

^[S-033] OWASP API Security Top 10 — 2023

• Autor/Herausgeber: OWASP
• Datum: 2023
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Risikokategorien für APIs, einschließlich Autorisierung und Ressourcenverbrauch.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/API-Security/editions/2023/en/0x11-t10/](https://owasp.org/API-Security/editions/2023/en/0x11-t10/)

Konfiguration und Secrets

^[S-034] Secrets Management Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Lebenszyklus und Schutz von Zugangsdaten und Schlüsseln.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)

Observability und Security

^[S-035] Logging Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Sicherheitsrelevante Protokollierung ohne unnötige Geheimnis- oder Personendaten.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)

Anwendungssicherheit

^[S-036] Authorization Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Serverseitige Autorisierung und Least Privilege.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)

KI-Sicherheit

^[S-037] OWASP GenAI LLM Top 10 2026

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 03.08.2026
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Aktuelle Risikokategorien für generative KI-Anwendungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)

^[S-038] MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems

• Autor/Herausgeber: MITRE
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Wissensbasis
• Status: Living Knowledge Base
• Relevanz: Taktiken und Techniken gegen KI-fähige Systeme.
• Refresh-Priorität: hoch
• Direkte URL: [https://atlas.mitre.org/](https://atlas.mitre.org/)

KI-Evaluation

^[S-039] Evaluation best practices

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Aktueller Leitfaden; Evals-Plattform mit angekündigter Abschaltung zum 30.11.2026
• Relevanz: Herstellerpraxis für aufgabenspezifische Datensätze, Evaluatoren, menschliche Kalibrierung und kontinuierliche Evaluation.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/evaluation-best-practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)

^[S-040] Define success criteria and build evaluations

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Erfolgskriterien, Testfälle und Evaluation für LLM-Anwendungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://platform.claude.com/docs/en/test-and-evaluate/develop-tests](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)

Container und Build

^[S-041] Building best practices

• Autor/Herausgeber: Docker
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Kleine Build-Kontexte, Multi-Stage Builds, Version-Pinning und regelmäßige Rebuilds.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.docker.com/build/building/best-practices/](https://docs.docker.com/build/building/best-practices/)

^[S-042] Image digests and immutability

• Autor/Herausgeber: Docker
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Unveränderliche Inhaltsadressierung von Containerbildern.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.docker.com/dhi/explore/security-concepts/digests/](https://docs.docker.com/dhi/explore/security-concepts/digests/)

Secure SDLC

^[S-043] Secure by Design

• Autor/Herausgeber: CISA
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Behördenleitlinie
• Status: Living Guidance
• Relevanz: Herstellerverantwortung und sichere Standardeinstellungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/secure-by-design](https://www.cisa.gov/resources-tools/resources/secure-by-design)

^[S-044] Product Security Bad Practices

• Autor/Herausgeber: CISA
• Datum: 17.01.2025
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Klar benannte Praktiken, die bei kritischer Software vermieden werden sollen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/product-security-bad-practices](https://www.cisa.gov/resources-tools/resources/product-security-bad-practices)

Recht und Produktbetrieb

^[S-045] Verordnung (EU) 2024/2847 — Cyber Resilience Act

• Autor/Herausgeber: Europäische Union
• Datum: 23.10.2024; ABl. 20.11.2024
• Dokumenttyp: EU-Verordnung
• Status: In Kraft; gestaffelte Anwendung
• Relevanz: Horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)

Reliability

^[S-046] Timeouts, retries, and backoff with jitter

• Autor/Herausgeber: Amazon Web Services
• Datum: 12.06.2026
• Dokumenttyp: Offizieller Engineering-Fachbeitrag
• Status: Aktualisierte Fassung
• Relevanz: Timeouts, begrenzte Wiederholungen, Backoff, Jitter und Retry-Amplifikation.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)

^[S-047] Making retries safe with idempotent APIs

• Autor/Herausgeber: Amazon Web Services
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizieller Engineering-Fachbeitrag
• Status: Living Documentation
• Relevanz: Idempotenzschlüssel und sichere Wiederholbarkeit zustandsändernder Operationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

^[S-048] Idempotent requests

• Autor/Herausgeber: Stripe
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Konkrete API-Praxis für Idempotenzschlüssel.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.stripe.com/api/idempotent_requests](https://docs.stripe.com/api/idempotent_requests)

Site Reliability Engineering

^[S-049] The Site Reliability Workbook

• Autor/Herausgeber: Google
• Datum: 2018
• Dokumenttyp: Offizielles Fachbuch
• Status: Online-Ausgabe
• Relevanz: Praxisrahmen für SLOs, Releases, On-Call, Incident Response und Zuverlässigkeitsarbeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/index/](https://sre.google/workbook/index/)

^[S-050] SRE Engagement Model / Production Readiness Review

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Produktionsreife, Übergabe und gemeinsame Betriebsverantwortung.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/engagement-model/](https://sre.google/workbook/engagement-model/)

^[S-051] Canarying Releases

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Risikoreduktion durch schrittweise Releases und SLO-basierte Bewertung.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/canarying-releases/](https://sre.google/workbook/canarying-releases/)

^[S-052] Implementing SLOs

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Definition, Messung und Nutzung von Service Level Objectives.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/implementing-slos/](https://sre.google/workbook/implementing-slos/)

^[S-053] Alerting on SLOs

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Burn-Rate-basierte Alarmierung statt rein technischer Schwellenwerte.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/alerting-on-slos/](https://sre.google/workbook/alerting-on-slos/)

^[S-054] On-Call

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Betriebsbereitschaft, Eskalation und Balance zwischen Änderung und Stabilität.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/on-call/](https://sre.google/workbook/on-call/)

Incident Response

^[S-055] Incident Response

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Incident Command, Kommunikation, Mitigation und Übungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/incident-response/](https://sre.google/workbook/incident-response/)

Betrieb und Wartung

^[S-056] Eliminating Toil

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Reduktion manueller, wiederholbarer Betriebsarbeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/eliminating-toil/](https://sre.google/workbook/eliminating-toil/)

Observability

^[S-057] Signals

• Autor/Herausgeber: OpenTelemetry
• Datum: 10.03.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Traces, Metrics, Logs, Baggage und Profiles als Telemetriesignale.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/](https://opentelemetry.io/docs/concepts/signals/)

^[S-058] Traces

• Autor/Herausgeber: OpenTelemetry
• Datum: 14.01.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: End-to-End-Sicht auf verteilte Requests.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/traces/](https://opentelemetry.io/docs/concepts/signals/traces/)

^[S-059] Metrics

• Autor/Herausgeber: OpenTelemetry
• Datum: 02.07.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Laufzeitmessungen und zugeordnete Metadaten.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/metrics/](https://opentelemetry.io/docs/concepts/signals/metrics/)

^[S-060] Logs

• Autor/Herausgeber: OpenTelemetry
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Log-API, Bridges und Korrelation mit Traces.
• Refresh-Priorität: hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/logs/](https://opentelemetry.io/docs/concepts/signals/logs/)

^[S-061] Context propagation

• Autor/Herausgeber: OpenTelemetry
• Datum: 14.01.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Korrelation verteilter Telemetriesignale über Prozess- und Netzgrenzen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/context-propagation/](https://opentelemetry.io/docs/concepts/context-propagation/)

KI-Observability

^[S-062] GenAI semantic conventions

• Autor/Herausgeber: OpenTelemetry
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Spezifikation
• Status: Teilweise experimentell; Living Specification
• Relevanz: Semantische Konventionen für Modellaufrufe, Agenten und GenAI-Ereignisse.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/specs/semconv/gen-ai/](https://opentelemetry.io/docs/specs/semconv/gen-ai/)

Backup und Restore

^[S-063] PostgreSQL 18 Documentation — Backup and Restore

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: SQL-Dumps, Dateisystem-Backups und kontinuierliche Archivierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/backup.html](https://www.postgresql.org/docs/current/backup.html)

^[S-064] Continuous Archiving and Point-in-Time Recovery

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: WAL-Archivierung und Wiederherstellung auf einen früheren Zeitpunkt.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/continuous-archiving.html](https://www.postgresql.org/docs/current/continuous-archiving.html)

^[S-065] SQL Dump

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Logische Exporte und Wiederherstellung, auch über Versionsgrenzen hinweg.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/backup-dump.html](https://www.postgresql.org/docs/current/backup-dump.html)

Vulnerability Management

^[S-066] Known Exploited Vulnerabilities Catalog

• Autor/Herausgeber: CISA
• Datum: Living Catalog; geprüft 08.08.2026
• Dokumenttyp: Behördenkatalog
• Status: Kontinuierlich aktualisiert
• Relevanz: Priorisierung tatsächlich ausgenutzter Schwachstellen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.cisa.gov/known-exploited-vulnerabilities-catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

Wartung und Abhängigkeiten

^[S-067] Dependabot security updates

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte Vorschläge für verwundbare Abhängigkeiten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)

^[S-068] Renovate Documentation

• Autor/Herausgeber: Mend Renovate
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte, konfigurierbare Abhängigkeitsaktualisierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.renovatebot.com/](https://docs.renovatebot.com/)

Post-Mortems

^[S-069] Postmortem of database outage of January 31

• Autor/Herausgeber: GitLab
• Datum: 10.02.2017
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Datenlöschung, unzureichend funktionsfähige Backups und Wiederherstellungsprobleme.
• Refresh-Priorität: niedrig
• Direkte URL: [https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)

^[S-070] Details of the Cloudflare outage on July 2, 2019

• Autor/Herausgeber: Cloudflare
• Datum: 02.07.2019
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Katastrophales Regex-Backtracking, globale Schnellverteilung und fehlender Performance-Gate.
• Refresh-Priorität: niedrig
• Direkte URL: [https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/](https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/)

^[S-071] Post-incident review: April 2022 outage

• Autor/Herausgeber: Atlassian Engineering
• Datum: 04.05.2022
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Fehlerhafte Skriptausführung, Löschung von Kundensites und langwierige Wiederherstellung.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.atlassian.com/engineering/post-incident-review-april-2022-outage](https://www.atlassian.com/engineering/post-incident-review-april-2022-outage)

^[S-072] Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach

• Autor/Herausgeber: U.S. Government Accountability Office
• Datum: 30.08.2018
• Dokumenttyp: Behördenbericht
• Status: Primär-/Untersuchungsquelle
• Relevanz: Asset-Erkennung, Patchen, Segmentierung, Erkennung und Datengovernance als Ausfallfaktoren.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.gao.gov/products/gao-18-559](https://www.gao.gov/products/gao-18-559)

^[S-073] Executive Summary: Root Cause Analysis — Channel File 291

• Autor/Herausgeber: CrowdStrike
• Datum: 06.08.2024
• Dokumenttyp: Unternehmens-Root-Cause-Analyse
• Status: Primärbericht des Herstellers
• Relevanz: Fehlerhafte Content-Konfiguration, unzureichende Validierung und weltweite Ausrollung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.crowdstrike.com/wp-content/uploads/2024/08/Executive-Summary_Root-Cause-Analysis_Channel-File-291.pdf](https://www.crowdstrike.com/wp-content/uploads/2024/08/Executive-Summary_Root-Cause-Analysis_Channel-File-291.pdf)

Recht und Compliance

^[S-074] Verordnung (EU) 2016/679 — Datenschutz-Grundverordnung

• Autor/Herausgeber: Europäische Union
• Datum: 27.04.2016
• Dokumenttyp: EU-Verordnung
• Status: In Kraft
• Relevanz: Datenschutzrechtliche Anforderungen an personenbezogene Daten in Entwicklung und Betrieb.
• Refresh-Priorität: mittel
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

^[S-075] Verordnung (EU) 2024/1689 — AI Act

• Autor/Herausgeber: Europäische Union
• Datum: 13.06.2024
• Dokumenttyp: EU-Verordnung
• Status: In Kraft; gestaffelte Anwendung
• Relevanz: Pflichten über den Lebenszyklus bestimmter KI-Systeme, einschließlich Qualität und Monitoring.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)

Recht: digitale Dienste

^[S-076] Digitale-Dienste-Gesetz (DDG)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 06.05.2024; zuletzt geändert 12.05.2026
• Dokumenttyp: Bundesgesetz
• Status: In Kraft; aktueller Gesetzesstand am Stichtag
• Relevanz: Grundrahmen für digitale Dienste und aktuelle Terminologie; ersetzt das TMG.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/ddg/BJNR0950B0024.html](https://www.gesetze-im-internet.de/ddg/BJNR0950B0024.html)

Recht: Anbieterkennzeichnung

^[S-077] § 5 DDG — Allgemeine Informationspflichten

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 06.05.2024; zuletzt geändert 12.05.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Anbieterkennzeichnung für geschäftsmäßige digitale Dienste.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/ddg/__5.html](https://www.gesetze-im-internet.de/ddg/__5.html)

^[S-078] § 6 DDG — Besondere Informationspflichten bei kommerziellen Kommunikationen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 06.05.2024; zuletzt geändert 12.05.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Erkennbarkeit kommerzieller Kommunikation und weiterer Angaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/ddg/__6.html](https://www.gesetze-im-internet.de/ddg/__6.html)

Recht: Datenschutz und Endgeräte

^[S-079] Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 23.06.2021; Terminologie geändert mit Wirkung 14.05.2024
• Dokumenttyp: Bundesgesetz
• Status: In Kraft; URL-Pfad trägt historisch weiterhin ttdsg
• Relevanz: Schutz der Privatsphäre in Endeinrichtungen und Regeln für digitale Dienste.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/ttdsg/BJNR198210021.html](https://www.gesetze-im-internet.de/ttdsg/BJNR198210021.html)

^[S-080] § 25 TDDDG — Schutz der Privatsphäre bei Endeinrichtungen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 23.06.2021; Terminologie geändert 14.05.2024
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Einwilligungsgrundsatz und Ausnahmen für Speichern/Auslesen in Endeinrichtungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/ttdsg/__25.html](https://www.gesetze-im-internet.de/ttdsg/__25.html)

Datenschutz: Website-Technologien

^[S-081] Orientierungshilfe für Anbieter:innen von digitalen Diensten, Version 1.2

• Autor/Herausgeber: Datenschutzkonferenz (DSK)
• Datum: 11.2024
• Dokumenttyp: Behördenorientierung
• Status: Aktuelle DSK-Fassung am Stichtag
• Relevanz: Praxisleitlinie zu § 25 TDDDG, DSGVO-Folgeprozessen und Consent-Bannern.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf](https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf)

Datenschutz: Consent Management

^[S-082] Einwilligungsverwaltungsverordnung (EinwV)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 06.02.2025; in Kraft seit 01.04.2025
• Dokumenttyp: Bundesverordnung
• Status: In Kraft
• Relevanz: Anerkannte Einwilligungsverwaltungsdienste nach TDDDG.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/einwv/BJNR0200B0025.html](https://www.gesetze-im-internet.de/einwv/BJNR0200B0025.html)

Datenschutz: ePrivacy

^[S-083] Richtlinie 2002/58/EG über Privatsphäre und elektronische Kommunikation

• Autor/Herausgeber: Europäische Union
• Datum: 12.07.2002; konsolidierter Stand geprüft 08.08.2026
• Dokumenttyp: EU-Richtlinie
• Status: In Kraft; mehrfach geändert
• Relevanz: Europäische Grundlage für Vertraulichkeit und Endgerätezugriffe.
• Refresh-Priorität: hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/dir/2002/58/oj](https://eur-lex.europa.eu/eli/dir/2002/58/oj)

^[S-084] Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive

• Autor/Herausgeber: European Data Protection Board
• Datum: 07.10.2024
• Dokumenttyp: Behördenleitlinie
• Status: Final nach öffentlicher Konsultation
• Relevanz: Technischer Anwendungsbereich von Speichern und Zugriffen auf Endgeräte.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en)

Datenschutz: Einwilligung

^[S-085] Guidelines 05/2020 on consent under Regulation 2016/679

• Autor/Herausgeber: European Data Protection Board
• Datum: 04.05.2020
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Anforderungen an freiwillige, informierte, spezifische und widerrufliche Einwilligung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf)

Datenschutz: Rollen

^[S-086] Guidelines 07/2020 on the concepts of controller and processor in the GDPR

• Autor/Herausgeber: European Data Protection Board
• Datum: 07.07.2021
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Rollenverteilung Verantwortlicher, gemeinsam Verantwortliche und Auftragsverarbeiter.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.edpb.europa.eu/system/files/2023-10/edpb_guidelines_202007_controllerprocessor_final_en.pdf](https://www.edpb.europa.eu/system/files/2023-10/edpb_guidelines_202007_controllerprocessor_final_en.pdf)

Datenschutz: Privacy by Design

^[S-087] Guidelines 4/2019 on Article 25 Data Protection by Design and by Default

• Autor/Herausgeber: European Data Protection Board
• Datum: 20.10.2020
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf)

Datenschutz: Incident

^[S-088] Guidelines 9/2022 on personal data breach notification under GDPR

• Autor/Herausgeber: European Data Protection Board
• Datum: 28.03.2023
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Bewertung und Meldung von Verletzungen des Schutzes personenbezogener Daten.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.edpb.europa.eu/system/files/2023-04/edpb_guidelines_202209_personal_data_breach_notification_v2.0_en.pdf](https://www.edpb.europa.eu/system/files/2023-04/edpb_guidelines_202209_personal_data_breach_notification_v2.0_en.pdf)

Datenschutz: Consent Banner

^[S-089] Cookie Banner Taskforce report

• Autor/Herausgeber: European Data Protection Board
• Datum: 17.01.2023
• Dokumenttyp: Behördenbericht
• Status: Angenommen
• Relevanz: Gemeinsame Behördenpositionen zu typischen Cookie-Banner-Gestaltungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf)

Datenschutz: Drittlandtransfer

^[S-090] Durchführungsbeschluss (EU) 2021/914 — Standardvertragsklauseln

• Autor/Herausgeber: Europäische Kommission
• Datum: 04.06.2021
• Dokumenttyp: EU-Durchführungsbeschluss
• Status: In Kraft
• Relevanz: Instrument für bestimmte Drittlandübermittlungen personenbezogener Daten.
• Refresh-Priorität: mittel
• Direkte URL: [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj](https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj)

^[S-091] Durchführungsbeschluss (EU) 2023/1795 — EU-US Data Privacy Framework

• Autor/Herausgeber: Europäische Kommission
• Datum: 10.07.2023
• Dokumenttyp: Angemessenheitsbeschluss
• Status: In Kraft am Stichtag; Rechtsentwicklung beobachten
• Relevanz: Angemessenheitsrahmen für zertifizierte US-Organisationen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj](https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj)

^[S-092] Urteil C-311/18 — Data Protection Commissioner gegen Facebook Ireland und Maximillian Schrems

• Autor/Herausgeber: Gerichtshof der Europäischen Union
• Datum: 16.07.2020
• Dokumenttyp: Gerichtsentscheidung
• Status: Rechtskräftig
• Relevanz: Prüfpflichten und ergänzende Maßnahmen bei Drittlandtransfers.
• Refresh-Priorität: mittel
• Direkte URL: [https://curia.europa.eu/juris/liste.jsf?num=C-311/18](https://curia.europa.eu/juris/liste.jsf?num=C-311/18)

Datenschutz: Cookies

^[S-093] Urteil C-673/17 — Planet49

• Autor/Herausgeber: Gerichtshof der Europäischen Union
• Datum: 01.10.2019
• Dokumenttyp: Gerichtsentscheidung
• Status: Rechtskräftig
• Relevanz: Einwilligung in Cookies und Informationsanforderungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://curia.europa.eu/juris/liste.jsf?num=C-673/17](https://curia.europa.eu/juris/liste.jsf?num=C-673/17)

Datenschutz: KI-Funktionen

^[S-094] Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen

• Autor/Herausgeber: Datenschutzkonferenz (DSK)
• Datum: 06.2025
• Dokumenttyp: Behördenorientierung
• Status: Aktuelle Fassung am Stichtag
• Relevanz: TOM, Datenflüsse und Schutzmaßnahmen für KI-Funktionen in Websystemen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf](https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf)

Recht: Medien

^[S-095] Medienstaatsvertrag (MStV), konsolidierte Fassung

• Autor/Herausgeber: Die Medienanstalten
• Datum: Stand geprüft 08.08.2026; Veröffentlichungsdatum der Fassung UNKLAR
• Dokumenttyp: Staatsvertrag / konsolidierter Text
• Status: Aktuelle Websitefassung prüfen
• Relevanz: Zusätzliche Anbieterkennzeichnung bei journalistisch-redaktionellen Angeboten.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.die-medienanstalten.de/fileadmin/user_upload/Rechtsgrundlagen/Gesetze_Staatsvertraege/Medienstaatsvertrag_MStV.pdf](https://www.die-medienanstalten.de/fileadmin/user_upload/Rechtsgrundlagen/Gesetze_Staatsvertraege/Medienstaatsvertrag_MStV.pdf)

Recht: Inhalte und Software

^[S-096] Urheberrechtsgesetz (UrhG)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 09.09.1965; aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz
• Status: In Kraft
• Relevanz: Rechte an Texten, Bildern, Software, Datenbanken und Nutzungsrechten.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/urhg/BJNR012730965.html](https://www.gesetze-im-internet.de/urhg/BJNR012730965.html)

Recht: Bilder und Personen

^[S-097] Kunsturhebergesetz (KunstUrhG)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 09.01.1907; aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz
• Status: In Kraft
• Relevanz: Bildnisse und Veröffentlichung von Personenabbildungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.gesetze-im-internet.de/kunsturhg/BJNR000070907.html](https://www.gesetze-im-internet.de/kunsturhg/BJNR000070907.html)

Recht: Kennzeichen

^[S-098] Markengesetz (MarkenG)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 25.10.1994; aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz
• Status: In Kraft
• Relevanz: Kennzeichen-, Marken- und Namensrisiken bei Domains und Webauftritten.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.gesetze-im-internet.de/markeng/BJNR308210994.html](https://www.gesetze-im-internet.de/markeng/BJNR308210994.html)

Barrierefreiheit: Recht

^[S-099] Barrierefreiheitsstärkungsgesetz (BFSG)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 16.07.2021; anwendbar seit 28.06.2025
• Dokumenttyp: Bundesgesetz
• Status: In Kraft
• Relevanz: Pflichten für erfasste Produkte und Dienstleistungen einschließlich E-Commerce.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bfsg/BJNR297010021.html](https://www.gesetze-im-internet.de/bfsg/BJNR297010021.html)

^[S-100] § 2 BFSG — Begriffsbestimmungen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 16.07.2021
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Definition von Kleinstunternehmen und Dienstleistungen im elektronischen Geschäftsverkehr.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bfsg/__2.html](https://www.gesetze-im-internet.de/bfsg/__2.html)

^[S-101] § 3 BFSG — Barrierefreiheit und Kleinstunternehmensausnahme

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 16.07.2021
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Grundpflicht und Ausnahme für Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bfsg/__3.html](https://www.gesetze-im-internet.de/bfsg/__3.html)

^[S-102] Barrierefreiheitsstärkungsverordnung (BFSGV)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 15.06.2022; zuletzt geändert 10.07.2026
• Dokumenttyp: Bundesverordnung
• Status: In Kraft; Änderung Juli 2026 berücksichtigt
• Relevanz: Konkrete Anforderungen an Dienstleistungen, Websites, Apps und E-Commerce-Funktionen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bfsgv/BJNR092800022.html](https://www.gesetze-im-internet.de/bfsgv/BJNR092800022.html)

^[S-103] § 12 BFSGV — Allgemeine Anforderungen an Dienstleistungen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 15.06.2022; zuletzt geändert 10.07.2026
• Dokumenttyp: Bundesverordnung / Einzelnorm
• Status: In Kraft
• Relevanz: Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit von Websites und Apps.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bfsgv/__12.html](https://www.gesetze-im-internet.de/bfsgv/__12.html)

^[S-104] § 19 BFSGV — Zusätzliche Anforderungen an E-Commerce-Dienstleistungen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 15.06.2022; zuletzt geändert 10.07.2026
• Dokumenttyp: Bundesverordnung / Einzelnorm
• Status: In Kraft
• Relevanz: Barrierefreiheit von Information, Identifizierung, Authentifizierung, Sicherheit und Zahlung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bfsgv/__19.html](https://www.gesetze-im-internet.de/bfsgv/__19.html)

Barrierefreiheit: öffentlicher Sektor

^[S-105] § 12a BGG — Barrierefreie Informationstechnik öffentlicher Stellen des Bundes

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 10.07.2018; aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Bundesrechtliche Pflichten öffentlicher Stellen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bgg/__12a.html](https://www.gesetze-im-internet.de/bgg/__12a.html)

^[S-106] Barrierefreie-Informationstechnik-Verordnung (BITV 2.0)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 12.09.2011; aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesverordnung
• Status: In Kraft
• Relevanz: Technische Konkretisierung für Bundesstellen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bitv_2_0/BJNR184300011.html](https://www.gesetze-im-internet.de/bitv_2_0/BJNR184300011.html)

Barrierefreiheit: Standards

^[S-107] Web Content Accessibility Guidelines (WCAG) 2.2

• Autor/Herausgeber: W3C
• Datum: 12.12.2024
• Dokumenttyp: W3C Recommendation
• Status: Aktuelle W3C-Empfehlung am Stichtag
• Relevanz: Internationaler technischer Referenzrahmen für barrierefreie Webinhalte.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/TR/WCAG22/](https://www.w3.org/TR/WCAG22/)

^[S-108] How to Meet WCAG 2 (Quick Reference)

• Autor/Herausgeber: W3C Web Accessibility Initiative
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Umsetzungshilfe
• Status: Living Documentation
• Relevanz: Filterbare Kriterien, Techniken und Fehlerbeispiele.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/WAI/WCAG22/quickref/](https://www.w3.org/WAI/WCAG22/quickref/)

^[S-109] EN 301 549 V3.2.1 — Accessibility requirements for ICT products and services

• Autor/Herausgeber: ETSI / CEN / CENELEC
• Datum: 03.2021
• Dokumenttyp: Europäische Norm
• Status: Gültige veröffentlichte Fassung; Revisionen beobachten
• Relevanz: Europäischer ICT-Barrierefreiheitsstandard mit Webanforderungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf](https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf)

^[S-110] Accessible Rich Internet Applications (WAI-ARIA) 1.2

• Autor/Herausgeber: W3C
• Datum: 06.06.2023
• Dokumenttyp: W3C Recommendation
• Status: Aktuelle Recommendation am Stichtag
• Relevanz: Semantik und Zustände für zugängliche Webkomponenten.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.w3.org/TR/wai-aria-1.2/](https://www.w3.org/TR/wai-aria-1.2/)

Barrierefreiheit: Praxis

^[S-111] ARIA Authoring Practices Guide

• Autor/Herausgeber: W3C Web Accessibility Initiative
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Umsetzungshilfe
• Status: Living Documentation
• Relevanz: Muster, Tastaturinteraktion und Beispiele für komplexe Komponenten.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/WAI/ARIA/apg/](https://www.w3.org/WAI/ARIA/apg/)

Barrierefreiheit: Formulare

^[S-112] Forms Tutorial

• Autor/Herausgeber: W3C Web Accessibility Initiative
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Umsetzungshilfe
• Status: Living Documentation
• Relevanz: Beschriftung, Gruppierung, Anweisungen, Validierung und Rückmeldung in Formularen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/WAI/tutorials/forms/](https://www.w3.org/WAI/tutorials/forms/)

Barrierefreiheit: Inhalte

^[S-113] Images Tutorial and Alt Decision Tree

• Autor/Herausgeber: W3C Web Accessibility Initiative
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Umsetzungshilfe
• Status: Living Documentation
• Relevanz: Entscheidungslogik für Alternativtexte und dekorative Bilder.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/WAI/tutorials/images/decision-tree/](https://www.w3.org/WAI/tutorials/images/decision-tree/)

Barrierefreiheit: Formulare

^[S-114] Inaccessibility of CAPTCHA

• Autor/Herausgeber: W3C
• Datum: 16.12.2019
• Dokumenttyp: W3C Working Group Note
• Status: Veröffentlichte Note
• Relevanz: Zugänglichkeitsrisiken und Alternativen zu bild-/audiozentrierten CAPTCHAs.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.w3.org/TR/turingtest/](https://www.w3.org/TR/turingtest/)

E-Commerce: Verbraucherrecht

^[S-115] § 312d BGB — Informationspflichten

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Informationspflichten bei Fernabsatz- und außerhalb von Geschäftsräumen geschlossenen Verträgen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bgb/__312d.html](https://www.gesetze-im-internet.de/bgb/__312d.html)

E-Commerce: Checkout

^[S-116] § 312j BGB — Pflichten im elektronischen Geschäftsverkehr gegenüber Verbrauchern

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Bestellübersicht und ausdrückliche Bestätigung der Zahlungspflicht.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bgb/__312j.html](https://www.gesetze-im-internet.de/bgb/__312j.html)

E-Commerce: Verbraucherrecht

^[S-117] § 355 BGB — Widerrufsrecht bei Verbraucherverträgen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Grundmechanik des Verbraucherwiderrufs.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bgb/__355.html](https://www.gesetze-im-internet.de/bgb/__355.html)

^[S-118] § 356 BGB — Widerrufsrecht bei außerhalb von Geschäftsräumen geschlossenen Verträgen und Fernabsatzverträgen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Beginn und Besonderheiten der Widerrufsfrist, digitale Inhalte und Dienstleistungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bgb/__356.html](https://www.gesetze-im-internet.de/bgb/__356.html)

^[S-119] Art. 246a § 1 EGBGB — Informationspflichten bei Fernabsatzverträgen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Vorvertragliche Pflichtinformationen im B2C-Fernabsatz.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bgbeg/art_246a__1.html](https://www.gesetze-im-internet.de/bgbeg/art_246a__1.html)

^[S-120] Art. 246a § 4 EGBGB — Formale Anforderungen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Art und Zeitpunkt der Bereitstellung von Verbraucherinformationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/bgbeg/art_246a__4.html](https://www.gesetze-im-internet.de/bgbeg/art_246a__4.html)

E-Commerce: Preisangaben

^[S-121] Preisangabenverordnung (PAngV)

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 12.11.2021; zuletzt geändert 12.05.2026
• Dokumenttyp: Bundesverordnung
• Status: In Kraft; Stand Mai 2026
• Relevanz: Gesamtpreis, Grundpreis, Fernabsatz und Preisermäßigungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.gesetze-im-internet.de/pangv_2022/BJNR492110021.html](https://www.gesetze-im-internet.de/pangv_2022/BJNR492110021.html)

E-Commerce: Streitbeilegung

^[S-122] § 36 VSBG — Allgemeine Informationspflicht

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 19.02.2016; aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Information zur Teilnahme an Verbraucherschlichtung unter den gesetzlichen Voraussetzungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/vsbg/__36.html](https://www.gesetze-im-internet.de/vsbg/__36.html)

^[S-123] § 37 VSBG — Informationen nach Entstehen der Streitigkeit

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: 19.02.2016; aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Information über zuständige Verbraucherschlichtungsstelle nach erfolgloser direkter Streitbeilegung.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/vsbg/__37.html](https://www.gesetze-im-internet.de/vsbg/__37.html)

^[S-124] Verordnung (EU) 2024/3228 zur Einstellung der europäischen ODR-Plattform

• Autor/Herausgeber: Europäische Union
• Datum: 19.12.2024
• Dokumenttyp: EU-Verordnung
• Status: ODR-Plattform eingestellt; Daten bis 20.07.2025 gelöscht
• Relevanz: Aktualisiert alte Website-Muster, die weiterhin auf die eingestellte OS-Plattform verlinken.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/3228/oj](https://eur-lex.europa.eu/eli/reg/2024/3228/oj)

E-Commerce: Produktsicherheit

^[S-125] Konsolidierte Verordnung (EU) 2023/988 über die allgemeine Produktsicherheit

• Autor/Herausgeber: Europäische Union
• Datum: 29.05.2026
• Dokumenttyp: Konsolidierter EU-Rechtsakt
• Status: In Kraft; anwendbar seit 13.12.2024
• Relevanz: Produkt- und Sicherheitsinformationen in Onlineangeboten sowie Pflichten von Marktplätzen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2023/988/2026-05-29/deu](https://eur-lex.europa.eu/eli/reg/2023/988/2026-05-29/deu)

E-Commerce: Plattformen

^[S-126] Verordnung (EU) 2022/2065 — Digital Services Act

• Autor/Herausgeber: Europäische Union
• Datum: 19.10.2022
• Dokumenttyp: EU-Verordnung
• Status: In Kraft und anwendbar
• Relevanz: Zusatzpflichten für Vermittlungsdienste, Hostingdienste, Plattformen und Marktplätze.
• Refresh-Priorität: hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2022/2065/oj/deu](https://eur-lex.europa.eu/eli/reg/2022/2065/oj/deu)

E-Commerce: Lauterkeit

^[S-127] § 5a UWG — Irreführung durch Unterlassen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Vorenthalten wesentlicher Informationen in geschäftlichen Handlungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/uwg_2004/__5a.html](https://www.gesetze-im-internet.de/uwg_2004/__5a.html)

^[S-128] § 5b UWG — Wesentliche Informationen

• Autor/Herausgeber: Bundesministerium der Justiz / Bundesamt für Justiz
• Datum: Aktueller Stand geprüft 08.08.2026
• Dokumenttyp: Bundesgesetz / Einzelnorm
• Status: In Kraft
• Relevanz: Wesentliche Informationen bei Aufforderungen zum Kauf und Rankings.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.gesetze-im-internet.de/uwg_2004/__5b.html](https://www.gesetze-im-internet.de/uwg_2004/__5b.html)

Zahlung und Checkout

^[S-129] Richtlinie (EU) 2015/2366 über Zahlungsdienste (PSD2)

• Autor/Herausgeber: Europäische Union
• Datum: 25.11.2015
• Dokumenttyp: EU-Richtlinie
• Status: In Kraft; künftige Reformen beobachten
• Relevanz: Grundrahmen für Zahlungsdienste und starke Kundenauthentifizierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/dir/2015/2366/oj](https://eur-lex.europa.eu/eli/dir/2015/2366/oj)

^[S-130] Delegierte Verordnung (EU) 2018/389 zu starker Kundenauthentifizierung und sicheren offenen Standards

• Autor/Herausgeber: Europäische Kommission
• Datum: 27.11.2017
• Dokumenttyp: EU-Verordnung
• Status: In Kraft
• Relevanz: Technische Anforderungen an SCA und sichere Kommunikation.
• Refresh-Priorität: hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg_del/2018/389/oj](https://eur-lex.europa.eu/eli/reg_del/2018/389/oj)

^[S-131] PCI Data Security Standard v4.0.1

• Autor/Herausgeber: PCI Security Standards Council
• Datum: 11.06.2024
• Dokumenttyp: Industriestandard
• Status: Aktuelle Revision am Stichtag
• Relevanz: Sicherheitsanforderungen für Umgebungen, die Zahlungskartendaten speichern, verarbeiten oder übertragen.
• Refresh-Priorität: hoch
• Direkte URL: [https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1)

^[S-132] Best Practices for Securing E-commerce

• Autor/Herausgeber: PCI Security Standards Council
• Datum: 31.01.2017; Aktualität einzelner Details prüfen
• Dokumenttyp: Branchenleitfaden
• Status: Grundlagen weiterhin relevant; gegen PCI DSS 4.0.1 abgleichen
• Relevanz: Risiken eingebetteter und umgeleiteter Bezahlseiten sowie Skriptmanipulation.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf](https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf)

Webstandards

^[S-133] HTML Living Standard

• Autor/Herausgeber: WHATWG
• Datum: Living Standard; geprüft 08.08.2026
• Dokumenttyp: Offene Webspezifikation
• Status: Living Standard
• Relevanz: Semantik, Formulare, Navigation, Script- und Dokumentverhalten.
• Refresh-Priorität: hoch
• Direkte URL: [https://html.spec.whatwg.org/](https://html.spec.whatwg.org/)

^[S-134] URL Living Standard

• Autor/Herausgeber: WHATWG
• Datum: Living Standard; geprüft 08.08.2026
• Dokumenttyp: Offene Webspezifikation
• Status: Living Standard
• Relevanz: Parsing und Serialisierung von URLs.
• Refresh-Priorität: hoch
• Direkte URL: [https://url.spec.whatwg.org/](https://url.spec.whatwg.org/)

^[S-135] Fetch Living Standard

• Autor/Herausgeber: WHATWG
• Datum: Living Standard; geprüft 08.08.2026
• Dokumenttyp: Offene Webspezifikation
• Status: Living Standard
• Relevanz: Netzwerkanfragen, CORS, Credentials und Request-/Response-Verarbeitung im Browser.
• Refresh-Priorität: hoch
• Direkte URL: [https://fetch.spec.whatwg.org/](https://fetch.spec.whatwg.org/)

^[S-136] CSS Snapshot 2025

• Autor/Herausgeber: W3C
• Datum: 2025; genauer Veröffentlichungsstand geprüft 08.08.2026
• Dokumenttyp: W3C Working Group Note / Snapshot
• Status: Aktueller Snapshot am Stichtag prüfen
• Relevanz: Überblick stabiler CSS-Spezifikationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/TR/css-2025/](https://www.w3.org/TR/css-2025/)

Transport und TLS

^[S-137] RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3

• Autor/Herausgeber: IETF
• Datum: 08.2018
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Aktuelles TLS-Protokoll für Transportverschlüsselung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8446.html](https://www.rfc-editor.org/rfc/rfc8446.html)

Webstandards

^[S-138] RFC 9113 — HTTP/2

• Autor/Herausgeber: IETF
• Datum: 06.2022
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: HTTP/2-Framing und Multiplexing.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9113.html](https://www.rfc-editor.org/rfc/rfc9113.html)

^[S-139] RFC 9114 — HTTP/3

• Autor/Herausgeber: IETF
• Datum: 06.2022
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: HTTP über QUIC.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9114.html](https://www.rfc-editor.org/rfc/rfc9114.html)

Transport und TLS

^[S-140] RFC 6797 — HTTP Strict Transport Security (HSTS)

• Autor/Herausgeber: IETF
• Datum: 11.2012
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Erzwingung von HTTPS durch Browser nach Policyempfang.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6797.html](https://www.rfc-editor.org/rfc/rfc6797.html)

^[S-141] RFC 8555 — Automatic Certificate Management Environment (ACME)

• Autor/Herausgeber: IETF
• Datum: 03.2019
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Automatisierte Ausstellung und Erneuerung von Zertifikaten.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8555.html](https://www.rfc-editor.org/rfc/rfc8555.html)

DNS und Domains

^[S-142] RFC 1034 — Domain Names: Concepts and Facilities

• Autor/Herausgeber: IETF
• Datum: 11.1987
• Dokumenttyp: Internet Standard / RFC
• Status: Historische Grundlage; weiterhin relevant
• Relevanz: Grundkonzept des Domain Name System.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc1034.html](https://www.rfc-editor.org/rfc/rfc1034.html)

^[S-143] RFC 1035 — Domain Names: Implementation and Specification

• Autor/Herausgeber: IETF
• Datum: 11.1987
• Dokumenttyp: Internet Standard / RFC
• Status: Historische Grundlage; weiterhin relevant
• Relevanz: DNS-Nachrichten, Resource Records und Implementierung.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc1035.html](https://www.rfc-editor.org/rfc/rfc1035.html)

^[S-144] RFC 4033 — DNS Security Introduction and Requirements

• Autor/Herausgeber: IETF
• Datum: 03.2005
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Grundlagen und Ziele von DNSSEC.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc4033.html](https://www.rfc-editor.org/rfc/rfc4033.html)

^[S-145] RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record

• Autor/Herausgeber: IETF
• Datum: 11.2019
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: DNS-Steuerung zulässiger Zertifizierungsstellen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8659.html](https://www.rfc-editor.org/rfc/rfc8659.html)

Webstandards: Cookies

^[S-146] RFC 6265 — HTTP State Management Mechanism

• Autor/Herausgeber: IETF
• Datum: 04.2011
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track; aktuelle Browserpraxis zusätzlich prüfen
• Relevanz: Grundmechanik von HTTP-Cookies.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6265.html](https://www.rfc-editor.org/rfc/rfc6265.html)

Browser-Sicherheit

^[S-147] Content Security Policy Level 3

• Autor/Herausgeber: W3C
• Datum: Working Draft / Living Specification; geprüft 08.08.2026
• Dokumenttyp: W3C-Spezifikation
• Status: Entwicklungsstand; Browserunterstützung separat prüfen
• Relevanz: Policy zur Begrenzung ausführbarer und ladbarer Webressourcen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/TR/CSP3/](https://www.w3.org/TR/CSP3/)

^[S-148] Subresource Integrity

• Autor/Herausgeber: W3C
• Datum: 23.06.2016
• Dokumenttyp: W3C Recommendation
• Status: Recommendation
• Relevanz: Integritätsprüfung extern geladener Ressourcen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.w3.org/TR/SRI/](https://www.w3.org/TR/SRI/)

^[S-149] Referrer Policy

• Autor/Herausgeber: W3C
• Datum: 26.01.2017; Living-Entwicklung geprüft 08.08.2026
• Dokumenttyp: W3C Recommendation
• Status: Recommendation
• Relevanz: Steuerung der Referrer-Information bei Navigation und Requests.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.w3.org/TR/referrer-policy/](https://www.w3.org/TR/referrer-policy/)

^[S-150] Permissions Policy

• Autor/Herausgeber: W3C
• Datum: Working Draft; geprüft 08.08.2026
• Dokumenttyp: W3C-Spezifikation
• Status: Entwicklungsstand
• Relevanz: Begrenzung bestimmter Browserfunktionen für Dokumente und Frames.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.w3.org/TR/permissions-policy-1/](https://www.w3.org/TR/permissions-policy-1/)

Identität und Authentisierung

^[S-151] Web Authentication: An API for accessing Public Key Credentials Level 3

• Autor/Herausgeber: W3C
• Datum: Entwicklungsstand geprüft 08.08.2026
• Dokumenttyp: W3C-Spezifikation
• Status: Candidate/Working Draft; Status regelmäßig prüfen
• Relevanz: WebAuthn und passwortlose beziehungsweise phishingresistente Authentisierung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.w3.org/TR/webauthn-3/](https://www.w3.org/TR/webauthn-3/)

SEO und Crawling

^[S-152] RFC 9309 — Robots Exclusion Protocol

• Autor/Herausgeber: IETF
• Datum: 09.2022
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Standardisiertes Verhalten von robots.txt.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9309.html](https://www.rfc-editor.org/rfc/rfc9309.html)

^[S-153] Sitemaps XML format

• Autor/Herausgeber: Sitemaps.org
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offenes Protokoll
• Status: Living Documentation
• Relevanz: Maschinenlesbare Auflistung und Metadaten von URLs.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.sitemaps.org/protocol.html](https://www.sitemaps.org/protocol.html)

SEO und strukturierte Daten

^[S-154] Schema.org vocabulary

• Autor/Herausgeber: Schema.org Community
• Datum: Living Vocabulary; geprüft 08.08.2026
• Dokumenttyp: Offenes Vokabular
• Status: Living Documentation
• Relevanz: Strukturierte Daten für Webinhalte.
• Refresh-Priorität: hoch
• Direkte URL: [https://schema.org/](https://schema.org/)

DNS und Domains

^[S-155] Domains registrieren — Grundlagen und Domaininhaberschaft

• Autor/Herausgeber: DENIC eG
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Registry-Dokumentation
• Status: Living Documentation
• Relevanz: Registrierung, Domaininhaber und Providerprozess für .de-Domains.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.denic.de/domains/de-domains/domainregistrierung](https://www.denic.de/domains/de-domains/domainregistrierung)

^[S-156] Providerwechsel und AuthInfo

• Autor/Herausgeber: DENIC eG
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Registry-Dokumentation
• Status: Living Documentation
• Relevanz: Transferprozess und AuthInfo für .de-Domains.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.denic.de/domains/de-domains/providerwechsel](https://www.denic.de/domains/de-domains/providerwechsel)

^[S-157] DENIC TRANSIT

• Autor/Herausgeber: DENIC eG
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Registry-Dokumentation
• Status: Living Documentation
• Relevanz: Folgen eines beendeten Providervertrags und Handlungsoptionen für Domaininhaber.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.denic.de/domains/de-domains/transit](https://www.denic.de/domains/de-domains/transit)

^[S-158] Registrant Rights and Responsibilities

• Autor/Herausgeber: ICANN
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle ICANN-Information
• Status: Living Documentation
• Relevanz: Rechte und Pflichten registrierter Domaininhaber bei gTLDs.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.icann.org/resources/pages/benefits-2013-09-16-en](https://www.icann.org/resources/pages/benefits-2013-09-16-en)

Transport und TLS

^[S-159] Why ninety-day lifetimes for certificates

• Autor/Herausgeber: Internet Security Research Group / Let’s Encrypt
• Datum: 09.11.2015
• Dokumenttyp: Offizieller Projektbeitrag
• Status: Grundsatzbeitrag; Automatisierung weiterhin erforderlich
• Relevanz: Kurze Zertifikatslaufzeiten und Notwendigkeit automatisierter Erneuerung.
• Refresh-Priorität: mittel
• Direkte URL: [https://letsencrypt.org/2015/11/09/why-90-days](https://letsencrypt.org/2015/11/09/why-90-days)

^[S-160] Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates

• Autor/Herausgeber: CA/Browser Forum
• Datum: Living Standard; geprüft 08.08.2026
• Dokumenttyp: Branchenstandard
• Status: Aktuelle Fassung am Stichtag prüfen
• Relevanz: Anforderungen an öffentlich vertrauenswürdige TLS-Zertifikate.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://cabforum.org/working-groups/server/baseline-requirements/requirements/](https://cabforum.org/working-groups/server/baseline-requirements/requirements/)

^[S-161] Server Side TLS — Recommended configurations

• Autor/Herausgeber: Mozilla
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle technische Empfehlung
• Status: Living Documentation
• Relevanz: Praxisprofile für TLS-Konfiguration.
• Refresh-Priorität: hoch
• Direkte URL: [https://wiki.mozilla.org/Security/Server_Side_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)

^[S-162] BSI TR-02102-2 — Kryptographische Verfahren: Verwendung von TLS

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik
• Datum: Aktuelle Fassung am Stichtag; genaues Ausgabedatum im Dokument prüfen
• Dokumenttyp: Technische Richtlinie
• Status: Aktueller BSI-Stand prüfen
• Relevanz: Deutsche Behördenempfehlungen zu TLS-Versionen und Cipher Suites.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf)

SEO und Crawling

^[S-163] Google Search Essentials

• Autor/Herausgeber: Google Search Central
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Suchmaschinen-Dokumentation
• Status: Living Documentation
• Relevanz: Technische Anforderungen, Spamrichtlinien und zentrale Best Practices.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.google.com/search/docs/essentials](https://developers.google.com/search/docs/essentials)

SEO und Inhalte

^[S-164] Spam policies for Google web search

• Autor/Herausgeber: Google Search Central
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Suchmaschinen-Dokumentation
• Status: Living Documentation
• Relevanz: Unerlaubte Manipulationsmuster einschließlich skalierter Inhaltsproduktion ohne Mehrwert.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.google.com/search/docs/essentials/spam-policies](https://developers.google.com/search/docs/essentials/spam-policies)

SEO und KI-Inhalte

^[S-165] Google Search’s guidance about AI-generated content

• Autor/Herausgeber: Google Search Central
• Datum: 08.02.2023; geprüft 08.08.2026
• Dokumenttyp: Offizielle Suchmaschinen-Dokumentation
• Status: Grundsatzbeitrag; aktuelle Spamrichtlinien mitprüfen
• Relevanz: Einordnung von KI-generierten Inhalten nach Qualität und Zweck statt Erzeugungswerkzeug allein.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/search/blog/2023/02/google-search-and-ai-content](https://developers.google.com/search/blog/2023/02/google-search-and-ai-content)

SEO und Crawling

^[S-166] Understand the JavaScript SEO basics

• Autor/Herausgeber: Google Search Central
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Suchmaschinen-Dokumentation
• Status: Living Documentation
• Relevanz: Crawling, Rendering und Indexierung JavaScript-basierter Seiten.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)

^[S-167] Introduction to robots.txt

• Autor/Herausgeber: Google Search Central
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Suchmaschinen-Dokumentation
• Status: Living Documentation
• Relevanz: Suchmaschinenspezifische robots.txt-Verarbeitung.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/search/docs/crawling-indexing/robots/intro](https://developers.google.com/search/docs/crawling-indexing/robots/intro)

^[S-168] Learn about sitemaps

• Autor/Herausgeber: Google Search Central
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Suchmaschinen-Dokumentation
• Status: Living Documentation
• Relevanz: Einsatz und Grenzen von Sitemaps.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview)

SEO und strukturierte Daten

^[S-169] General structured data guidelines

• Autor/Herausgeber: Google Search Central
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Suchmaschinen-Dokumentation
• Status: Living Documentation
• Relevanz: Qualitäts-, Relevanz- und Sichtbarkeitsregeln für strukturierte Daten.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/search/docs/appearance/structured-data/sd-policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)

Performance

^[S-170] Web Vitals

• Autor/Herausgeber: Google / web.dev
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle technische Dokumentation
• Status: Living Documentation
• Relevanz: LCP, INP und CLS als nutzerzentrierte Performancekennzahlen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://web.dev/articles/vitals](https://web.dev/articles/vitals)

^[S-171] Interaction to Next Paint (INP)

• Autor/Herausgeber: Google / web.dev
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle technische Dokumentation
• Status: Living Documentation
• Relevanz: Responsiveness-Metrik und Messmethoden.
• Refresh-Priorität: hoch
• Direkte URL: [https://web.dev/articles/inp](https://web.dev/articles/inp)

Qualität und Performance

^[S-172] Lighthouse overview

• Autor/Herausgeber: Google Chrome for Developers
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Tooldokumentation
• Status: Living Documentation
• Relevanz: Automatisierte Audits für Performance, Accessibility, Best Practices und SEO.
• Refresh-Priorität: hoch
• Direkte URL: [https://developer.chrome.com/docs/lighthouse/overview/](https://developer.chrome.com/docs/lighthouse/overview/)

SEO und Betrieb

^[S-173] About Search Console

• Autor/Herausgeber: Google Search Central
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Tooldokumentation
• Status: Living Documentation
• Relevanz: Monitoring von Crawling, Indexierung, Suchleistung und Problemen.
• Refresh-Priorität: hoch
• Direkte URL: [https://support.google.com/webmasters/answer/9128668](https://support.google.com/webmasters/answer/9128668)

Identität und Authentisierung

^[S-174] SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management

• Autor/Herausgeber: NIST
• Datum: 31.07.2025
• Dokumenttyp: Behördenstandard
• Status: Final; ersetzt SP 800-63B
• Relevanz: Aktueller Referenzrahmen für Authenticatoren, MFA, Passwort- und Phishingresistenz.
• Refresh-Priorität: hoch
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/63/b/4/final](https://csrc.nist.gov/pubs/sp/800/63/b/4/final)

Identität und APIs

^[S-175] RFC 6749 — The OAuth 2.0 Authorization Framework

• Autor/Herausgeber: IETF
• Datum: 10.2012
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Grundrahmen delegierter Autorisierung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6749.html](https://www.rfc-editor.org/rfc/rfc6749.html)

^[S-176] RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients

• Autor/Herausgeber: IETF
• Datum: 09.2015
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Schutz des Authorization Code Flow gegen Code-Abgriff.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7636.html](https://www.rfc-editor.org/rfc/rfc7636.html)

^[S-177] RFC 9700 — Best Current Practice for OAuth 2.0 Security

• Autor/Herausgeber: IETF
• Datum: 01.2025
• Dokumenttyp: Best Current Practice / RFC
• Status: BCP 240
• Relevanz: Aktuelle Sicherheitspraktiken und überholte OAuth-Muster.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9700.html](https://www.rfc-editor.org/rfc/rfc9700.html)

^[S-178] RFC 8725 — JSON Web Token Best Current Practices

• Autor/Herausgeber: IETF
• Datum: 02.2020
• Dokumenttyp: Best Current Practice / RFC
• Status: BCP 225
• Relevanz: Sichere Validierung und Nutzung von JWT.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8725.html](https://www.rfc-editor.org/rfc/rfc8725.html)

Websicherheit: Eingaben

^[S-179] Input Validation Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Serverseitige Syntax- und Semantikvalidierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)

Websicherheit: XSS

^[S-180] Cross Site Scripting Prevention Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Kontextsensitive Ausgabe-Kodierung und sichere Sinks.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

Websicherheit: Injection

^[S-181] SQL Injection Prevention Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Parametrisierte Abfragen und weitere SQL-Injection-Schutzmaßnahmen.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)

Websicherheit: Sessions

^[S-182] Cross-Site Request Forgery Prevention Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: CSRF-Token, SameSite und weitere Schutzmuster.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)

^[S-183] Session Management Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Sichere Session-IDs, Cookies, Lebenszyklen und Logout.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)

Websicherheit: Authentisierung

^[S-184] Authentication Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Sichere Anmeldung, Fehlerausgaben, MFA und Reauthentisierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)

^[S-185] Password Storage Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Passworthashing und Parameterwahl.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

Websicherheit: Uploads

^[S-186] File Upload Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Dateitypen, Speicherung, Prüfung und Zugriffsschutz bei Uploads.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)

Websicherheit: SSRF

^[S-187] Server-Side Request Forgery Prevention Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Kontrollen gegen serverseitige unautorisierte Netzwerkzugriffe.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)

Websicherheit: Browser

^[S-188] Testing Cross Origin Resource Sharing

• Autor/Herausgeber: OWASP WSTG
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Prüfung fehlerhafter CORS-Konfiguration.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing)

^[S-189] HTTP Headers Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Sicherheitsrelevante HTTP-Header und typische Werte.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)

^[S-190] Content Security Policy Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Praktische Einführung und Deployment von CSP.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)

Websicherheit: APIs

^[S-191] REST Security Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Authentisierung, Autorisierung, Eingaben, Statuscodes und Transport für REST APIs.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)

^[S-192] GraphQL Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Risiken von Introspection, Query-Tiefe, Autorisierung und Ressourcenverbrauch.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)

Transport und TLS

^[S-193] Transport Layer Security Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: TLS-Konfiguration und Zertifikatsbetrieb.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

Websicherheit: Integrationen

^[S-194] Validating webhook deliveries

• Autor/Herausgeber: GitHub
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Signaturprüfung eingehender Webhooks.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries](https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries)

Hosting und Cloud

^[S-195] Shared Responsibility Model

• Autor/Herausgeber: Amazon Web Services
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Cloud-Dokumentation
• Status: Living Documentation
• Relevanz: Abgrenzung von Cloud- und Kundenverantwortung.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/compliance/shared-responsibility-model/](https://aws.amazon.com/compliance/shared-responsibility-model/)

CMS und Wartung

^[S-196] Security — WordPress

• Autor/Herausgeber: WordPress.org
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Sicherheitsprozess und Releasegrundsätze des CMS-Projekts.
• Refresh-Priorität: hoch
• Direkte URL: [https://wordpress.org/about/security/](https://wordpress.org/about/security/)

^[S-197] Hardening WordPress

• Autor/Herausgeber: WordPress Developer Resources
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Betriebliche Härtung einer WordPress-Installation.
• Refresh-Priorität: hoch
• Direkte URL: [https://developer.wordpress.org/advanced-administration/security/hardening/](https://developer.wordpress.org/advanced-administration/security/hardening/)

^[S-198] Updating WordPress

• Autor/Herausgeber: WordPress.org
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Update- und Sicherungsanforderungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://wordpress.org/documentation/article/updating-wordpress/](https://wordpress.org/documentation/article/updating-wordpress/)

CMS und Erweiterungen

^[S-199] Detailed Plugin Guidelines

• Autor/Herausgeber: WordPress Developer Resources
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Anforderungen und Grenzen für Plugins im offiziellen Verzeichnis.
• Refresh-Priorität: hoch
• Direkte URL: [https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/)

Laufzeit und Abhängigkeiten

^[S-200] Supported Versions

• Autor/Herausgeber: PHP Project
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Aktiv unterstützte und nur noch sicherheitsunterstützte PHP-Versionen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.php.net/supported-versions.php](https://www.php.net/supported-versions.php)

^[S-201] Node.js releases

• Autor/Herausgeber: OpenJS Foundation / Node.js
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: LTS- und End-of-Life-Zyklen von Node.js.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://nodejs.org/en/about/previous-releases](https://nodejs.org/en/about/previous-releases)

^[S-202] About semantic versioning

• Autor/Herausgeber: npm Docs
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Praktische Abhängigkeitsbereiche in npm-Paketen.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.npmjs.com/about-semantic-versioning](https://docs.npmjs.com/about-semantic-versioning)

Backup und Wiederherstellung

^[S-203] Back Up Business Data

• Autor/Herausgeber: CISA
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Behördenempfehlung
• Status: Living Guidance
• Relevanz: Getrennte, getestete Datensicherungen als Resilienzmaßnahme.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.cisa.gov/secure-our-world/back-up-business-data](https://www.cisa.gov/secure-our-world/back-up-business-data)

E-Mail und Zustellung

^[S-204] RFC 7208 — Sender Policy Framework (SPF)

• Autor/Herausgeber: IETF
• Datum: 04.2014
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Domainbasierte Autorisierung sendender Mailserver.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7208.html](https://www.rfc-editor.org/rfc/rfc7208.html)

^[S-205] RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures

• Autor/Herausgeber: IETF
• Datum: 09.2011
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Kryptographische Signatur von E-Mail-Domänen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6376.html](https://www.rfc-editor.org/rfc/rfc6376.html)

^[S-206] RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)

• Autor/Herausgeber: IETF
• Datum: 03.2015
• Dokumenttyp: Informational RFC
• Status: Published specification
• Relevanz: Policy und Berichte auf Grundlage von SPF/DKIM-Alignment.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7489.html](https://www.rfc-editor.org/rfc/rfc7489.html)

^[S-207] RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)

• Autor/Herausgeber: IETF
• Datum: 09.2018
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Policy zur erzwingbaren TLS-Zustellung zwischen Mailservern.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8461.html](https://www.rfc-editor.org/rfc/rfc8461.html)

^[S-208] RFC 8460 — SMTP TLS Reporting

• Autor/Herausgeber: IETF
• Datum: 09.2018
• Dokumenttyp: Internet Standard / RFC
• Status: Standards Track
• Relevanz: Berichte über TLS-Zustellprobleme.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8460.html](https://www.rfc-editor.org/rfc/rfc8460.html)

E-Mail und Datenschutz

^[S-209] Orientierungshilfe Maßnahmen zum Schutz personenbezogener Daten bei der Übermittlung per E-Mail

• Autor/Herausgeber: Datenschutzkonferenz (DSK)
• Datum: 16.06.2021
• Dokumenttyp: Behördenorientierung
• Status: Veröffentlicht; Aktualität gegen Stand der Technik prüfen
• Relevanz: Risikobasierte Schutzmaßnahmen für E-Mail-Übermittlungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.datenschutzkonferenz-online.de/media/oh/20210616_orientierungshilfe_e_mail_verschluesselung.pdf](https://www.datenschutzkonferenz-online.de/media/oh/20210616_orientierungshilfe_e_mail_verschluesselung.pdf)

Formulare und Spam

^[S-210] Turnstile documentation

• Autor/Herausgeber: Cloudflare
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation; Anbieterquelle
• Relevanz: Bot-Abwehr ohne klassische Bildrätsel; Datenfluss und Anbieterbedingungen separat prüfen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.cloudflare.com/turnstile/](https://developers.cloudflare.com/turnstile/)

KI-gestützte Entwicklung

^[S-211] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

• Autor/Herausgeber: METR
• Datum: 10.07.2025
• Dokumenttyp: Originalstudie / randomisierte kontrollierte Untersuchung
• Status: Preprint / Forschungsbericht
• Relevanz: Messung von Produktivitätseffekten aktueller KI-Tools bei erfahrenen Entwicklern in bekannten Repositories.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2507.09089](https://arxiv.org/abs/2507.09089)

^[S-212] The Impact of AI on Developer Productivity: Evidence from GitHub Copilot

• Autor/Herausgeber: Peng et al. / GitHub Research
• Datum: 13.02.2023
• Dokumenttyp: Experiment / Preprint
• Status: Anbieternahe Forschung; Kontext beachten
• Relevanz: Kontrolliertes Experiment zu einer klar abgegrenzten Programmieraufgabe.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2302.06590](https://arxiv.org/abs/2302.06590)

^[S-213] Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions

• Autor/Herausgeber: Pearce et al.
• Datum: 19.08.2021
• Dokumenttyp: Originalstudie / arXiv
• Status: Peer-reviewter Konferenzbeitrag (IEEE S&P 2022)
• Relevanz: Sicherheitsanalyse von KI-generierten Codevorschlägen in ausgewählten Szenarien.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2108.09293](https://arxiv.org/abs/2108.09293)

^[S-214] 2025 Developer Survey — AI

• Autor/Herausgeber: Stack Overflow
• Datum: 2025
• Dokumenttyp: Branchenumfrage
• Status: Anbieter-/Community-Umfrage; Selbstbericht
• Relevanz: Nutzung, Vertrauen und wahrgenommene Grenzen von KI-Werkzeugen.
• Refresh-Priorität: hoch
• Direkte URL: [https://survey.stackoverflow.co/2025/ai](https://survey.stackoverflow.co/2025/ai)

Fälle und Lessons Learned

^[S-215] ICO fines British Airways £20m for data breach affecting more than 400,000 customers

• Autor/Herausgeber: UK Information Commissioner’s Office
• Datum: 16.10.2020
• Dokumenttyp: Behördenentscheidung / Pressemitteilung
• Status: Finale Geldbuße
• Relevanz: Web- und Sicherheitsmängel, die zu großflächigem Datenabfluss beitrugen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2020/10/ico-fines-british-airways-20m-for-data-breach-affecting-more-than-400000-customers/](https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2020/10/ico-fines-british-airways-20m-for-data-breach-affecting-more-than-400000-customers/)

^[S-216] ICO fines Ticketmaster UK Limited £1.25million for failing to protect customers’ payment details

• Autor/Herausgeber: UK Information Commissioner’s Office
• Datum: 13.11.2020
• Dokumenttyp: Behördenentscheidung / Pressemitteilung
• Status: Finale Geldbuße
• Relevanz: Drittanbieter-Chatbot-Skript und Zahlungskartendaten als Supply-Chain-Lehre.
• Refresh-Priorität: niedrig
• Direkte URL: [https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2020/11/ico-fines-ticketmaster-uk-limited-125million-for-failing-to-protect-customers-payment-details/](https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2020/11/ico-fines-ticketmaster-uk-limited-125million-for-failing-to-protect-customers-payment-details/)

^[S-217] Cookies: financial penalties against Google LLC and Google Ireland Limited and Amazon Europe Core

• Autor/Herausgeber: CNIL
• Datum: 10.12.2020
• Dokumenttyp: Behördenentscheidung / Mitteilung
• Status: Entscheidungen veröffentlicht
• Relevanz: Consent- und Informationsmängel bei Cookie-Technologien.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.cnil.fr/en/cookies-financial-penalties-60-million-euros-against-company-google-llc-and-40-million-euros](https://www.cnil.fr/en/cookies-financial-penalties-60-million-euros-against-company-google-llc-and-40-million-euros)

^[S-218] Cookies: CNIL fines Google a total of 150 million euros and Facebook 60 million euros for non-compliance

• Autor/Herausgeber: CNIL
• Datum: 06.01.2022
• Dokumenttyp: Behördenentscheidung / Mitteilung
• Status: Entscheidungen veröffentlicht
• Relevanz: Ungleichgewicht zwischen Annahme und Ablehnung nicht notwendiger Cookies.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.cnil.fr/en/cookies-cnil-fines-google-total-150-million-euros-and-facebook-60-million-euros-non-compliance](https://www.cnil.fr/en/cookies-cnil-fines-google-total-150-million-euros-and-facebook-60-million-euros-non-compliance)

^[S-219] Drupal core — Highly critical — Remote Code Execution — SA-CORE-2018-002

• Autor/Herausgeber: Drupal Security Team
• Datum: 28.03.2018
• Dokumenttyp: Offizielles Sicherheitsadvisory
• Status: Behobene historische Schwachstelle
• Relevanz: Kritische CMS-Schwachstelle und Bedeutung zeitnaher Updates.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.drupal.org/sa-core-2018-002](https://www.drupal.org/sa-core-2018-002)

^[S-220] 2020.02.29 CAA Rechecking Bug

• Autor/Herausgeber: Let’s Encrypt
• Datum: 29.02.2020; aktualisiert 04.03.2020
• Dokumenttyp: Offizieller Incidentbericht
• Status: Behobener Vorfall
• Relevanz: Zertifikatswiderruf und Notwendigkeit automatisierter Erneuerungs- und Reaktionsprozesse.
• Refresh-Priorität: niedrig
• Direkte URL: [https://letsencrypt.org/2020/02/29/2020.02.29-caa-rechecking-bug/](https://letsencrypt.org/2020/02/29/2020.02.29-caa-rechecking-bug/)

^[S-221] CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability

• Autor/Herausgeber: CISA / FBI
• Datum: 07.06.2023; fortlaufend aktualisiert
• Dokumenttyp: Gemeinsames Cybersecurity Advisory
• Status: Behördenadvisory
• Relevanz: Massenhafte Ausnutzung einer Webanwendungsschwachstelle und Lieferkettenwirkung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a)

Schnell veraltend — Refresh-Plan

REFRESH-HINWEIS: Webrecht, Barrierefreiheitsumsetzung, AI-Act-Leitlinien, Sicherheitskataloge, Browser-, CMS-, Runtime-, Suchmaschinen- und Zahlungsdokumentation können sich kurzfristig ändern. Vor Buchsatz und Neuauflage sind die folgenden Quellen erneut zu prüfen. ^{[S-099; S-075; S-066; S-198; S-163; S-131]}

Empfohlene Prüffrequenz

Qualitätssicherung und Dossiergrenzen

Strukturprüfungen

Inhaltliche Grenzen

• Das Dossier ist keine Rechtsberatung, kein Penetrationstest, kein BFSG-Konformitätsgutachten und keine Datenschutz-Folgenabschätzung.
• Gesetze und Standards müssen auf Anbieter, Zielgruppe, Dienstleistung, Daten, Funktionen und Vertrag des konkreten Projekts angewendet werden.
• Normen sind teilweise kostenpflichtig; öffentlich zugängliche Metadaten belegen Ausgabe und Gegenstand, nicht den gesamten Normtext.
• Offizielle Produkt- und Projektquellen können nach dem Stichtag verändert werden; der Refresh-Plan ist verbindlicher Bestandteil der Wissensbasis.
• Automatisierte Prüfwerkzeuge erfassen nur einen Teil von Security, Accessibility, Datenschutz und Nutzerqualität.
• Post-Mortems und Behördenentscheidungen liefern reale Lehren, aber keine universellen Eintrittswahrscheinlichkeiten für andere Systeme.
• Konkrete Vertragsklauseln, Haftungsverteilung, Steuerfragen und branchenspezifische Sonderpflichten sind außerhalb des Dossiers.

Schlussbefund: Eine Website für Kunden zu bauen bedeutet nicht, möglichst schnell sichtbare Seiten zu erzeugen. Es bedeutet, einen begrenzten, nachweisbaren und übergabefähigen digitalen Dienst zu schaffen, dessen Inhalt, Datenfluss, Sicherheit, Zugänglichkeit und Betrieb verstanden werden. KI kann diesen Prozess beschleunigen. Sie kann ihn nicht verantworten. ^{[S-002; S-001; S-010; S-004; S-074]}