Sprawdzanie osadzania iframe

Co decyduje o tym, czy strona może być osadzona?

Szybki przewodnik: konfiguracja nagłówków odpowiedzi

Jeśli kontrolujesz witrynę, zarządzaj osadzaniem bezpośrednio poprzez nagłówki odpowiedzi.

Uwaga: Nagłówek X-Frame-Options wygasł na rzecz dyrektywy CSP frame-ancestors. Przy obecności obu, pierwszeństwo ma CSP — zalecamy stosowanie frame-ancestors.

W jaki sposób serwer wykrywa, że żądanie pochodzi z iframe'a?

• Sec-Fetch-Dest: document — nawigacja najwyższego poziomu, nie wewnątrz żadnej ramki.
• Sec-Fetch-Dest: iframe — żądanie jest ładowane wewnątrz elementu <iframe>.
• Sec-Fetch-Dest: frame — ładowane wewnątrz przestarzałego znacznika <frame> (frameset).
• Sec-Fetch-Dest: embed / object — ładowane wewnątrz elementu <embed> lub <object>.

Przykładowe konfiguracje serwerów: blokowanie osadzania w iframe

Poniższe przykłady kodu prezentują metodę konfiguracji każdego serwera lub frameworka w celu całkowitego zablokowania osadzania w iframach (X-Frame-Options: DENY + CSP frame-ancestors 'none') — stanowi to najbardziej restrykcyjną opcję spośród zaprezentowanych w przewodniku ekspresowym powyżej.

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 });
  },
};

Wystarczy zezwolić wyłącznie własnej witrynie lub krótkiej białej liście na osadzanie, zamiast blokować wszystkich? Zamień DENY na SAMEORIGIN oraz 'none' na 'self' lub jawną listę adresów — reszta konfiguracji pozostaje bez zmian.

Znane ograniczenia i uwagi dotyczące platform

Pomijając ogólne zasady dotyczące nagłówków, znane platformy często mają swoje specyficzne uwarunkowania. Warto je mieć na uwadze, zanim uznasz daną stronę za „zablokowaną” lub „nadającą się do osadzenia” wyłącznie na podstawie analizy nagłówków.

Typowe przypadki użycia

• Określ, czy zewnętrzny widżet, dashboard lub dokument może zostać osadzony we własnym produkcie, zanim zaczniesz programować integrację.
• Zweryfikuj, czy Twoja witryna poprawnie zwraca oczekiwaną politykę X-Frame-Options lub frame-ancestors w nagłówku CSP.
• Debuguj ochronę przed clickjackiem: sprawdź, dlaczego strona wyświetla `about:blank` lub komunikat o odrzuceniu wewnątrz ramki iframe.
• Weryfikuj adresy URL grupowo podczas agregacji treści lub integracji portali, wykorzystując historię sesji do ponownego przeglądania wyników.
• Przygotuj się do przeglądów bezpieczeństwa lub testów penetracyjnych, dokumentując politykę osadzania w ramkach zewnętrznych zależności.

Najczęściej zadawane pytania (FAQ)