Eine externe Datei wird gebraucht, aber der Browser soll sie nicht direkt beim fremden Anbieter abholen. „Dann setzen wir einen Proxy davor“, sagt die Entwicklung. Das kann eine sinnvolle Lösung sein. Es ist nur noch keine vollständige Antwort auf die Frage, welche Informationen beim Anbieter ankommen. Ein Zwischenstopp ändert den Weg. Was mitreist, entscheidet die Umsetzung.

Ein serverseitiger Proxy kann Ressourcen für die eigene Website abrufen und an Besucher weiterreichen. Richtig aufgebaut lässt sich so ein direkter Kontakt zwischen Besucherbrowser und Ressourcenanbieter vermeiden. Damit daraus ein datensparsamer Ablauf wird, müssen jedoch auch Anfrageinhalte, Weiterleitungen und nachgeladene Ressourcen betrachtet werden. Hier lohnt sich eine genauere Rückfrage.

Der Unterschied beginnt beim Verbindungsweg

Bei einer direkten Einbindung fragt der Browser die Ressource beim externen Ziel an. Bei der vorgeschalteten Lösung fragt er zunächst Ihre eigene Auslieferung an; Ihr Server holt die benötigte Datei. Der externe Anbieter sieht dann zunächst die Verbindung Ihres Servers. Die MDN-Erklärung zu Proxy-Servern beschreibt diesen Vermittlungsmechanismus und mögliche Weitergaben ursprünglicher Verbindungsinformationen.

Für das Gespräch im Team genügt eine einfache Skizze: Besucher, eigener Server, externer Anbieter. Schreiben Sie an jede Verbindung, welche Daten benötigt werden. Bei einer statischen Datei kann die Antwort sehr kurz sein. Bei einer personalisierten Anfrage, einer Suche oder einem eingebetteten Konto wird sie umfangreicher. Das Wort Proxy allein unterscheidet diese Fälle nicht.

Beispiel: OpenStreetMap-Karte über den eigenen Proxy

Auf Ihrer Kontaktseite zeigt eine Karte den Weg zum Büro. Solche Karten bestehen häufig aus kleinen Bildkacheln, den sogenannten Tiles. Statt diese direkt beim Kartenanbieter anzufragen, lädt der Besucherbrowser sie über Ihren eigenen Server. Der Tile-Proxy holt die benötigten Kacheln bei einem Anbieter auf Basis von OpenStreetMap-Daten ab und liefert sie an den Browser aus. Der Anbieter sieht dabei die IP-Adresse Ihres Proxyservers statt der IP-Adresse des Besuchers – sofern diese nicht über zusätzliche Header oder andere Angaben weitergereicht wird.

Hier passt auch ein Cache: Die bereits abgerufenen Kacheln des angezeigten Kartenausschnitts bleiben entsprechend den zulässigen Speicherfristen auf Ihrem Server. Ruft der nächste Besucher denselben Ausschnitt auf, kommen gültig zwischengespeicherte Kacheln direkt aus diesem Vorrat. Dafür ist kein erneuter Abruf beim Kartenanbieter nötig. Das reduziert externe Anfragen und kann die Karte schneller laden lassen. Erst für fehlende oder zu aktualisierende Kacheln muss Ihr Server wieder beim Anbieter anfragen.

Für diesen Datenschutzvorteil dürfen weder Besucher-IP-Adressen noch Cookies oder persönliche Kennungen zum Tile-Anbieter mitreisen. Auch Kartenskripte, Schriftdateien und eine eventuell angebotene Adresssuche müssen in das Konzept passen. Der Anbieter erhält bei einem nötigen Abruf weiterhin die angefragten Kachelkoordinaten und erforderliche Angaben zu Ihrer Anwendung; vollständig informationsfrei ist die Verbindung also nicht.

Eine reine Standortkarte kann auf dieser Grundlage auch ohne zusätzliche Einwilligung auskommen, wenn keine einwilligungspflichtigen Vorgänge wie Tracking hinzukommen und die verbleibende Datenverarbeitung auf einer passenden Rechtsgrundlage erfolgt. Der Gewinn liegt in der datensparsamen Umsetzung, nicht allein im Wort „Proxy“. Die Datenschutzbehörde erläutert die Abgrenzung bei Cookies und Endgerätezugriffen; für die Karte ist der konkrete Gesamtaufbau entscheidend.

Wählen Sie dafür einen OSM-basierten Tile-Anbieter, dessen Bedingungen Proxybetrieb und Caching erlauben. Freie Kartendaten bedeuten nicht unbegrenzt nutzbare Kachelserver. Die OSMF empfiehlt einen eigenen Caching-Proxy vor ihren öffentlichen Standardservern grundsätzlich nicht. Ihre Tile-Nutzungsregeln (englisch) verlangen unter anderem eine erkennbare Anwendung, einen korrekten Referer, das Beachten der Cache-Vorgaben und sichtbare Quellenangaben. Ganze Regionen vorsorglich herunterzuladen ist dort nicht erlaubt.

Die ursprüngliche IP-Adresse darf nicht durch die Hintertür mitfahren

Ein Proxy kann Informationen aus der ursprünglichen Anfrage weitergeben. Der Header X-Forwarded-For dient beispielsweise dazu, ursprüngliche Client-IP-Adressen zu übermitteln. Wenn das Ziel Ihrer Lösung ist, gerade diese Information nicht an den Ressourcenanbieter zu senden, muss die Konfiguration dazu passen. Die bloße Tatsache, dass ein eigener Server dazwischensteht, genügt nicht als Nachweis.

Fragen Sie außerdem nach Cookies, Kennungen, Referrer-Angaben und Parametern in der Adresse. Werden sie tatsächlich benötigt, entfernt oder ungeprüft weitergereicht? Eine E-Mail-Adresse in einem Suchparameter bleibt eine E-Mail-Adresse, auch wenn der Browser eine eigene Domain aufruft. Lassen Sie sich nicht nur die Servernamen, sondern die tatsächlich weitergegebenen Daten erklären. Daraus lässt sich eine konkrete technische Anforderung formulieren.

Bei einer Datei hört die Einbindung manchmal nicht auf

Eine Schriftdatei ist vergleichsweise überschaubar. Ein Stylesheet kann weitere Schrift- oder Bildadressen enthalten. Ein Skript kann nach dem Laden zusätzliche Verbindungen aufbauen. Eine eingebettete Anwendung kann andere Dienste kontaktieren, sobald Besucher mit ihr interagieren. Wird nur die erste Datei über den Proxy geliefert, sind diese Folgeaufrufe nicht automatisch ebenfalls erfasst.

Prüfen Sie deshalb das fertige Ergebnis im Browser und die nachgelagerten Abläufe auf dem Server. Ein Beispielszenario: Das Startskript eines Widgets kommt über die eigene Domain. Beim Öffnen des Widgets verbindet sich der Browser trotzdem direkt mit dem ursprünglichen Anbieter. Die erste Zeile in der Netzwerkansicht sieht beruhigend aus; der tatsächliche Ablauf ist weiterhin gemischt. Eine reine Namensänderung löst diesen Unterschied nicht.

Wer wartet die Zwischenstation?

Mit dem Proxy übernehmen Sie eine zusätzliche technische Aufgabe. Klären Sie, wer zulässige Zieladressen verwaltet, Fehler beobachtet und Änderungen beim Anbieter nachvollzieht. Eine unkontrollierte Durchreiche für beliebige Zieladressen ist keine geeignete Grundlage. Die Lösung sollte auf die tatsächlich benötigten Ressourcen begrenzt sein und einen benannten technischen Verantwortlichen haben.

Besprechen Sie außerdem, was bei einer nicht erreichbaren Quelle passiert. Gibt es einen bewusst eingerichteten Zwischenspeicher? Wie aktuell muss die Datei sein? Welche Fehlermeldung sehen Besucher? Ein stiller Rückfall auf den direkten Fremdabruf könnte das ursprüngliche Datenschutzkonzept unterlaufen. Deshalb gehört auch das Verhalten bei Fehlern in die Abnahme. Die angenehmste Lösung im Normalbetrieb kann sonst gerade im Störungsfall anders arbeiten als vorgesehen.

Eine technische Maßnahme ersetzt nicht die übrigen Fragen

Ein Proxy kann unnötige Datenweitergaben reduzieren. Daraus folgt nicht automatisch, dass jede darüber vermittelte Verarbeitung zulässig oder einwilligungsfrei ist. Entscheidend bleiben unter anderem Zweck, Datenarten, Beteiligte und konkrete Ausgestaltung. Auch die eigenen Serverprotokolle gehören in die Betrachtung: Welche Angaben werden dort gespeichert, wer hat Zugriff und wie lange bleiben sie erhalten?

Prüfen Sie ebenso die Nutzungsbedingungen der Ressource. Nicht jeder Anbieter erlaubt beliebiges Zwischenspeichern oder eine veränderte Auslieferung. Für Ihre Projektentscheidung sind deshalb technische Umsetzung, Vertragsbedingungen und datenschutzrechtliche Einordnung getrennte Punkte. Das macht die Lösung nicht schlechter. Es verhindert lediglich, dass aus einer sinnvollen Maßnahme ein pauschales Versprechen „Es werden keine Informationen weitergegeben“ wird.

Fünf Fragen für eine verständliche Abnahme

Lassen Sie sich beantworten: Welche Ressourcen laufen über die Zwischenstation? Welche Besucherdaten erreichen den Anbieter? Welche Folgeaufrufe bleiben direkt? Was passiert bei einem Ausfall? Und wer kontrolliert das nach Änderungen? Diese Fragen sind auch ohne tiefes Serverwissen verständlich. Die Antworten sollten konkret genug sein, dass eine andere betreuende Person die Lösung später übernehmen kann.

Ein browserbasierter Scan kann zeigen, welche direkten Ziele nach außen sichtbar sind. Die vollständige serverseitige Weitergabe kann er daraus nicht ableiten. Ergänzen Sie den Scan deshalb um eine Konfigurationsprüfung durch die Entwicklung. Im Beitrag zu externen Ressourcen finden Sie weitere Einbindungsvarianten; der Consent-Test hilft beim Vergleich verschiedener Besucherentscheidungen. So wird aus „Wir haben einen Proxy“ eine nachvollziehbare Beschreibung des tatsächlichen Ablaufs.