iframe-Einbettungsprüfung

Was bestimmt, ob eine Seite eingebettet werden kann?

Kurzanleitung: Einrichtung von Response-Headern

Wenn Sie die Website besitzen, steuern Sie die Einbettung direkt über Antwortheader.

Hinweis: X-Frame-Options wird durch CSP frame-ancestors abgelöst. Wenn beide vorhanden sind, hat CSP Vorzug – bevorzugen Sie frame-ancestors.

Wie erkennt der Server, dass eine Anfrage von einem iFrame stammt?

• Sec-Fetch-Dest: document – Top-Level-Navigation, nicht in einem Frame enthalten.
• Sec-Fetch-Dest: iframe – Die Anfrage wird in einem <iframe>-Element geladen.
• Sec-Fetch-Dest: frame – In einem älteren <frame>-Element (Frameset) geladen.
• Sec-Fetch-Dest: embed/object – In einem <embed>- oder <object>-Element geladen.

Server-Konfigurationsbeispiele: IFrame-Einbindung blockieren

Die folgenden Codeausschnitte zeigen, wie Sie jeden Server oder jedes Framework konfigurieren, um iframe-Einbettung vollständig zu blockieren (X-Frame-Options: DENY + CSP frame-ancestors 'none') – die strengste Maßnahme aus der Schnellanleitung oben.

server {
    location / {
        add_header X-Frame-Options "DENY" always;
        add_header Content-Security-Policy "frame-ancestors 'none'" always;
    }
}

<IfModule mod_headers.c>
    Header always set X-Frame-Options "DENY"
    Header always set Content-Security-Policy "frame-ancestors 'none'"
</IfModule>

app.use((req, res, next) => {
  res.setHeader('X-Frame-Options', 'DENY');
  res.setHeader('Content-Security-Policy', "frame-ancestors 'none'");
  next();
});

// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          { key: 'X-Frame-Options', value: 'DENY' },
          { key: 'Content-Security-Policy', value: "frame-ancestors 'none'" },
        ],
      },
    ];
  },
};

class SetFrameOptions
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);
        $response->headers->set('X-Frame-Options', 'DENY');
        $response->headers->set('Content-Security-Policy', "frame-ancestors 'none'");

        return $response;
    }
}

export default {
  async fetch(request) {
    const response = await fetch(request);
    const headers = new Headers(response.headers);
    headers.set('X-Frame-Options', 'DENY');
    headers.set('Content-Security-Policy', "frame-ancestors 'none'");
    return new Response(response.body, { status: response.status, headers });
  },
};

Müssen Sie stattdessen nur Ihre eigene Website oder eine kurze Zulassungsliste zur Einbettung der Seite erlauben, statt alle zu blockieren? Tauschen Sie DENY gegen SAMEORIGIN und 'none' gegen 'self' oder eine explizite Ursprungsliste aus – der Rest der Konfiguration bleibt gleich.

Bekannte Fallstricke bei Plattformen

Von allgemeinen Header-Regeln abgesehen, haben einige bekannte Plattformen eigene Besonderheiten – das ist wert zu wissen, bevor man allein anhand von Headern annimmt, dass etwas „blockiert“ oder „einbettbar“ ist.

Häufige Anwendungsfälle

• Entscheiden Sie, ob ein externes Widget, Dashboard oder Dokument in Ihr eigenes Produkt eingebettet werden kann, bevor Sie Integrationscode schreiben.
• Überprüfen Sie, ob Ihre eigene Seite die X-Frame-Options- oder CSP frame-ancestors-Richtlinie sendet, die Sie beabsichtigt haben.
• Clickjacking-Schutz debuggen: Verstehen, warum eine Seite about:blank oder eine Ablehnungsmeldung in einem iframe anzeigt.
• Kandidaten-URLs stapelweise prüfen bei der Inhaltsaggregation oder Portal-Integration, wobei die Sitzungsverlauf verwendet wird, um Ergebnisse erneut aufzurufen.
• Vorbereitung auf Sicherheitsüberprüfungen oder Penetrationstests durch Dokumentation der Framing-Richtlinie externer Abhängigkeiten.

FAQs