Zurück zum Blog
Technologie

Bild auf fremder Seite kaputt? Der Fehlerbaum für 403 und Hotlink-Schutz (2026)

Veröffentlicht am11 min read
Teilen

Du klebst einen Bild-Link in deinen Blog, die lokale Vorschau sieht bestens aus. Veröffentlicht, und die anderen sehen einen kaputten Bildrahmen. Oder schlimmer — die ganze Bildposition ist eine leere Fläche, gar nichts.

In diese Grube bin ich mehr als einmal getappt. Einmal ging es live richtig schief, als ich für den Blog eines Freundes Bilder umzog: lokal alles grün, nach dem Livegang war ein Drittel der Startseiten-Thumbnails kaputt, und ich dachte erst, der Cache sei nicht geleert. Drei Tage debuggen, bis ich merkte, dass es gar nicht mein Fehler war — die Quellseite der Bilder hatte Hotlink-Schutz aktiv, und jede Anfrage, die nicht von ihrer eigenen Domain kam, wurde blockiert.

Architektonisch betrachtet werden bei „Bild zeigt auf fremder Seite nichts an" drei völlig verschiedene Fehler in einen Topf geworfen. Um richtig zu reparieren, trennst du zuerst, welcher davon dich getroffen hat.

Zuerst trennen: 403, kaputtes Bild und leere 200-Seite sind drei Dinge

Viele nennen alles pauschal „kaputtes Bild" und probieren wild herum. Ehrlich gesagt liegen die Wurzeln dieser drei Symptome weit auseinander, und die Fehlersuche läuft jeweils anders.

Symptom HTTP-Status Wahrscheinlichste Ursache Fehlersuche
kaputter Bildrahmen (Symbol zerrissen) 403 / 404 Hotlink-Schutz blockt, oder Link ist falsch Referer und URL-Korrektheit prüfen
kaputter Bildrahmen (Symbol zerrissen) 200, aber kein Bild du bekommst eine HTML-Fehlerseite statt Bilddatei Content-Type prüfen
leere Fläche (kein zerrissenes Symbol) 200 CSS überdeckt, oder CSP blockt Laden DevTools-Konsole und CSP prüfen
Symbol dreht sich, dann weg Timeout / CORS Cross-Origin-Policy oder Server-Timeout Request-Details im Network-Tab prüfen

Erst den Status, dann den Content-Type, zuletzt das Bild. Machst du diese Reihenfolge rückwärts, drehst du dich im Kreis.

Grundprinzip: Wie Referer und Hotlink-Schutz funktionieren

Um zu verstehen, warum fremde Bilder blockiert werden, musst du wissen, was der Browser beim Laden heimlich tut.

Wenn Seite A per <img src="https://B.com/photo.jpg"> das Bild von Seite B lädt, hängt der Browser der Anfrage einen Referer-Header an (ja, das Wort ist historisch falsch geschrieben, ein r fehlt, und dabei blieb es bis heute). Dieser Header sagt B: „Dieses Bild wird von einer Seite auf A angefragt."

Das Grundprinzip: Der Server oder das CDN von B nimmt die Domain aus dem Referer und gleicht sie gegen eine Whitelist ab. Die Logik ungefähr so —

1. Referer ist leer (Bild direkt geöffnet, Bookmark) → je nach Einstellung durchlassen oder blocken
2. Referer-Domain steht auf der Whitelist → durchlassen
3. Referer-Domain steht nicht drauf → 403 Forbidden zurück

Das ist Hotlink-Schutz. Sein Zweck ist simpel: Niemand soll fremde Bandbreite abgreifen. Bettest du auf deiner Seite ein Bild von B ein, wird jeder Aufruf deiner Seite Bs Traffic-Rechnung belastet, und B ist zu Recht verärgert.

Ein Detail, das viele nicht kennen: Die Standard-Referrer-Policy moderner Browser ist strict-origin-when-cross-origin. Bei Cross-Origin-Anfragen sendet sie nur die „Herkunftsdomain" (etwa https://a.com/), nicht den vollen Pfad. Der Hotlink-Schutz bekommt also deinen Domainnamen, genug zum Abgleich mit der Whitelist und genug, um dich zu blocken. Genau deshalb kriegt Hotlink-Schutz Hotlinks in den Griff.

Warum dein Bild auf fremder Seite kaputt wird: ein Fehlerbaum

Das Prinzip aufgeklappt lässt sich die Ursache auf einen Baum eindampfen. Geh ihn einfach von oben durch.

Zweig eins: Ist der Status 403?

Wenn ja, ist es zu 90% Hotlink-Schutz. B sieht, dass dein Referer nicht auf seiner Whitelist steht, und lehnt direkt ab. Bs Einstellung kannst du nicht ändern, die einzige Lösung ist, sein Bild nicht mehr zu hotlinken (dazu unten die richtige Lösung).

Zweig zwei: Status ist 200, aber Bild kaputt?

Sieh dir den Rohinhalt dieses „Bilds" an. Sehr wahrscheinlich bekommst du eine HTML-Seite — manche Sites geben kein 403, sondern eine „Bitte nicht hotlinken"-Hinweisseite mit Status 200 zurück. Der Browser parst HTML als Bild und zeigt dir natürlich einen Bruch. Der Content-Type verrät es: Ein normales Bild ist image/jpeg, image/png, die Fehlerseite ist text/html.

Zweig drei: Hast du den „Seitenlink" statt „Bild-Direktlink" geklebt?

Die häufigste Anfängerfalle. https://imgur.com/aBcDeFg ist eine Seite, https://i.imgur.com/aBcDeFg.jpg erst die Bilddatei selbst. Lädst du Ersteres per <img src>, bekommst du eine ganze HTML-Seite, kein Bild. Ein i. und eine Dateiendung Unterschied, komplett anderes Ergebnis.

Zweig vier: Hat dich deine Referrer-Policy selbst ausgesperrt?

Der versteckte Fall. Hat deine Seite Referrer-Policy: no-referrer gesetzt, sendet der Browser beim Bildladen gar keinen Referer. Manche Hotlink-Schutz-Konfigurationen sind „leerer Referer wird immer geblockt", und schon sperrt dich deine eigene Datenschutz-Einstellung aus. In der Praxis tritt das meist bei Sites auf, die sehr auf Privatsphäre achten und die Meta-Referrer-Angabe komplett abdrehen.

Diagnose in der Praxis: DevTools und curl

Theorie durch, wie prüfst du konkret? Ich nutze fix zwei Werkzeuge und lokalisiere damit 90% der kaputten Bilder in fünf Minuten.

Werkzeug eins: DevTools Network-Tab

Entwicklertools öffnen (F12), zu Network wechseln, Seite neu laden, im Filter den Bilddateinamen eingeben. Klick in die Anfrage und sieh dir drei Dinge an:

  • Status: 403, 404 oder 200?
  • Content-Type in den Response Headers: image/* oder text/html?
  • Referer in den Request Headers: Was wird tatsächlich gesendet? Leer oder deine Domain?

Nach diesen drei taucht die Ursache meist auf.

Werkzeug zwei: curl mit manuellem Referer

DevTools zeigt das Phänomen, aber um „ist es wirklich Hotlink-Schutz" zu verifizieren, ist curl am direktesten. Du setzt beliebige Referer und schaust, wie der Server reagiert:

# ganz ohne Referer (simuliert direktes Öffnen)
curl -I "https://example.com/photo.jpg"

# mit einem Referer, der "von der Quellseite selbst" tut
curl -I -H "Referer: https://example.com/" "https://example.com/photo.jpg"

# mit einem Referer "von deiner externen Seite"
curl -I -H "Referer: https://your-blog.com/" "https://example.com/photo.jpg"

Die Auswertung ist eindeutig. Geben der erste und dritte 403, der zweite aber 200 — Glückwunsch, Hotlink-Schutz bewiesen. Der Server erkennt nur den Referer der Quellseite selbst, alles andere geblockt. Geben alle drei 200, hat der Bruch nichts mit Hotlink-Schutz zu tun, zurück zur URL- oder CSP-Prüfung.

Ich fahre gewohnheitsmäßig alle drei zusammen, der Vergleich ist viel klarer als eine einzelne Zeile. Genau deshalb ist curl effizienter als blindes Klicken im Browser.

Hotlink-Verhalten gängiger Bild-Hoster und CDNs

Die Standardlaune der Dienste unterscheidet sich stark. Unten meine Beobachtung aus Jahren des Bilder-Umziehens; die konkreten Einstellungen können sich jederzeit ändern, aber die Richtung stimmt.

Diensttyp Hotlink-Schutz standardmäßig Verhalten bei leerem Referer Für externen Direktlink geeignet?
selbst gehostetes Nginx / Apache je nach Konfiguration meist durchgelassen je nach Einstellung
Enterprise-CDN (Whitelist möglich) an- oder abschaltbar frei konfigurierbar richtig gesetzt: ja
manche kostenlose Bild-Hoster oft an oft geblockt oft geblockt
Bild-Domains von Social-Plattformen (Instagram-, Facebook-CDN) fast immer an fast immer geblockt nein, vergiss es
auf Teilen ausgerichteter Bild-Hoster meist aus durchgelassen ja, genau dafür existiert er

Die entscheidende Zeile ist die vierte. Bild-URLs, die du aus den CDN-Domains von Social-Plattformen wie Instagram oder Facebook kopierst, lassen sich fast zu 100% nicht extern einbetten, weil ihr Geschäftsmodell darin besteht, dich innerhalb der Plattform einzusperren. Die Bilder woanders posten? Sackgasse.

Und ein auf „Teilen" ausgerichteter Bild-Hoster hat Hotlink-Schutz standardmäßig aus — sein Existenzzweck ist, dass dein Bild stabil von fremden Seiten geladen werden kann. Verwechsle diese zwei Kategorien bloß nicht.

Die Referrer-Policy-Falle: sogar der Browser kann dich sabotieren

Den versteckten Fall von oben hier ausführlich, weil er einen am ehesten am Verstand zweifeln lässt.

Referrer-Policy ist ein Header, den die Seite (die anfragende Partei) setzen kann. Er entscheidet, wie viel Referer-Information der Browser sendet. Es gibt mehrere Werte:

  • no-referrer: sendet gar nichts.
  • origin: sendet nur die Herkunftsdomain.
  • strict-origin-when-cross-origin: Cross-Origin nur die Domain, Downgrade auf HTTP sendet nichts (moderner Standard).
  • unsafe-url: sendet sogar den vollen Pfad (nicht empfohlen, leakt Privatsphäre).

Hier der Widerspruch. Hotlink-Schutz braucht den Referer zur Herkunftsbestimmung, aber die Datenschutzpolitik ermutigt, wenig bis keinen Referer zu senden. Setzt eine Site aus Datenschutzgründen no-referrer und lädt ein Bild mit Hotlink-Schutz, der „leeren Referer immer blockt", brechen alle Bilder.

Genau das ging mir live einmal schief — eine sehr datenschutzbewusste Site hatte seitenweit no-referrer, und alle externen Bilder brachen. Ich dachte erst, der Bild-Hoster sei down, und suchte lange, bis ich merkte, dass meine eigene Meta-Angabe den Referer abgewürgt hatte. Diese Falle liegt fern, denn „mehr Datenschutz" klingt nicht danach, dass es einem selbst schadet.

Ein DSGVO-Randgedanke, der im deutschsprachigen Raum relevant ist: Ein voller Referer mit Pfad kann für die Zielseite personenbezogene oder verhaltensbezogene Information darstellen. Der moderne Standard strict-origin-when-cross-origin ist deshalb ein sinnvoller Datenschutz-Default — nur eben inkompatibel mit strengem „leerer Referer blockt". Man wählt hier faktisch zwischen Datensparsamkeit und Kompatibilität.

Die richtige Lösung: hotlinke fremde Bilder nicht

Am Ende der Fehlersuche steht eine harte Wahrheit: Solange ein Bild nicht bei dir selbst gehostet ist, kann jedes „fremde Bild" zu einem Zeitpunkt verschwinden, den du nicht kontrollierst. Der Gegenüber ändert den Hotlink-Schutz, tauscht die URL, löscht die Datei oder legt die ganze Site still, und deine Seite bricht mit.

Wirklich stabil sind nur zwei Wege.

Erstens: Hoste das Bild dort neu, wo du Kontrolle hast. Bette nicht direkt fremde URLs ein. Lad das Bild herunter, auf deinen eigenen Speicher oder einen Hoster, der externe Links erlaubt, und nutze diese stabile URL. Architektonisch holst du damit die Verfügbarkeit deiner Seite aus fremden Serverhänden in deine eigenen zurück — solange die Quelle nicht dir gehört, schlägt jede Hotlink-Anpassung, jeder URL-Umbau, jede Abschaltung des Gegenübers direkt als Bruch auf deiner Seite durch, und du bekommst nicht mal eine Vorwarnung, oft erfährst du es erst durch Leser-Meldungen. Hast du bereits einen ganzen Schwung Altlinks auf fremden Domains, die du auf einmal umziehen willst, habe ich separat eine komplette SOP zum Batch-Ersetzen von Bild-Links geschrieben, die per Skript alle Alt-URLs seitenweit auf einmal tauscht. Kontrollierbare Quellen sind stabile Quellen.

Zweitens: Wähle einen Hoster, dessen Hotlink-Schutz standardmäßig aus ist. Viele kostenlose Hoster blocken externe Links, um Bandbreite zu sparen, und zeigen dir im Forum oder Blog einen Bruch. Für externe Links nimm einen Dienst, der Direktlinks ausdrücklich erlaubt.

Das ist auch ein Prinzip, das wir bei lpic.cc verfolgen: Nach dem Upload bekommst du eine stabile Bild-Direktlink-URL, kein Hotlink-Block per Default, damit es in Forum, Blog und Discord normal angezeigt wird und nicht grundlos zu 403 wird. Für private Bilder kannst du per Passwortschutz steuern, wer sie sieht. Zum Ausprobieren lade ein Bild kostenlos hoch, kleb den Link in eine andere Seite und du weißt sofort, ob es stabil hält.

Ehrlich gesagt gehören auch die Grenzen dazu: Der kostenlose Plan hat aktuell 30 Tage Aufbewahrung, kein dauerhaftes Archiv, und der Dienst ist werbefinanziert. Für Langzeit-Archiv oder große kommerzielle Bildbestände solltest du einen kostenpflichtigen Profi-Plan oder eigenen Speicher mit Backup prüfen. Ein Werkzeug ist nur im richtigen Kontext sinnvoll — das habe ich erst durch eigene Fehltritte gelernt.

Häufige Fragen (FAQ)

F: Warum öffne ich denselben Bild-Link selbst problemlos, aber auf fremder Seite bricht er?

Weil beim „direkten Öffnen" dein Referer leer oder von einer erlaubten Quelle ist, der Hotlink-Schutz lässt durch. Auf fremder Seite wird der Referer zu dieser externen Domain, steht nicht auf der Whitelist und wird zu 403 geblockt. Dieselbe URL, anderer Referer, völlig anderes Ergebnis.

F: Sind 403 und kaputtes Bild dasselbe?

Nein. 403 ist die explizite Server-Ablehnung (Status 403), kaputtes Bild ist nur die Bildschirmdarstellung „Browser kann nicht zeichnen". 403 verursacht einen Bruch, aber ein Bruch kann auch von falscher URL, falschem Content-Type oder CSP-Block kommen. Erst den Status prüfen.

F: Umgeht Referrer-Policy: no-referrer den Hotlink-Schutz?

Manchmal ja, manchmal wird es schlimmer. Ist der gegnerische Hotlink-Schutz „leerer Referer durchgelassen", kommst du ohne Referer durch. Ist er „leerer Referer immer geblockt", brichst du komplett. Kein zuverlässiger Trick, nutz ihn nicht als richtige Lösung.

F: Ich hole Bilder per Skript (Python / Node) und bekomme auch 403 — was tun?

Wie beim Browser — dein Skript sendet nicht den richtigen Referer. Test erst per curl, welchen Referer der Gegenüber akzeptiert, und ergänze denselben Header in deiner HTTP-Anfrage. Aber Achtung: Das Umgehen fremden Hotlink-Schutzes kann gegen die Nutzungsbedingungen verstoßen, das musst du selbst abwägen.

F: Wie prüfe ich schnell, ob ein Bild-Hoster externe Links erlaubt?

Ein Testbild hochladen, den Direktlink nehmen und curl -I -H "Referer: https://google.com/" laufen lassen. 200 heißt externe Links erlaubt, 403 heißt Hotlink-Schutz, nicht für fremde Seiten nutzen. In dreißig Sekunden verifiziert.

References

#Hotlink-Schutz#hotlink protection#403 Forbidden#Referer#Referrer-Policy#CDN#Bild-Direktlink 2026
H

Verfasst von

Harvey Zhang

Mitgründer & CTO

Backend-Ingenieur und Systemarchitekt mit fundierter technischer Analyse von Bildhosting-Infrastrukturen.