Von Objekten zu iframes — allgemeine Einbettungstechnologien

Eine kurze Geschichte des Einbettens

Vor langer Zeit im Web war es populär, Frames zu verwenden, um Websites zu erstellen — kleine Teile einer Website, die in einzelnen HTML-Seiten gespeichert waren. Diese wurden in ein Meisterdokument eingefügt, das als Frameset bezeichnet wurde und es Ihnen ermöglichte, den Bereich auf dem Bildschirm zu spezifizieren, den jeder Frame ausfüllte, ähnlich wie beim Festlegen der Größe von Spalten und Reihen einer Tabelle. Diese galten in den späten 90er Jahren als das Nonplusultra, und es gab Hinweise darauf, dass das Aufteilen einer Webseite in kleinere Teile die Download-Geschwindigkeit verbesserte — was besonders bemerkbar war, da die Netzwerkverbindungen damals so langsam waren. Allerdings hatten sie viele Probleme, die alle Vorteile überwogen, als die Netzwerkgeschwindigkeiten schneller wurden, weshalb man sie heute nicht mehr benutzt.

Etwas später (Ende der 90er, Anfang der 2000er) wurden Plugin-Technologien sehr populär, wie Java-Applets und Flash — diese erlaubten Webentwicklern, reichhaltige Inhalte wie Videos und Animationen in Webseiten einzubetten, die HTML allein nicht bieten konnte. Das Einbetten dieser Technologien wurde durch Elemente wie <object> und das weniger gebräuchliche <embed> erreicht, und sie waren damals sehr nützlich. Sie sind inzwischen aus der Mode gekommen aufgrund vieler Probleme, einschließlich Barrierefreiheit, Sicherheit, Dateigröße und mehr. Heutzutage haben große Browser die Unterstützung für Plugins wie Flash eingestellt.

Schließlich erschien das <iframe> Element (zusammen mit anderen Methoden zur Einbettung von Inhalten, wie <canvas>, <video>, etc.). Dieses bietet eine Möglichkeit, ein gesamtes Webdokument innerhalb eines anderen einzubetten, als wäre es ein <img> oder ein ähnliches Element, und wird heute regelmäßig verwendet.

Mit dieser Geschichtsstunde abgehakt, lassen Sie uns weitermachen und sehen, wie man einige dieser Techniken verwendet.

Spielen mit klassischen Einbettungsanwendungen

In diesem Artikel werden wir direkt in eine Übung einsteigen, um Ihnen sofort eine Vorstellung davon zu geben, wofür Einbettungstechnologien nützlich sind. Die Online-Welt ist sehr vertraut mit YouTube, aber viele Menschen wissen nicht über einige der integrierten Sharing-Funktionen Bescheid.

1. Öffnen Sie zuerst den MDN Playground.
2. Schauen wir uns nun an, wie YouTube es uns erlaubt, ein Video in jede beliebige Seite einzubetten, die wir mögen, mithilfe eines <iframe>.
   1. Gehen Sie zu YouTube und finden Sie ein Video, das Ihnen gefällt.
   2. Unter dem Video finden Sie einen Teilen-Button — wählen Sie diesen aus, um die Sharing-Optionen anzuzeigen.
   3. Wählen Sie den Einbetten-Button, und Sie erhalten einige <iframe>-Codes — kopieren Sie diese.
   4. Fügen Sie es in den HTML-Bereich im Playground ein und sehen Sie sich das Ergebnis in der Ausgabe an.
3. Für Bonuspunkte können Sie auch versuchen, eine Google Map in den Playground einzubetten:
   1. Gehen Sie zu Google Maps und finden Sie eine Karte, die Ihnen gefällt.
   2. Klicken Sie auf das "Hamburger-Menü" (drei horizontale Linien) oben links in der Benutzeroberfläche.
   3. Wählen Sie die Option Karte teilen oder einbetten.
   4. Wählen Sie die Option Karte einbetten, die Ihnen einen <iframe>-Code gibt – kopieren Sie diesen.
   5. Fügen Sie ihn in den HTML-Bereich im Playground ein und sehen Sie sich das Ergebnis in der Ausgabe an.

Wenn Sie einen Fehler machen, können Sie ihn jederzeit mit dem Reset-Button im Playground zurücksetzen.

iframes im Detail

Das war einfach und hat Spaß gemacht, oder? <iframe>-Elemente sind dafür vorgesehen, andere Web-Dokumente in das aktuelle Dokument einzubetten. Das ist großartig, um Drittanbieterinhalte in Ihre Website zu integrieren, über die Sie möglicherweise keine direkte Kontrolle haben und deren eigene Version Sie nicht implementieren möchten — wie Videos von Online-Videoanbietern, Kommentarsysteme wie Disqus, Karten von Online-Kartenanbietern, Werbebanner usw. Sogar die Live-Editierbaren Beispiele, die Sie in diesem Kurs verwendet haben, sind mit <iframe>s implementiert.

Bevor Sie sich in die Nutzung von <iframe>-Elementen stürzen, gibt es einige Sicherheitsbedenken, die beachtet werden sollten. Angenommen, Sie möchten das MDN-Lexikon auf einer Ihrer Webseiten mithilfe des <iframe>-Elements einbinden. In diesem Fall könnten Sie versuchen, etwas wie das folgende Codebeispiel zu verwenden. Wenn Sie den folgenden Code in eine Ihrer Seiten einfügen würden, wären Sie wahrscheinlich überrascht, eine Fehlermeldung anstelle der Lexikonseite zu sehen:

<iframe
  src="https://developer.mozilla.org/en-US/docs/Glossary"
  width="100%"
  height="500"
  allowfullscreen
  sandbox>
</iframe>

iframe {
  border: none;
}

Wenn Sie sich die Konsole Ihres Browsers ansehen, sehen Sie eine Fehlermeldung wie die folgende:

Refused to display 'https://developer.mozilla.org/' in a frame because it set 'X-Frame-Options' to 'deny'.

Der Sicherheits-Abschnitt unten geht näher auf die Gründe ein, warum diese Fehlermeldung angezeigt wird, aber zuerst werfen wir einen Blick darauf, was unser Code macht.

Das Beispiel enthält die wesentlichen Grundlagen, die zum Verwenden eines <iframe> erforderlich sind:

border: none

Wenn verwendet, wird das <iframe> ohne umgebenden Rahmen angezeigt. Andernfalls zeigen Browser standardmäßig das <iframe> mit einem umgebenden Rahmen an (was im Allgemeinen unerwünscht ist).

allowfullscreen

Wenn gesetzt, kann das <iframe> mithilfe der Fullscreen API in den Vollbildmodus versetzt werden (etwas außerhalb des Umfangs dieses Artikels).

src

Dieses Attribut enthält, wie bei <video>/<img>, einen Pfad, der auf die URL des einzubettenden Dokuments verweist.

width und height

Diese Attribute spezifizieren die Breite und Höhe, die Sie für das iframe möchten.

sandbox

Dieses Attribut, das in etwas moderneren Browsern funktioniert als der Rest der <iframe>-Funktionen (z. B. IE 10 und höher), fordert erhöhte Sicherheitseinstellungen an; hierzu später mehr im nächsten Abschnitt.

Sicherheitsbedenken

Oben haben wir Sicherheitsbedenken erwähnt — gehen wir nun etwas detaillierter darauf ein. Wir erwarten nicht, dass Sie all diesen Inhalt beim ersten Mal perfekt verstehen; wir möchten Sie lediglich auf dieses Problem aufmerksam machen und eine Referenz bereitstellen, auf die Sie zurückkommen können, wenn Sie erfahrener werden und anfangen, <iframe>s in Ihren Experimenten und Arbeiten in Betracht zu ziehen. Außerdem besteht kein Grund, sich zu fürchten und keine <iframe>s zu verwenden — Sie müssen nur vorsichtig sein. Lesen Sie weiter …

Browserhersteller und Webentwickler haben auf die harte Tour gelernt, dass iframes ein häufiges Ziel (offizieller Begriff: Angriffsvektor) für schlechte Menschen im Web sind (oft Hacker genannt, oder genauer Cracker), die versuchen, Ihre Webseite böswillig zu ändern oder Personen dazu zu bringen, etwas zu tun, das sie nicht tun wollen, wie Benutzername und Passwort preiszugeben. Aufgrund dessen haben Spezifikationsingenieure und Browserentwickler verschiedene Sicherheitsmechanismen entwickelt, um <iframe>s sicherer zu machen, und es gibt auch bewährte Verfahren, die beachtet werden müssen — einige davon werden wir im Folgenden behandeln.

Ein schnelles Beispiel zunächst — versuchen Sie, das vorherige Beispiel, das wir oben gezeigt haben, in Ihrem Browser zu laden — Sie können es live auf GitHub finden (sehen Sie sich den Quellcode ebenfalls an). Anstelle der erwarteten Seite sehen Sie wahrscheinlich eine Art Nachricht mit dem Effekt "Ich kann diese Seite nicht öffnen", und wenn Sie sich die Konsole in den Browser-Entwicklertools ansehen, erhalten Sie eine Nachricht, die Ihnen sagt, warum. In Firefox wird Ihnen etwas wie Das Laden von "https://developer.mozilla.org/de/docs/Glossary" in einem Frame wird durch die "X-Frame-Options"-Anweisung, die auf "DENY" gesetzt ist, verweigert.

Dies ist, weil die Entwickler, die MDN gebaut haben, eine Einstellung auf dem Server, der die Webseiten bereitstellt, hinzugefügt haben, die das Einbetten innerhalb von <iframe>s untersagt (siehe Konfigurieren von CSP-Richtlinien, unten). Das macht Sinn — eine vollständige MDN-Seite macht wirklich keinen Sinn in andere Seiten eingebettet zu werden, es sei denn, Sie möchten etwas wie das Einbetten auf Ihrer Seite tun und sie als Ihre eigenen beanspruchen — oder versuchen, Daten über Clickjacking zu stehlen, was beides wirklich schlechte Dinge sind. Auch, wenn jeder damit anfangen würde, all die zusätzlichen Bandbreitenkosten würden Mozilla viel Geld kosten.

Nur einbetten, wenn nötig

Manchmal macht es Sinn, Drittinhalte einzubetten — wie YouTube-Videos und Karten — aber Sie können sich viele Kopfschmerzen ersparen, wenn Sie nur dann Drittinhalte einbetten, wenn es absolut notwendig ist. Eine gute Regel für Websicherheit ist "Man kann nie zu vorsichtig sein. Wenn Sie es gemacht haben, überprüfen Sie es trotzdem doppelt. Wenn es jemand anderes gemacht hat, gehen Sie davon aus, dass es gefährlich ist, bis das Gegenteil bewiesen ist."

Neben der Sicherheit sollten Sie auch auf Fragen des geistigen Eigentums achten. Die meisten Inhalte sind urheberrechtlich geschützt, offline und online, auch Inhalte, die Sie vielleicht nicht erwarten (zum Beispiel die meisten Bilder auf Wikimedia Commons). Zeigen Sie niemals Inhalte auf Ihrer Webseite an, wenn Sie sie nicht besitzen oder die Eigentümer Ihnen keine schriftliche, eindeutige Erlaubnis erteilt haben. Die Strafen für Urheberrechtsverletzungen sind schwerwiegend. Wieder einmal gilt: Man kann nie zu vorsichtig sein.

Wenn die Inhalte lizenziert sind, müssen Sie die Lizenzbedingungen einhalten. Der Inhalt auf MDN ist beispielsweise lizenziert unter CC-BY-SA. Das bedeutet, Sie müssen uns ordnungsgemäß creditieren, wenn Sie unsere Inhalte zitieren, auch wenn Sie wesentliche Änderungen daran vornehmen.

Verwenden Sie HTTPS

HTTPS ist die verschlüsselte Version von HTTP. Sie sollten Ihre Webseiten wann immer möglich mit HTTPS ausliefern:

1. HTTPS reduziert die Wahrscheinlichkeit, dass entfernte Inhalte während der Übertragung manipuliert wurden.
2. HTTPS verhindert, dass eingebettete Inhalte auf Inhalte in Ihrem übergeordneten Dokument zugreifen können und umgekehrt.

Das Aktivieren von HTTPS für Ihre Seite erfordert die Installation eines speziellen Sicherheitszertifikats. Viele Hostinganbieter bieten HTTPS-fähiges Hosting an, ohne dass Sie selbst ein Zertifikat einrichten müssen. Wenn Sie jedoch den https-Support für Ihre Site selbst einrichten müssen, bietet Let's Encrypt Tools und Anleitungen für das automatische Erstellen und Installieren des erforderlichen Zertifikats — mit integrierter Unterstützung für die am weitesten verbreiteten Web-Server, einschließlich des Apache-Webservers, Nginx und andere. Das Let's Encrypt-Tooling ist so konzipiert, dass der Prozess so einfach wie möglich ist, es gibt also keinen wirklich guten Grund, es zu vermeiden oder andere zur Verfügung stehende Mittel nicht zu nutzen, um Ihre Site mit HTTPS zu sichern.

Verwenden Sie immer das sandbox-Attribut

Sie sollten Angreifern so wenig Macht wie möglich geben, um schlechte Dinge auf Ihrer Website zu tun, deshalb sollten Sie eingebetteten Inhalten nur die Berechtigungen geben, die notwendig sind, um ihre Aufgabe zu erfüllen. Natürlich gilt dies auch für Ihre eigenen Inhalte. Ein Container für Code, in dem er angemessen verwendet werden kann — oder zum Testen — aber dem Rest des Codes (entweder versehentlich oder böswillig) keinen Schaden zufügen kann, wird als Sandbox bezeichnet.

Inhalts, das nicht in einer Sandbox ausgeführt wird, kann möglicherweise JavaScript ausführen, Formulare absenden, Pop-up-Fenster auslösen usw. Standardmäßig sollten Sie alle verfügbaren Einschränkungen durch das sandbox-Attribut ohne Parameter verwenden, wie in unserem vorherigen Beispiel gezeigt.

Falls unbedingt erforderlich, können Sie die Berechtigungen einzeln wieder hinzufügen (innerhalb des Werts des sandbox=""-Attributs) — siehe den sandbox Referenzeintrag für alle verfügbaren Optionen. Ein wichtiger Hinweis ist, dass Sie niemals sowohl allow-scripts als auch allow-same-origin zu Ihrem sandbox-Attribut hinzufügen sollten — in diesem Fall könnten die eingebetteten Inhalte die Same-Origin-Richtlinie umgehen, die das Ausführen von Skripten auf Websites verhindert, und JavaScript verwenden, um das Sandboxing komplett zu deaktivieren.

Konfigurieren von CSP-Richtlinien

CSP steht für Content Security Policy und bietet eine Reihe von HTTP-Headern (Metadaten, die zusammen mit Ihren Webseiten bereitgestellt werden, wenn sie von einem Webserver bereitgestellt werden), die darauf ausgelegt sind, die Sicherheit Ihres HTML-Dokuments zu verbessern. Wenn es darum geht, <iframe>s sicherer zu machen, können Sie Ihren Server konfigurieren, um einen geeigneten "X-Frame-Options"-Header zu senden. Dies kann verhindern, dass andere Websites Ihre Inhalte in ihren Webseiten einbetten (was Clickjacking und eine Reihe anderer Angriffe ermöglichen würde), was genau das ist, was die MDN-Entwickler getan haben, wie wir zuvor gesehen haben.

Die <embed> und <object> Elemente

Die <embed> und <object> Elemente haben eine andere Funktion als <iframe> — diese Elemente sind allgemeine Einbettungstools zum Einbetten externer Inhalte, wie PDFs.

Allerdings werden Sie diese Elemente vermutlich nicht sehr oft verwenden. Wenn Sie PDFs anzeigen müssen, ist es in der Regel besser, einen Link zu ihnen zu setzen, anstatt sie in die Seite einzubetten.

Historisch gesehen wurden diese Elemente auch zum Einbetten von Inhalten verwendet, die von Browser-Plugins](/de/docs/Glossary/Plugin) wie Adobe Flash gehandhabt werden, aber diese Technologie ist jetzt veraltet und wird von modernen Browsern nicht mehr unterstützt.

Wenn Sie sich in der Situation befinden, Plugin-Inhalte einbetten zu müssen, benötigen Sie mindestens diese Art von Informationen:

Schauen wir uns ein <object>-Beispiel an, das ein PDF in eine Seite einbettet (siehe das Live-Beispiel und den Quellcode):

<object data="my-pdf.pdf" type="application/pdf" width="800" height="1200">
  <p>
    You don't have a PDF plugin, but you can
    <a href="my-pdf.pdf">download the PDF file. </a>
  </p>
</object>

PDFs waren ein notwendiger Zwischenschritt zwischen Papier und Digital, stellen jedoch viele Barrierefreiheitsprobleme dar und können auf kleinen Bildschirmen schwer zu lesen sein. Sie sind immer noch in manchen Kreisen beliebt, es ist jedoch viel besser, zu ihnen zu verlinken, damit sie heruntergeladen oder auf einer separaten Seite gelesen werden können, anstatt sie in eine Webseite einzubetten.

Zusammenfassung

Das Thema des Einbettens anderer Inhalte in Webdokumente kann schnell sehr komplex werden. In diesem Artikel haben wir versucht, es auf einfache, vertraute Weise zu präsentieren, die sofort relevant erscheint, während wir dennoch auf einige der fortgeschritteneren Funktionen der beteiligten Technologien anspielen. Zunächst werden Sie das Einbetten wahrscheinlich nicht viel mehr verwenden als Inhalte von Drittanbietern wie Karten und Videos auf Ihren Seiten einzubetten. Wenn Sie jedoch erfahrener werden, werden Sie wahrscheinlich weitere Anwendungen dafür finden.

Es gibt viele andere Technologien, die das Einbetten externer Inhalte beinhalten, zusätzlich zu den hier besprochenen. Wir haben einige in früheren Artikeln gesehen, wie etwa <video>, <audio>, und <img>, aber es gibt noch andere zu entdecken, wie etwa <canvas> für JavaScript-generierte 2D- und 3D-Grafiken und <svg> für die Einbettung von Vektorgrafiken.