← Wszystkie wpisy
Wydajność i bezpieczeństwo 6 min czytania

Nagłówki bezpieczeństwa HTTP w Akamai CDN

Nagłówki bezpieczeństwa HTTP przekazują przeglądarce zasady obsługi strony: określają, skąd wolno ładować zasoby, czy witrynę można osadzić w ramce i do jakich funkcji urządzenia ma dostęp aplikacja. Gdy serwis działa za Akamai CDN, politykę tę można wdrożyć centralnie na warstwie brzegowej, bez zmieniania konfiguracji każdego serwera źródłowego.

Dlaczego warto ustawić nagłówki na warstwie Akamai?

W Akamai Property Manager służy do tego behavior Modify Outgoing Response Header. Pozwala dodawać, usuwać i modyfikować nagłówki odpowiedzi wysyłanej z Akamai do klienta. Regułę można zastosować do całego Property albo ograniczyć ją do wybranych hostów, ścieżek lub typów odpowiedzi.

Nagłówek dodany w tym miejscu jest nakładany po przetworzeniu odpowiedzi przez Akamai, bezpośrednio przed wysłaniem jej do użytkownika. Dzięki temu zmiana nie modyfikuje obiektu przechowywanego w cache CDN, a jedna polityka może objąć odpowiedzi pobrane z origina oraz obsłużone z pamięci podręcznej.

Najpierw sprawdź nagłówki zwracane przez origin. Jeżeli ten sam nagłówek jest już ustawiany przez aplikację lub reverse proxy, zdecyduj, czy Akamai ma go zastąpić, zachować, czy usunąć i dodać ponownie. Dwie sprzeczne wartości mogą dać inny rezultat w zależności od przeglądarki.

Zestaw startowy

Przykładowa baza dla typowego serwisu internetowego może wyglądać następująco:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'
To punkt wyjścia, a nie gotowa konfiguracja dla każdej aplikacji. Szczególnie HSTS, Permissions Policy i Content Security Policy trzeba dopasować do domen, integracji i funkcji używanych przez konkretny serwis.

Strict-Transport-Security, czyli HSTS

HSTS informuje przeglądarkę, że domena powinna być otwierana wyłącznie przez HTTPS. Typowa konfiguracja zapisująca tę decyzję na rok wygląda tak:

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age=31536000 oznacza 31 536 000 sekund, czyli jeden rok. Dyrektywa includeSubDomains rozszerza zasadę również na subdomeny.

HSTS wymaga ostrożnego wdrożenia. Przed dodaniem includeSubDomains upewnij się, że każda używana subdomena poprawnie obsługuje HTTPS. Przeglądarka pamięta politykę przez czas określony w max-age, dlatego błędnej konfiguracji nie da się natychmiast cofnąć po stronie użytkownika.

Ochrona przed osadzaniem strony

Nagłówek X-Frame-Options określa, czy stronę można umieścić w elemencie <iframe>. Ogranicza w ten sposób ryzyko clickjackingu, w którym właściwy interfejs zostaje osadzony lub zasłonięty przez witrynę kontrolowaną przez atakującego.

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

DENY zabrania osadzania strony, a SAMEORIGIN pozwala na nie tylko w obrębie tego samego originu. Bardziej elastyczną kontrolę zapewnia dyrektywa frame-ancestors w Content Security Policy. Można stosować ją razem z X-Frame-Options, jeśli serwis nadal obsługuje starszych klientów.

X-Content-Type-Options

Ta konfiguracja zabrania przeglądarce zgadywania typu MIME zasobu:

X-Content-Type-Options: nosniff

Jeżeli odpowiedź deklaruje konkretny Content-Type, przeglądarka powinna go respektować zamiast próbować interpretować zawartość jako inny rodzaj danych. To prosty nagłówek, który zwykle można wdrożyć bez wpływu na prawidłowo skonfigurowaną aplikację. Ewentualne problemy najczęściej ujawniają błędne typy MIME zwracane przez sam serwer.

Content Security Policy

Content Security Policy, czyli CSP, jest najbardziej rozbudowanym z opisywanych mechanizmów. Pozwala kontrolować źródła skryptów, arkuszy CSS, obrazów, fontów, ramek oraz połączeń wykonywanych przez aplikację.

Content-Security-Policy: default-src 'self'; script-src 'self' https://example-cdn.com; img-src 'self' data: https:; frame-ancestors 'self'

Polityka default-src 'self' dopuszcza domyślnie zasoby wyłącznie z tego samego originu. W rzeczywistej aplikacji trzeba zwykle uwzględnić system analityczny, fonty, CDN, zewnętrzne API, osadzone materiały i skrypty dostawców.

Najpierw raportowanie, później blokowanie

Zbyt restrykcyjna CSP może zablokować skrypty, style lub połączenia niezbędne do działania serwisu. Dlatego wdrożenie warto rozpocząć od nagłówka:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Tryb Report-Only rejestruje naruszenia, ale ich nie wymusza. Zebrane raporty pozwalają zidentyfikować legalne źródła i przygotować politykę, którą można później przenieść do nagłówka Content-Security-Policy. Sam endpoint raportowy powinien być przygotowany na dużą liczbę powtarzających się zgłoszeń.

Permissions Policy

Permissions Policy określa, z jakich funkcji przeglądarki może korzystać witryna i osadzone w niej dokumenty. Jeżeli aplikacja nie potrzebuje kamery, mikrofonu ani lokalizacji, można je jawnie wyłączyć:

Permissions-Policy: camera=(), microphone=(), geolocation=()

Lista funkcji powinna wynikać z działania serwisu. Aplikacja wykorzystująca lokalizację użytkownika lub połączenia wideo wymaga odpowiednio innej polityki oraz wskazania dozwolonych originów.

Referrer Policy

Przy przechodzeniu między stronami przeglądarka może wysyłać nagłówek Referer z adresem strony źródłowej. Referrer-Policy określa, ile tej informacji trafi do kolejnego serwisu.

Referrer-Policy: strict-origin-when-cross-origin

Ta wartość zachowuje pełniejsze dane w obrębie tego samego originu, natomiast przy przejściu do innego originu ogranicza je do jego adresu. Bardziej restrykcyjne no-referrer całkowicie wyłącza przesyłanie informacji o stronie źródłowej, ale może też ograniczyć dane potrzebne do analityki lub integracji.

X-XSS-Protection jest mechanizmem historycznym

X-XSS-Protection aktywował filtry XSS w starszych przeglądarkach. Obecnie jest nagłówkiem przestarzałym i niestandardowym. Współczesna ochrona powinna opierać się na poprawnym kodowaniu danych wyjściowych, walidacji, aktualnym oprogramowaniu oraz dobrze przygotowanej Content Security Policy.

Jeżeli nagłówek nadal występuje w istniejącej konfiguracji, warto ustalić, czy wynika to z rzeczywistej potrzeby obsługi starszych klientów. Nie powinien być traktowany jako zamiennik CSP.

Konfiguracja w Akamai Property Manager

W odpowiednim miejscu drzewa reguł danego Property dodaj behavior Modify Outgoing Response Header. Dla własnego nagłówka konfiguracja opiera się na następujących polach:

Action: Add
Select Header Name: Other
Custom Header Name: <nazwa nagłówka>
Header Value: <wartość>

Przykład dla X-Content-Type-Options:

Action: Add
Select Header Name: Other
Custom Header Name: X-Content-Type-Options
Header Value: nosniff

Analogicznie można dodać pozostałe nagłówki. Behavior obsługuje również ich usuwanie, modyfikowanie oraz wyszukiwanie i zamianę fragmentów wartości.

Rozdziel reguły według zakresu

01
Całe PropertyNagłówki, które mają obowiązywać na każdym hoście i typie strony.
02
Dokumenty HTMLCSP, ochrona ramek i polityki dotyczące funkcji przeglądarki.
03
Wybrane hosty i ścieżkiWyjątki dla aplikacji, paneli, integracji oraz treści osadzanych w iframe.
04
Środowisko testoweWeryfikacja zmian przed aktywacją na ruchu produkcyjnym.

Nie każdy nagłówek musi być dodawany na każdym typie odpowiedzi. Przykładowo CSP ma największe znaczenie dla dokumentów, które przeglądarka interpretuje jako HTML, natomiast HSTS powinien być spójny dla hosta obsługiwanego przez HTTPS.

Weryfikacja publicznej odpowiedzi

Po aktywacji zmian sprawdź publiczny adres aplikacji, czyli odpowiedź przechodzącą już przez Akamai. Najprostszy test można wykonać poleceniem:

curl -I https://www.example.com

W odpowiedzi powinny pojawić się oczekiwane wartości:

HTTP/2 200
content-type: text/html
strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()
content-security-policy: default-src 'self'

Nie ograniczaj testu do strony głównej. Sprawdź przekierowania, błędy 4xx i 5xx, podstrony aplikacji, odpowiedzi pobierane z cache oraz odpowiedzi przekazywane z origina. Warto też otworzyć konsolę przeglądarki i zweryfikować naruszenia CSP oraz funkcje wymagające uprawnień.

Bezpieczna kolejność wdrożenia

  1. Zbierz aktualne nagłówki z Akamai i bezpośrednio z origina.
  2. Ustal zakres reguły oraz sposób obsługi wartości już zwracanych przez aplikację.
  3. Dodaj najprostsze polityki, takie jak X-Content-Type-Options i Referrer-Policy.
  4. Zweryfikuj HTTPS na wszystkich subdomenach przed rozszerzeniem HSTS.
  5. Uruchom CSP w trybie Report-Only i zbierz reprezentatywne raporty.
  6. Sprawdź stronę w kilku przeglądarkach oraz przetestuj logowanie, formularze i integracje.
  7. Aktywuj zmiany produkcyjnie i monitoruj błędy po wdrożeniu.

Jedna polityka, ale dopasowana do aplikacji

Przeniesienie nagłówków bezpieczeństwa do Akamai upraszcza zarządzanie nimi i pozwala stosować jednolite zasady niezależnie od tego, czy odpowiedź pochodzi z cache CDN, czy z serwera źródłowego. Najwięcej przygotowania wymagają HSTS i CSP, ponieważ błędna konfiguracja może realnie ograniczyć dostępność serwisu lub zablokować jego funkcje.

Dobrą bazę stanowią Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, Permissions-Policy i Referrer-Policy. Ich wartości powinny jednak wynikać z architektury aplikacji, a wdrożenie kończyć się testem publicznej odpowiedzi, nie jedynie sprawdzeniem konfiguracji w panelu.