Was wir tun.

Eine strukturierte interne Prüfung gegen eine etablierte Checkliste, jedes Quartal, plus unmittelbar nach jeder nicht-trivialen Abhängigkeitsaktualisierung oder Änderung an Auth-Flächen. Die Checkliste folgt dem Rahmen OWASP ASVS Level 2 + OWASP API Security Top 10 — wir beanspruchen keine Zertifizierung, verwenden die Fragen des Frameworks aber wörtlich, wo es nützlich ist. Jeder Durchgang erzeugt einen datierten Bericht, der ins Repository eingecheckt wird, mit Dateipfaden und Tests belegt; Befunde werden entweder in einem referenzierten Commit behoben oder mit Begründung als Restrisiko akzeptiert.

  • Masterscheckliste — acht Bereiche: Authentifizierung und Sitzung, öffentlicher Viewer + JSON-LD-Endpunkt, Dashboard-Schreibpfade, Speicher, eigene Domains, Abhängigkeiten, Geheimnisse, Logging und Monitoring.
  • Quartalsweise Prüfung — jede Zeile in der Datei mit Pfaden und Testdateien belegt; Pass / Teilweise / Fehler pro Zeile. Befunde werden entweder in einem referenzierten Commit behoben oder explizit als Restrisiko mit Begründung akzeptiert.
  • Abhängigkeits-Hygiene — pip-audit bei jedem Prüfdurchgang. Gepinntes requirements.txt ohne Versionsbereiche; Aktualisierungen sind bewusst und getestet.

Die tragenden Kontrollen.

Konkrete, überprüfbare Aussagen — jede ist eine Eigenschaft von Code oder Konfiguration, die ein Prüfer nachvollziehen kann.

  • Verschlüsselt im Transit. TLS auf jeder öffentlichen Fläche (qrregistry.io, qrregistry.eu, eigene Domain-Viewer) über Caddy mit On-Demand-Zertifikatsausstellung. Das Sitzungs-Cookie ist HttpOnly + Secure + SameSite=Lax.
  • Verschlüsselt im Speicher. PostgreSQL + MinIO auf EU-Hardware mit Festplattenverschlüsselung.
  • Keine Passwörter. Nur Magic-Link. Das Roh-Token hat ~256 Bit CSPRNG-Entropie, läuft in 15 Minuten ab und wird beim ersten Gebrauch konsumiert; die Datenbank speichert nur einen SHA-256-Hash, sodass ein Datenbank-Lesezugriff allein niemanden anmelden kann.
  • Differenzierte Audience-Authentifizierung. Prüfer- / Verwerter- / Reparatur- / Notified-Body-Berechtigungen sind kurzlebige JWTs, die von einer zentralen Admin-Oberfläche aus widerrufen werden können; ein Widerruf greift bei der nächsten Anfrage, nicht erst zum JWT-Ablauf.
  • Schreibpfade mit Eigentumsprüfung. Jeder Schreibvorgang auf Pässen, Bescheinigungen, Domains und Assets ist serverseitig durch row.user_id == user.id abgesichert. Andere Datensätze geben 404 statt 403 zurück — wir leaken keine Existenzhinweise.
  • Restricted-Tier-Filter. Eine einzige Funktion (strip_to_visible) regelt jede Pass-Fläche — HTML-Viewer, JSON-LD-Endpunkt, Audit-Feed, PDF. Kein Feld kann durch einen Zweig leaken, das ein anderer ausblendet.
  • Append-only-Audit-Kette. Jeder Speichervorgang schreibt eine passport_revisions-Zeile mit hash_before / hash_after / strukturiertem Diff. DELETE /dashboard/passports/{id} gibt unbedingt 403 zurück — Artikel 10(4) lebenslange Aufbewahrung.
  • Allowlist für eigene Domains. Caddys On-Demand-TLS-Frage-Endpunkt ist auf Loopback gebunden und konsultiert die Tabelle verifizierter Domains; nur verifizierte und bereitgestellte Hostnamen erhalten ein Zertifikat. Single-Claim-Invariante — ein Hostname kann nur einem Besitzer gehören.
  • Secrets-Disziplin. Keine Secrets im Quellcode. .env ist das einzige Inventar; pro-Dienst-Variablen (Datenbank, Stripe, Resend, MinIO) sind unabhängig.
  • Datenschutzkonforme Analytics. Scan-Ereignisse erfassen einen ISO-Ländercode (aus dem Header, nie eine rohe IP) und eine grobe Geräteklasse — niemals ein Tracking-Cookie, niemals eine Berechtigungsidentität. Dokumentiert und unter /privacy sichtbar.

Was wir ausdrücklich nicht tun.

Wir bezahlen keinen Drittanbieter-Penetrationstest, bis das Beschaffungstor eines Kunden den Aufwand rechtfertigt. ESPR Artikel 11(h) definiert keinen Zertifizierungspfad und schreibt keine Drittanbieter-Tests vor; eine Beauftragung über 15-30k € kauft Glaubwürdigkeit, aber kein regulatorisches <code>✅</code>, und die datierte interne Prüfung dokumentiert dieselben Belege zu geringeren Kosten, solange das Unternehmen klein ist.

Wir beanspruchen keine SOC-2- oder ISO-27001-Zertifizierung. Die Haltung unseres Infrastrukturanbieters steht hinter dem Footer-Hinweis <em>„ISO 27001 aligned“</em>; die Zertifizierung gehört ihm, nicht Contenza K/S.

Wir tun nicht so, als wäre eine saubere Prüfung das Fehlen von Befunden. Die Prüfung vom 30.04.2026 weist fünf 🟡 teilweise-Zeilen aus — vier sind Abhängigkeits-CVEs mit verfügbaren Fix-Versionen, die als Folge-Bump verfolgt werden, und eine ist ein verschobenes Anwendungs-Rate-Limit. Ehrlich ist nützlicher als aspirierend.

Was Sie nachlesen können.

  • Die Masterscheckliste liegt unter docs/security-review-checklist.md im Quellrepository — jede Zeile ist eine Frage, die die nächste Prüfung mit Belegen beantworten muss.
  • Jede datierte Prüfung liegt unter docs/security-review-{YYYY-MM-DD}.md — Dateipfade, Testdateien und Befunde, in der Datei. Der Git-Verlauf zeigt, was sich zwischen den Durchgängen geändert hat.
  • Jede öffentliche Aussage auf dieser Seite verweist auf eine Zeile der jüngsten Prüfung.

Eine Schwachstelle melden.

Bitte schreiben Sie dem Team eine E-Mail mit Details. Wir behandeln Sicherheitsmeldungen vorrangig und antworten innerhalb eines Geschäftstages. Es gibt noch kein formelles Bug-Bounty-Programm — in unserer Größenordnung ist die Anerkennung ein herzliches Dankeschön und ein Eintrag im Changelog.

Fragen zu dieser Richtlinie? Bitte das Kontaktformular nutzen — oder erreichen Sie das Team über die Angaben auf der Kontaktseite.