Dodaj nagłówki bezpieczeństwa za pomocą Lambda@Edge i Terraform w AWS S3/CloudFront

Opublikowany: 2021-04-24

Gdy logujesz się na https://app.sendgrid.com , aby sprawdzić szczegóły swojego konta lub odwiedzasz https://mc.sendgrid.com dla kampanii marketingowych, odwiedzasz nasze frontowe aplikacje internetowe hostowane w zasobnikach AWS S3 z Dystrybucje CloudFront na nich.

Nasze aplikacje internetowe zasadniczo składają się ze zminimalizowanych i podzielonych na kod plików JavaScript i CSS, plików HTML oraz plików graficznych przesłanych do zasobników S3 jako pamięci podręcznej CloudFront i udostępniających je naszym użytkownikom. Każde ze środowisk naszych aplikacji internetowych, począwszy od testowania, przemieszczania i produkcji, ma osobne wiadro S3 i dystrybucję CloudFront.

Ta infrastruktura AWS S3 i CloudFront działa dobrze w przypadku naszych aplikacji internetowych na dużą skalę w hostowaniu plików w sieci dostarczania treści, ale w naszych początkowych konfiguracjach brakowało ściślejszych zabezpieczeń w postaci nagłówków zabezpieczeń.

Dodanie tych nagłówków bezpieczeństwa zapobiegłoby atakom, takim jak cross-site scripting, MIME sniffing, clickjacking, wstrzykiwanie kodu i ataki typu man-in-the-middle związane z niezabezpieczonymi protokołami. Jeśli zostawiono ich bez opieki, miałoby to poważne konsekwencje dla danych naszych klientów i dla zaufania naszej firmy, że będziemy w stanie zapewnić bezpieczne korzystanie z sieci.

Zanim zbadaliśmy, jak dodać te nagłówki, najpierw zrobiliśmy krok wstecz, aby zobaczyć, gdzie jesteśmy. Po uruchomieniu adresu URL naszej aplikacji internetowej przez witrynę skanującą nagłówki zabezpieczeń , nie dziwiło, że otrzymaliśmy ocenę negatywną, ale zobaczyliśmy przydatną listę nagłówków, do których warto się przyjrzeć, jak pokazano poniżej.

Jak widać, było wiele do zrobienia. Zbadaliśmy, jak skonfigurować nasze zasoby AWS S3 i CloudFront, aby odpowiadały za pomocą nagłówków bezpieczeństwa, aby złagodzić wspomniane zagrożenia i luki w zabezpieczeniach.

Na wysokim poziomie możemy to osiągnąć, tworząc funkcję Lambda@Edge, która zmienia nagłówki odpowiedzi pochodzenia, aby dołączyć żądane nagłówki zabezpieczeń, zanim pliki aplikacji internetowej powrócą do przeglądarki użytkownika.

Strategia polega na tym, aby najpierw przetestować ręczne podłączanie za pomocą konsoli AWS. Następnie umieścimy te konfiguracje w Terraform, aby zapisać tę część infrastruktury w kodzie do przyszłego odniesienia i udostępniania innym zespołom i aplikacjom.

Jakie nagłówki bezpieczeństwa chcielibyśmy dodać?

W ramach zaleceń naszego zespołu ds. bezpieczeństwa produktów otrzymaliśmy zadanie dodania nagłówków zabezpieczeń, takich jak „Strict-Transport-Security” i „X-Frame-Options”. Zalecamy również zapoznanie się z zasobami, takimi jak Ścieżka MDN Web Security , aby przyspieszyć. Oto krótkie podsumowanie nagłówków zabezpieczeń, które możesz zastosować do swoich aplikacji internetowych.

Ścisłe bezpieczeństwo transportu (HSTS)

Ma to na celu dostarczenie przeglądarce wskazówek dotyczących dostępu do aplikacji internetowej za pośrednictwem protokołu HTTPS, a nie HTTP.

Polityka bezpieczeństwa treści (CSP)

Ma to na celu ustawienie wyraźnych list dozwolonych dla rodzaju zasobów, które ładujesz lub łączysz w swojej aplikacji internetowej, takich jak skrypty, obrazy, style, czcionki, żądania sieciowe i ramki iframe. To było dla nas najtrudniejsze do skonfigurowania, ponieważ mieliśmy skrypty, obrazy, style i punkty końcowe interfejsu API innych firm, które musieliśmy wyraźnie zarejestrować w tych zasadach.

Wskazówka: użyj nagłówka Content-Security-Policy-Report-Only , aby ułatwić testowanie w określonych środowiskach. Jeśli określone zasoby naruszyły zasady, zaobserwowaliśmy pomocne dane wyjściowe konsoli zawierające zasoby, które musieliśmy zezwolić w naszych zasadach.

Jeśli chcesz uniknąć zabawnego wpadki z pustymi ekranami i niepowodzeniem ładowania aplikacji internetowych, zdecydowanie zalecamy najpierw poeksperymentować ze swoimi zasadami w trybie tylko raportów i przeprowadzić dokładne testy, zanim poczujesz się na tyle pewnie, aby wdrożyć te zasady zabezpieczeń w środowisku produkcyjnym.

X-Content-Type-Options

Ma to na celu utrzymanie i ładowanie zasobów z poprawnymi typami MIME na Twojej stronie internetowej.

X-Frame-Opcje

Ma to na celu zapewnienie reguł dotyczących potencjalnego ładowania aplikacji internetowej w elemencie iframe.

X-XSS-Ochrona

Uniemożliwia to ładowanie stron, jeśli w niektórych przeglądarkach zostanie wykryty atak XSS (cross-site scripting).

Zasady dotyczące polecających

Zarządza to sposobem, w jaki nagłówek „Referrer” z informacjami o pochodzeniu żądania jest przekazywany podczas podążania za linkami do zewnętrznych witryn lub zasobów.

Mając na uwadze te nagłówki zabezpieczeń, wróćmy do tego, jak dzisiaj skonfigurowaliśmy nasze dystrybucje CloudFront i jak funkcje Lambda@Edge pomogą nam osiągnąć nasz cel.

Używanie Lambda@Edge z naszymi dystrybucjami CloudFront

Dla naszych dystrybucji CloudFront ustawiamy takie rzeczy jak:

    • Certyfikaty SSL dla domen do dołączenia na górze adresu URL CloudFront, np. https://app.sendgrid.com
    • Początki wiadra S3
    • Grupy pochodzenia z zasobnikami podstawowymi i replikami do automatycznego przełączania awaryjnego
    • Zachowania w pamięci podręcznej

W szczególności te zachowania pamięci podręcznej pozwalają nam kontrolować, jak długo chcemy, aby odpowiedzi dla określonych typów ścieżek i plików były przechowywane w pamięci podręcznej na serwerach brzegowych na całym świecie. Ponadto zachowanie pamięci podręcznej zapewnia nam również sposób na wyzwalanie funkcji AWS Lambda w odpowiedzi na różne zdarzenia, takie jak żądania pochodzenia i odpowiedzi dotyczące pochodzenia. Możesz myśleć o funkcjach AWS Lambda jako o określonym kodzie, który definiujesz, który zostanie uruchomiony w odpowiedzi na określone zdarzenie.

W naszym przypadku możemy zmienić nagłówki odpowiedzi pochodzenia, zanim zostaną zbuforowane przez serwery brzegowe. Nasza funkcja Lambda@Edge doda niestandardowe nagłówki zabezpieczeń do odpowiedzi pochodzenia, zanim w końcu powróci ona z powrotem do serwera brzegowego i zanim użytkownik końcowy otrzyma pliki JavaScript, CSS i HTML z tymi nagłówkami.

Wzorowaliśmy nasze podejście na tym poście na blogu AWS i rozszerzyliśmy je, aby ułatwić wprowadzanie zmian w określonej Polityce bezpieczeństwa treści. Możesz modelować swoją funkcję Lambda@Edge na podstawie sposobu, w jaki ustawiliśmy to w generowaniu list dla skryptu, stylu i źródeł połączeń. Ta funkcja skutecznie modyfikuje nagłówki odpowiedzi pochodzenia CloudFront i dołącza każdy nagłówek zabezpieczeń z określonymi wartościami do odpowiedzi przed zwróceniem, wywołując funkcję wywołania zwrotnego podaną, jak pokazano poniżej.

Jak testujemy tę funkcję Lambda@Edge?

Zanim oficjalnie zmienisz sposób zwracania zasobów za pomocą nagłówków zabezpieczeń, powinieneś sprawdzić, czy funkcja działa po ręcznym skonfigurowaniu wszystkiego za pomocą konsoli AWS. Niezwykle ważne jest, aby aplikacje internetowe mogły ładować się i działać poprawnie z nagłówkami bezpieczeństwa dodanymi do odpowiedzi sieciowych. Ostatnią rzeczą, którą chcesz usłyszeć, jest nieoczekiwana awaria spowodowana nagłówkami zabezpieczeń, więc przetestuj je dokładnie w swoich środowiskach programistycznych.

Ważne jest również, aby wiedzieć, co dokładnie będziesz później pisać w kodzie Terraform, aby zapisać tę konfigurację w swojej bazie kodu. Jeśli nie wiesz o Terraform, zapewnia to sposób na pisanie i zarządzanie infrastrukturą chmury za pomocą kodu.

Porada: Zapoznaj się z dokumentacją Terraform , aby sprawdzić, czy może ona pomóc w utrzymaniu złożonych konfiguracji bez konieczności zapamiętywania wszystkich kroków wykonanych w konsolach w chmurze.

Jak zacząć korzystać z konsoli AWS

Zacznijmy od ręcznego konfigurowania rzeczy za pomocą konsoli AWS.

  1. Najpierw musisz utworzyć funkcję Lambda@Edge w regionie „us-east-1”. Przechodząc do strony usług Lambda, klikniemy „Utwórz funkcję” i nazwijmy ją mniej więcej w stylu „testSecurityHeaders1”.

2. Możesz użyć istniejącej roli z uprawnieniami do uruchamiania funkcji na serwerach brzegowych lub możesz użyć jednego z ich szablonów zasad ról, takich jak „Basic Lambda@Edge Permissions…” i nazwij go „lambdaedgeroletest”.

3. Po utworzeniu testowej funkcji Lambda i roli, powinieneś zobaczyć coś takiego, gdzie zauważysz przycisk „Dodaj wyzwalacz” dla funkcji. W tym miejscu ostatecznie skojarzysz Lambdę z zachowaniem pamięci podręcznej dystrybucji CloudFront wyzwolonym w zdarzeniu odpowiedzi pochodzenia.

4. Następnie musisz edytować kod funkcji za pomocą kodu nagłówków bezpieczeństwa, który stworzyliśmy wcześniej i nacisnąć „Zapisz”.

5. Po zapisaniu kodu funkcji przetestujmy, czy twoja funkcja Lambda w ogóle działa, przewijając do góry i naciskając przycisk „Test”. Utworzysz zdarzenie testowe o nazwie „samplecloudfrontresponse” przy użyciu szablonu zdarzenia „cloudfront-modify-response-header”, aby zasymulować rzeczywiste zdarzenie odpowiedzi pochodzenia CloudFront i zobaczyć, jak działa w stosunku do niego Twoja funkcja.

Zauważysz takie rzeczy, jak obiekt nagłówków „cf.response”, który zmodyfikuje kod funkcji Lambda.

6. Po utworzeniu zdarzenia testowego ponownie klikniesz przycisk „Test” i zobaczysz, jak działa na nim funkcja Lambda. Powinien działać pomyślnie z dziennikami wyświetlającymi wynikową odpowiedź z dodanymi nagłówkami bezpieczeństwa, takimi jak ten.

Świetnie, funkcja Lambda wygląda na to, że poprawnie dołączyła nagłówki bezpieczeństwa do odpowiedzi!

7. Wróćmy do obszaru „Projektant” i kliknij przycisk „Dodaj wyzwalacz”, aby powiązać funkcję Lambda z zachowaniem pamięci podręcznej dystrybucji CloudFront w zdarzeniu odpowiedzi pochodzenia. Upewnij się, że wybrałeś wyzwalacz „CloudFront” i kliknij przycisk „Wdróż w Lambda@Edge”.

8. Następnie wybierz dystrybucję CloudFront (w naszym przykładzie wyczyściliśmy tutaj dane wejściowe ze względów bezpieczeństwa) i zachowanie pamięci podręcznej, aby ją powiązać.

Następnie wybierasz zachowanie pamięci podręcznej „*” i wybierasz zdarzenie „Origin response”, aby dopasować wszystkie ścieżki żądań do Twojej dystrybucji CloudFront i upewnić się, że funkcja Lambda zawsze działa dla wszystkich odpowiedzi pochodzenia.

Następnie odznaczasz potwierdzenie przed kliknięciem „Wdróż”, aby oficjalnie wdrożyć funkcję Lambda.

9. Po pomyślnym powiązaniu funkcji Lambda ze wszystkimi zachowaniami pamięci podręcznej odpowiedniej dystrybucji CloudFront, powinieneś zobaczyć coś podobnego w obszarze „Projektant” dashboardu Lambda, gdzie możesz zobaczyć wyzwalacze CloudFront i mieć możliwość ich przeglądania lub usuwania.

Wprowadzanie zmian w kodzie Lambda

Zawsze, gdy zajdzie potrzeba wprowadzenia zmian w kodzie Lambda, zalecamy:

    1. Opublikuj nową wersję za pomocą menu rozwijanego „Działania”
    2. Usuń wyzwalacze w starszej wersji (możesz kliknąć menu „Kwalifikatory”, aby zobaczyć wszystkie wersje swojej Lambdy)
    3. Powiąż wyzwalacze z najnowszym numerem wersji, który ostatnio opublikowałeś

Po wdrożeniu Lambdy po raz pierwszy lub po opublikowaniu nowej wersji Lambdy i powiązaniu wyzwalaczy z nowszą wersją Lambdy, możesz nie widzieć nagłówków bezpieczeństwa od razu w odpowiedziach dla Twojej aplikacji internetowej. Wynika to z tego, jak serwery brzegowe w CloudFront buforują odpowiedzi. W zależności od tego, jak długo ustawisz czas życia w zachowaniach pamięci podręcznej, może być konieczne chwilę poczekania, aby zobaczyć nowe nagłówki zabezpieczeń, chyba że unieważnisz pamięć podręczną w danej dystrybucji CloudFront.

Po ponownym wdrożeniu zmian w funkcji Lambda wyczyszczenie pamięci podręcznej często zajmuje trochę czasu (w zależności od ustawień pamięci podręcznej CloudFront), zanim odpowiedzi będą miały najnowsze poprawki w nagłówkach zabezpieczeń.

Wskazówka: aby uniknąć częstego odświeżania strony lub siedzenia niepewnego, czy Twoje zmiany zadziałały, uruchom unieważnienie pamięci podręcznej CloudFront, aby przyspieszyć proces czyszczenia pamięci podręcznej, aby można było zobaczyć zaktualizowane nagłówki zabezpieczeń.

Przejdź do strony CloudFront Services, poczekaj na wdrożenie statusu dystrybucji CloudFront, co oznacza, że ​​wszystkie skojarzenia lambda są kompletne i wdrożone, a następnie przejdź do zakładki „Invalidations”. Kliknij „Utwórz unieważnienie” i umieść „/*” jako ścieżkę obiektu, aby unieważnić wszystkie rzeczy w pamięci podręcznej i naciśnij „Unieważnij”. Nie powinno to zająć zbyt dużo czasu, a po zakończeniu odświeżenia aplikacji internetowej powinny zobaczyć najnowsze zmiany nagłówków zabezpieczeń.

Podczas iteracji nagłówków zabezpieczeń na podstawie stwierdzonych naruszeń lub błędów w aplikacji internetowej możesz powtórzyć ten proces:

    • Publikowanie nowej wersji funkcji Lambda
    • Usuwanie wyzwalaczy w starej wersji Lambda
    • Kojarzenie wyzwalaczy w nowej wersji
    • Pamięć podręczna unieważniająca Twoją dystrybucję CloudFront
    • Testowanie Twojej aplikacji internetowej
    • Powtarzając, aż poczujesz się pewnie i bezpiecznie, wszystko działa zgodnie z oczekiwaniami, bez pustych stron, nieudanych żądań API lub błędów bezpieczeństwa konsoli

Gdy wszystko jest stabilne, możesz opcjonalnie przejść do Terraformingu, co właśnie zrobiłeś ręcznie w konfiguracjach kodu, zakładając, że masz Terraform zintegrowany z kontami AWS. Nie będziemy omawiać, jak skonfigurować Terraform od początku, ale pokażemy fragmenty tego, jak będzie wyglądał kod Terraform.

Terraformowanie Lambda@Edge wyzwolonego przez naszą dystrybucję CloudFront

Po wykonaniu iteracji funkcji Lambda@Edge dla nagłówków bezpieczeństwa w regionie „us-east-1”, chcieliśmy dodać to do naszej bazy kodu Terraform w celu utrzymania kodu i kontroli wersji w przyszłości.

W przypadku wszystkich zachowań pamięci podręcznej, które już zaimplementowaliśmy, musieliśmy powiązać zachowanie pamięci podręcznej z funkcją Lambda@Edge, którą wyzwalało zdarzenie odpowiedzi pochodzenia.

Poniższe kroki zakładają, że masz już większość dystrybucji CloudFront i zasobników S3 skonfigurowanych za pomocą Terraform. Skoncentrujemy się na głównych modułach i właściwościach związanych z Lambda@Edge i dodamy wyzwalacz do zachowań pamięci podręcznej dystrybucji CloudFront. Nie będziemy omawiać sposobu konfigurowania zasobników S3 i innych ustawień dystrybucji CloudFront od podstaw za pośrednictwem Terraform, ale mamy nadzieję, że zobaczysz poziom wysiłku, aby wykonać to samodzielnie.

Obecnie dzielimy nasze zasoby AWS na oddzielne foldery modułów i przekazujemy zmienne do tych modułów, aby zapewnić elastyczność w naszej konfiguracji. Mamy folder apply z podfolderem development i production , a każdy z nich ma swój własny plik main.tf , w którym wywołujemy te moduły z określonymi zmiennymi wejściowymi w celu utworzenia instancji lub modyfikacji naszych zasobów AWS.

Każdy z tych podfolderów ma również folder lambdas , w którym przechowujemy nasz kod Lambda, taki jak plik security_headers_lambda.js . security_headers_lambda.js zawiera ten sam kod, którego używaliśmy w naszej funkcji Lambda podczas ręcznego testowania, z wyjątkiem tego, że zapisujemy go również w naszej bazie kodu, abyśmy mogli go skompresować i przesłać przez Terraform.

1. Najpierw potrzebujemy modułu wielokrotnego użytku do spakowania naszego pliku Lambda, zanim zostanie załadowany i opublikowany jako kolejna wersja naszej funkcji Lambda@Edge. Pobiera to ścieżkę do naszego folderu Lambda, w którym znajduje się ewentualna funkcja Node.js Lambda.

2. Następnie dodajemy do naszego istniejącego modułu CloudFront, który opakowuje zasobniki S3, polityki i zasoby dystrybucji CloudFront, tworząc również zasób Lambda zbudowany ze spakowanego pliku Lambda. Ponieważ dane wyjściowe modułu Lambda zip są przekazywane jako zmienne do modułu CloudFront w celu skonfigurowania zasobu Lambda, musimy określić region dostawcy AWS jako „us-east-1” i z działającą polityką ról taką jak ta.

3. W module CloudFront kojarzymy tę funkcję Lambda@Edge z zachowaniem pamięci podręcznej dystrybucji CloudFront, jak pokazano poniżej.

4. Na koniec, umieszczając to wszystko razem w naszym pliku main.tf folderu apply/development lub apply/production , wywołujemy wszystkie te moduły i umieszczamy odpowiednie dane wyjściowe jako zmienne w naszym module CloudFront, jak pokazano tutaj.

Te poprawki konfiguracji zasadniczo dotyczą ręcznych kroków, które wykonaliśmy w poprzedniej sekcji, aby zaktualizować kod Lambda i powiązać nowszą wersję z zachowaniami pamięci podręcznej CloudFront i wyzwalaczami zdarzeń odpowiedzi pochodzenia. Hurra! Nie musisz przechodzić ani zapamiętywać kroków Konsoli AWS, o ile zastosujemy te zmiany do naszych zasobów.

Jak możemy to bezpiecznie wdrożyć w różnych środowiskach?

Kiedy po raz pierwszy powiązaliśmy naszą funkcję Lambda@Edge z naszą testową dystrybucją CloudFront, szybko zauważyliśmy, że nasza aplikacja internetowa nie ładuje się już poprawnie. Wynikało to głównie z tego, jak zaimplementowaliśmy nasz nagłówek Content-Security-Policy i jak nie obejmował on wszystkich zasobów, które załadowaliśmy do naszej aplikacji. Inne nagłówki bezpieczeństwa stwarzały mniejsze ryzyko w zakresie blokowania ładowania naszej aplikacji. W przyszłości skupimy się na wprowadzaniu nagłówków zabezpieczeń z myślą o dalszych iteracjach, aby dostroić nagłówek Content-Security-Policy.

Jak wspomniano wcześniej, odkryliśmy, w jaki sposób możemy zamiast tego wykorzystać nagłówek Content-Security-Policy-Report-Only , aby zminimalizować ryzyko, gdy gromadzimy więcej domen zasobów do dodania w każdej z naszych zasad.

W tym trybie tylko do raportowania zasady będą nadal działać w przeglądarce i będą wyświetlać komunikaty o błędach konsoli dotyczące wszelkich naruszeń zasad. Jednak nie zablokuje to całkowicie tych skryptów i źródeł, więc nasza aplikacja internetowa może nadal działać normalnie. Od nas zależy, czy będziemy kontynuować przeglądanie całej aplikacji internetowej, aby mieć pewność, że nie pominiemy żadnych ważnych źródeł w naszych zasadach, w przeciwnym razie wpłynie to negatywnie na naszych klientów i zespół wsparcia.

Dla każdego środowiska możesz wdrożyć nagłówki bezpieczeństwa Lambda, takie jak:

    • Opublikuj zmiany w Lambdzie ręcznie lub za pomocą planu Terraform i najpierw zastosuj zmiany w środowisku za pomocą innych nagłówków zabezpieczeń i nagłówka Content-Security-Policy-Report-Only.
    • Poczekaj, aż stan dystrybucji CloudFront zostanie w pełni wdrożony z Lambda skojarzoną z zachowaniami pamięci podręcznej.
    • Wykonaj unieważnienie pamięci podręcznej w swojej dystrybucji CloudFront, jeśli poprzednie nagłówki zabezpieczeń nadal są wyświetlane lub trwa zbyt długo, zanim bieżące zmiany pojawią się w przeglądarce.
    • Odwiedzaj i przeglądaj strony swojej aplikacji internetowej z otwartymi narzędziami dla programistów, skanując konsolę w poszukiwaniu komunikatów o błędach konsoli „Tylko zgłoś…”, aby poprawić nagłówek Content-Security-Policy.
    • Wprowadź zmiany w swoim kodzie Lambda, aby uwzględnić te zgłoszone naruszenia.
    • Powtarzaj od pierwszego kroku, aż poczujesz się wystarczająco pewnie, aby zmienić nagłówek z Content-Security-Policy-Report-Only na Content-Security-Policy, co oznacza, że ​​środowisko będzie to egzekwować.

Poprawa naszych nagłówków bezpieczeństwa

Po pomyślnym zastosowaniu zmian Terraform w naszych środowiskach i unieważnieniu pamięci podręcznych CloudFront, odświeżyliśmy strony w naszej aplikacji internetowej. Utrzymywaliśmy otwarte narzędzia programistyczne, aby zobaczyć nagłówki zabezpieczeń, takie jak HSTS, CSP i inne w naszych odpowiedziach sieciowych, takie jak nagłówki zabezpieczeń pokazane poniżej.

Uruchomiliśmy również naszą aplikację internetową przez raport skanowania nagłówków bezpieczeństwa, taki jak ten na tej stronie . W rezultacie byliśmy świadkami znacznych ulepszeń (ocena A!) w stosunku do wcześniej niezadowalającej oceny, a podobne ulepszenia można osiągnąć po zmianie konfiguracji S3/CloudFront w celu wprowadzenia nagłówków zabezpieczeń.

Idąc dalej z nagłówkami bezpieczeństwa

Po ręcznym skonfigurowaniu nagłówków zabezpieczeń za pomocą konsoli AWS lub pomyślnym Terraformowaniu rozwiązania i zastosowaniu zmian w każdym ze swoich środowisk, masz teraz doskonałą podstawę do dalszej iteracji i ulepszania istniejących nagłówków zabezpieczeń w przyszłości.

W zależności od ewolucji aplikacji internetowej może być konieczne uszczegółowienie nagłówka Content-Security-Policy pod względem zasobów dozwolonych w celu zwiększenia bezpieczeństwa. Lub może być konieczne dodanie nowego nagłówka całkowicie w innym celu lub w celu wypełnienia innej luki w zabezpieczeniach.

Dzięki tym przyszłym zmianom w nagłówkach bezpieczeństwa w funkcjach Lambda@Edge, możesz zastosować podobne strategie wydawania dla każdego środowiska, aby upewnić się, że Twoje aplikacje internetowe są zabezpieczone przed złośliwymi atakami w sieci i nadal działają, a Twoi użytkownicy nigdy nie zauważą różnicy.

Więcej artykułów napisanych przez Alfreda Lucero można znaleźć na jego stronie autora bloga: https://sendgrid.com/blog/author/alfred/