Privacy by Default auf HTTP-Ebene: Header, die deine Tracking-Oberfläche verkleinern
Zwei Response-Header — Permissions-Policy und Referrer-Policy — bestimmen, wie viel deine Seiten an Ad-Tech und Dritte preisgeben. Einmal gesetzt, schließt sich die Überwachungsfläche standardmäßig.
Die meiste Privacy-Arbeit passiert in JavaScript — Consent-Logik, Tag-Gating, Rotation von Identifiern. Aber der Browser liefert dir zwei HTTP-Response-Header, die die Überwachungsfläche schließen, bevor ein einziges Skript läuft, und die meisten Seiten setzen keinen davon. Permissions-Policy und Referrer-Policy sind Privacy by Design in seiner buchstäblichsten Form: Konfiguration, kein Code.
Sie sind heute wichtiger als noch vor einem Jahr. Mit Googles Abschaltung der meisten Privacy-Sandbox-APIs im Oktober 2025 sind die übrig gebliebenen Ad-Tech-Direktiven, die diese APIs eingeführt haben, weiterhin in Chrome verdrahtet — und eine Seite kann sie jetzt aktiv abschalten, statt darauf zu warten, dass sie entfernt werden.
Permissions-Policy: Verweigere die Features, die du nie nutzt
Permissions-Policy steuert, welche Browser-Features ein Dokument und seine eingebetteten Frames verwenden dürfen. Es ist derselbe Mechanismus, der camera, geolocation und microphone regelt — aber er regelt auch die tracking-nahen APIs, nach denen Ad-Tech greift.
Die Standard-Allowlist ist für die meisten davon freizügig. browsing-topics, die Direktive, die die Topics API steuert, hat den Standardwert * — jeder Origin auf der Seite, einschließlich Drittanbieter-Frames, darf sie aufrufen, sofern du nichts anderes festlegst. Sie zu deaktivieren ist eine Zeile:
Permissions-Policy: browsing-topics=()
Eine leere Allowlist () verweigert das Feature allen, einschließlich deines eigenen Origins. Den gesamten Cluster aus Ad-Interest- und Measurement-APIs kannst du in einem einzigen Header sperren:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()
Jedes Skript — first-party oder eingebettet — das document.browsingTopics() aufruft oder einen Sec-Browsing-Topics-Request-Header sendet, scheitert nun mit einem NotAllowedError. Du verlässt dich nicht darauf, dass sich Dritte korrekt verhalten; du entfernst die Fähigkeit auf Plattform-Ebene.
Diese Direktiven sind zusammen mit der Privacy Sandbox als deprecated markiert, sodass einige in kommenden Releases aus Chrome verschwinden werden. Sie auf () zu setzen ist harmlos, sobald sie weg sind, und schützt bis dahin.
Referrer-Policy: Hör auf, deine URLs preiszugeben
Jede Navigation und jeder Subresource-Request kann einen Referer-Header tragen, der die Seite nennt, von der der Nutzer kam. Vollständige URLs geben Query-Strings, in den Pfad codierte Identifier, Suchbegriffe und interne Seitenstruktur an jeden Dritten weiter, den du lädst — Analytics-Anbieter, Fonts, CDNs, Ad-Pixel.
Moderne Browser verwenden standardmäßig strict-origin-when-cross-origin, was bereits eine vernünftige Untergrenze ist:
Referrer-Policy: strict-origin-when-cross-origin
Unter dieser Policy sendet der Browser die vollständige URL nur bei same-origin-Requests, sendet bei sicheren cross-origin-Requests nur den Origin und sendet nichts, wenn von HTTPS auf HTTP herabgestuft wird. So erreicht https://app.example/orders/4815?token=abc einen Dritten als https://app.example/ — Origin, kein Pfad, kein Query.
Dieser Standard wurde im November 2020 zum Spec-Standard, aber du solltest den Header trotzdem explizit setzen. Ein falsch konfigurierter Upstream, ein alter Framework-Standard oder ein <meta>-Referrer-Tag kann ihn überschreiben, und ein expliziter Header ist auditierbar. Wenn du nichts Sensibles in URLs einbettest und strikt sein willst, lässt strict-origin den Pfad auch bei same-origin-Requests fallen.
Warum das zu cookie-freier Analyse passt
Diese Header und ein Privacy-first-Tracker lösen dasselbe Problem aus zwei Richtungen. Der Tracker steuert, was deine Analyse erhebt; die Header steuern, was alle anderen auf der Seite erreichen können.
Ein cookie-freier Tracker, der Identität aus einem Einweg-Tageshash ableitet — SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) — braucht für seine Aufgabe nie die vollständige Referrer-URL oder die Topics API. Er liest document.referrer nur, um eine Besuchsquelle zuzuordnen, und dafür reicht der Origin. Das Verschärfen der Referrer-Policy kostet deine Analyse also nichts, während es für jeden anderen Request auf der Seite ein Leck schließt.
Dieselbe Ausrichtung gilt für die Performance. Header kosten null Bytes JavaScript und null Main-Thread-Zeit; sie werden vom Browser vor dem Parsing ausgewertet. Du erhältst eine messbare Privacy-Verbesserung ohne Auswirkung auf Largest Contentful Paint oder Interaction to Next Paint — der umgekehrte Trade-off gegenüber einer Consent-Management-Plattform, die Skriptgewicht hinzufügt, um Berechtigungen zu verwalten, die ein Header von vornherein hätte verweigern können.
Liefere sie am Edge aus
Setze beide Header an deinem Edge- oder Origin-Server, damit jede Response sie trägt, einschließlich statischer Assets und HTML:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin
Auf Cloudflare fügst du sie in einer Transform Rule oder einem Worker hinzu; in Next.js in der headers()-Konfiguration; in jedem Reverse-Proxy in einer einzigen add_header-Zeile. Es gibt kein Rollout-Risiko: Du verweigerst Fähigkeiten, die du nicht nutzt, und beschneidest Daten, die du nie senden wolltest.
Privacy by Design wird meist als Architekturentscheidung dargestellt. Auf HTTP-Ebene sind es zwei Zeilen Konfiguration, und sie stehen standardmäßig offen, bis du sie schließt.
Comments
Loading comments…