Ochrona portalu przed DDoS: cache bez wycieku danych

Ochronę publicznego portalu przed DDoS zacznij od oddzielenia informacji dostępnych dla wszystkich od działań i danych dotyczących jednej osoby. Sprawdzone publiczne odpowiedzi możesz udostępniać niewielkim kosztem przez sieć dostarczania treści, czyli CDN. Wyłącz ze współdzielonej pamięci podręcznej odpowiedzi prywatne i te zawierające dane dostępowe. Potem sprawdź, czy przy włączonych zabezpieczeniach kandydaci i badacze bezpieczeństwa nadal mogą wysyłać zgłoszenia.

Samo wczytanie strony z ofertami pracy nie wystarczy, żeby rekrutacja działała. Kandydat musi jeszcze otworzyć prywatny link, przesłać plik i dostać potwierdzenie, które odpowiada faktycznemu wynikowi. Badacz bezpieczeństwa potrzebuje instrukcji i możliwości poufnego zgłoszenia podatności. Jeśli ochronisz stronę wejściową, ale zablokujesz dalsze kroki, osoby, którym chcesz pomóc, nie załatwią swojej sprawy.

Poniżej proponujemy przegląd techniczny dla niewielkiego zespołu. Łączy wnioski z niedawno opisanego incydentu z ćwiczeniem, które możesz dostosować do własnego systemu. Nie jest certyfikatem odporności na ataki ani gwarancją dostępności konkretnej konfiguracji hostingu.

Czego Read the Docs nauczyło się z żądań omijających cache?

Nawet pozornie proste żądania mogą zużywać ograniczone zasoby aplikacji. Sprawdź najpierw ścieżki, które docierają do serwera źródłowego, czyli tego, na którym działa aplikacja. Nie zakładaj, że całe obciążenie pochodzi z popularnych stron.

Read the Docs opublikowało opis incydentu 8 września 2026 r. Sam atak przypadł na okres od połowy do końca czerwca i trwał blisko dziesięć dni. Dostawca podał, że w szczycie otrzymywał ponad 5,5 mln żądań na minutę. Zmieniały się cechy żądań, a ruch celował w odpowiedzi nieobecne w pamięci podręcznej. Początkowo tymczasowe przekierowania trafiały do backendu w Pythonie; zespół przeniósł ich obsługę do sieci brzegowej. Żądania do kolejnych nieistniejących ścieżek również wymuszały kosztowne odwołania do serwera. Zastosowano m.in. selektywną weryfikację ruchu, ponieważ sprawdzanie w ten sposób każdego czytelnika zakłóciłoby integracje.

To obserwacje Read the Docs, a nie opis sytuacji w Kit czy twojej firmie. Twojemu zespołowi przyda się bardziej konkretne pytanie: które pozornie tanie żądania nadal angażują aplikację?

Zacznij od fikcyjnego portalu

Na potrzeby ćwiczenia wyobraź sobie niewielką firmę programistyczną, która prowadzi publiczny portal kariery i program ujawniania podatności. Osoba szukająca pracy czyta opis stanowiska bez logowania. Kandydat korzysta z prywatnego linku do swojej aplikacji. Badacz czyta politykę bezpieczeństwa, a potem wysyła szczegóły, które muszą pozostać poufne.

Daj rekruterowi, osobie odpowiedzialnej za bezpieczeństwo i inżynierowi pustą kartkę. Poproś każdego o rozpisanie swojej ścieżki: od wejścia do potwierdzenia zgłoszenia. Uwzględnij stare zakładki i linki we wcześniej wysłanych wiadomościach. To propozycja warsztatu, nie opis incydentu u klienta.

Zaznaczcie teraz kroki wymagające serwera aplikacji. Przekierowanie może odczytywać dane z bazy. Strona błędu może korzystać z układu dopasowanego do użytkownika. Formularz może zawierać token. Znajdźcie te zależności, zanim presja podczas awarii skłoni kogoś do zmiany zasad cache w całym serwisie.

Jeśli chcesz szerzej ustalić, kto utrzymuje usługę, przeczytaj nasz tekst o własnym hostingu i odpowiedzialności zespołu. W tym ćwiczeniu skup się na napływającym ruchu i zawartości odpowiedzi.

Jak rozpoznać odpowiedzi, które naprawdę są publiczne?

Oceń całą odpowiedź, razem z nagłówkami i wariantami. Adres wyglądający na publiczny nie dowodzi, że każdy dostaje tę samą treść ani że współdzielona pamięć podręczna może ją bezpiecznie przekazywać kolejnym osobom.

Standard buforowania HTTP, RFC 9111, rozróżnia trzy często mylone dyrektywy. no-store zabrania przechowywania odpowiedzi w pamięci podręcznej. private wyklucza przechowywanie we współdzielonym cache. no-cache pozwala zapisać odpowiedź, ale wymaga jej walidacji przed ponownym użyciem. Sam nagłówek żądania Authorization też nie zapewnia pełnej ochrony: jawne dyrektywy odpowiedzi mogą zezwolić na jej współdzielenie. Dlatego skopiowanie znajomej nazwy nagłówka nie wystarczy.

Sporządź wykaz odpowiedzi

Poniższa tabela może posłużyć jako arkusz przeglądu. Pomaga ocenić rozwiązanie techniczne, nie jest standardem zgodności. Dla każdego wiersza wyznacz osobę, która zbierze dowody, i drugą, która sprawdzi wnioski.

Przejdź przez rzeczywiste scenariusze na kontach testowych i fikcyjnych danych. Porównaj dwa konta firmowe, dwa języki oraz wizytę osoby zalogowanej i anonimowej, o ile system obsługuje te warianty. Dopisz inne stany dostępne w twoim produkcie. Ta lista nie wyczerpuje wszystkich możliwości.

Sprawdź również drobne elementy strony. Obok ogólnego opisu stanowiska może pojawić się imię kandydata lub token formularza. To, że główna treść jest publiczna, nie oznacza, że można współdzielić całą odpowiedź. Rozważ oddzielenie publicznych danych od prywatnego interfejsu, zamiast uznawać całą stronę za nieszkodliwą.

Zachowaj różnice, które zmieniają znaczenie

Klucz cache określa, które żądania dotyczą tej samej odpowiedzi. Dokumentacja kluczy cache Cloudflare opisuje, jak pomijanie parametrów zapytania może połączyć żądania o różnych wartościach tych parametrów. Oceń tę opcję, zanim włączysz ją w całym portalu.

W ćwiczeniu dopisz znaczenie każdego składnika klucza. Host może wskazywać klienta. Język może zmieniać instrukcje. Filtr może wybierać inne stanowisko. Dane dostępowe mogą decydować o tym, kto ma prawo zobaczyć odpowiedź. Jeśli nie potrafisz uzasadnić, dlaczego daną różnicę można bezpiecznie pominąć, zachowaj ją do czasu wyjaśnienia.

Zachowaj dowody porównania po usunięciu danych wrażliwych. Zapisz zbadane ścieżki, sprawdzone stany i niewyjaśnione kwestie. Sam zrzut ekranu nie potwierdza zasad cache. Nie umieszczaj w dokumencie prawdziwych linków kandydatów ani treści poufnych zgłoszeń.

Jak chronić przekierowania i strony błędów?

Przekierowania i odpowiedzi błędów wymagają osobnej oceny prywatności i aktualności. Kod statusu mówi, co się wydarzyło. Nie rozstrzyga, czy odpowiedź można bezpiecznie współdzielić.

W fikcyjnej firmie zacznij od starego adresu portalu kariery. Jeśli adres docelowy jest stały i publiczny, sprawdź, czy przekierowanie da się obsłużyć przed serwerem aplikacji. Następnie wypróbuj stary link kandydata. Jego cel może zależeć od uwierzytelnienia lub stanu aplikacji kandydata. Wymaga więc osobnej decyzji, nawet gdy oba przekierowania mają ten sam kod statusu.

Podobnie podejdź do brakujących stron. Krótkie przechowywanie publicznej odpowiedzi 404 może ograniczyć powtarzaną pracę dla tego samego nieistniejącego zasobu. Nie rozwiąże jednak problemu nieograniczonej liczby nowych, nieistniejących ścieżek: każda może wywołać kolejne chybienie cache. Innych zasad wymaga też odpowiedź, która ukrywa prywatny zasób przed osobą bez uprawnień, a nie informuje o braku publicznej strony.

Ustal, kto odpowiada za aktualność informacji

Cache rodzi pytanie dotyczące działania produktu: jak długo można jeszcze pokazywać wczorajszą odpowiedź? Ustal dopuszczalne opóźnienie dla każdego publicznego zasobu, zamiast wybierać jeden wygodny czas ważności dla całej witryny.

Poproś rekrutera o opisanie skutków wyświetlania zamkniętego ogłoszenia jako otwartego. Osoba odpowiedzialna za bezpieczeństwo powinna wskazać zmiany polityki wymagające pilnej publikacji. Nowy adres kontaktowy może wymagać innego podejścia niż drobna korekta tekstu. To decyzje do podjęcia podczas przeglądu, nie uniwersalne zalecenia dotyczące czasu ważności.

Dokumentacja zasad cache Cloudflare wyjaśnia zależności między nagłówkami serwera źródłowego, regułami nadpisującymi, plikami cookie i udostępnianiem nieaktualnych odpowiedzi. Sprawdź faktyczną odpowiedź dostarczaną przez wdrożoną sieć brzegową. Deklaracja nagłówka w kodzie aplikacji nie dowodzi, co rzeczywiście otrzymuje odwiedzający.

Przećwicz zmianę stanu na fikcyjnym ogłoszeniu. Odczytaj je publiczną ścieżką, zamknij i sprawdź, kiedy zmieni się publiczna odpowiedź. Następnie spróbuj wykonać odpowiednią czynność ze starszej wersji strony. Aplikacja powinna decydować o przyjęciu na podstawie bieżącego stanu. Opis zapisany w cache nie może być zgodą na dalsze działanie.

Aktualizuj instrukcje zgłaszania podatności

Polityka zgłoszeń wymaga osobnej kontroli aktualności. RFC 9116 definiuje security.txt, w tym pole Expires i dane kontaktowe do zgłaszania podatności. Po upływie terminu ważności nie powinno się korzystać z tych informacji. Można podać kontakt przez stronę WWW, e-mail lub telefon, ale plik służy zgłaszaniu podatności, a nie jako ogólny kontakt do obsługi incydentów.

W ramach ćwiczenia sprawdź każdą opublikowaną drogę zgłoszenia. Użyj nieszkodliwych treści i uzgodnionej procedury testowej. Potwierdź, kto otrzymuje zgłoszenie i skąd nadawca wie, co się z nim stało. Szybko wczytująca się polityka jest przydatna wtedy, gdy jej instrukcje prowadzą do utrzymywanego kanału kontaktu.

Jeśli dopiero organizujesz ten proces, zacznij od poradnika dotyczącego programu ujawniania podatności (VDP). Oddziel publiczne instrukcje od prywatnego zgłoszenia, które pomagają wysłać.

Jak nie dopuścić, żeby weryfikacja ruchu blokowała zgłoszenia?

Dopasuj reguły ochrony do klientów i działań, których dotyczą. Przeglądarka otwierająca stronę i integracja wysyłająca dane w określonym formacie mogą zupełnie inaczej zareagować na to samo żądanie weryfikacji.

Dokumentacja stron weryfikacji Cloudflare wyjaśnia, że zwracają one HTML. Klient oczekujący JSON może więc dostać bezużyteczną dla niego odpowiedź. Wstępna weryfikacja w przeglądarce może pomóc w odpowiednich scenariuszach, ale nie jest uniwersalnym rozwiązaniem dla API ani webhooków.

Przygotowując test, wypisz żądania wykonywane po otwarciu strony. Uwzględnij wysyłanie zgłoszenia i pliku, uwierzytelnianie oraz wywołania zwrotne używane przez integrację. Przy każdym zapisz oczekiwany format odpowiedzi. Potem przejdź cały proces z włączoną właściwą regułą ochrony w odpowiednim środowisku testowym.

Nie kończ testu po pomyślnym przejściu pierwszej weryfikacji w przeglądarce. Wyślij formularz, otwórz kolejny link i sprawdź zapisany wynik. Gdy przesyłanie pliku się nie powiedzie, zbadaj format odpowiedzi, zanim uznasz, że problem tkwi w pliku. Wywołanie zwrotne sprawdź jako osobnego klienta. Udany test w przeglądarce nie potwierdza, że ono również działa.

Sprawdź błędne blokady z osobami, których dotyczą

Zapytaj rekrutera i osobę odpowiedzialną za bezpieczeństwo, co zobaczy niesłusznie zablokowany użytkownik. Czy będzie wiedzieć, czy coś dotarło do systemu? Czy wie, co zrobić dalej? Czy po ponowieniu próby będzie miał wątpliwości, czy zgłoszenie już istnieje?

Sprawdzaj te stany na fikcyjnych zgłoszeniach, żeby nie zaskakiwać zespołu nowymi wpisami w kolejkach produkcyjnych. Uzgodnij odpowiednią dla organizacji alternatywną drogę kontaktu. Poufne szczegóły nie powinny trafiać na publiczną stronę statusu. Nie wyświetlaj na stronie awaryjnej potwierdzenia wysłania, jeśli system nie przyjął zgłoszenia.

Takiej samej oceny wymagają limity żądań. Cloudflare opisuje opcje rate limiting uwzględniające NAT oraz ograniczenia związane z plikami cookie; dostępność funkcji zależy też od planu. Z kolei dokumentacja zliczania żądań wyjaśnia, że liczniki nie są współdzielone globalnie przez wszystkie centra danych. Reguła w sieci brzegowej nie stanowi więc ścisłego globalnego limitu transakcji.

Podczas przeglądu nie wybieraj wartości limitu tylko dlatego, że stosuje ją inna firma. Obserwuj prawidłowy przebieg procesu i ustal znaczenie powtarzanych działań. Seria odczytów strony, duży plik i wielokrotne wysłanie formularza mają inne skutki. Zapisz cel reguły oraz wyniki obserwacji, które skłoniłyby cię do jej zmiany.

Jak przetestować cały proces kandydata i badacza?

Sprawdź powodzenie, odmowę i ponowienie działania przez rzeczywiście wdrożone zabezpieczenia. Dostępność oznacza, że uprawniona osoba może wykonać zamierzone zadanie i zrozumieć wynik. Nie wystarczy poprawna odpowiedź strony głównej odnotowana przez monitoring.

Przed większą zmianą zasad cache lub reguł ruchu przeprowadź poniższe ćwiczenie. Użyj fikcyjnych danych, wyznacz osoby odpowiedzialne i jasno ustal, kiedy wycofasz zmianę. To przegląd funkcjonalny; nie zastępuje osobno zaplanowanego testu obciążeniowego.

1. Odczytaj publiczne informacje. Otwórz ogłoszenie lub politykę zwykłą drogą wejścia. Sprawdź firmę, język, aktualny status i dane kontaktowe. Jeśli istnieje stary publiczny link, powtórz test z jego użyciem.
2. Przejdź do części prywatnej. Użyj osobnych tożsamości testowych. Sprawdź, czy każda osoba widzi wyłącznie własne informacje, a anonimowe żądanie nie otrzymuje odpowiedzi przygotowanej dla poprzedniego odwiedzającego.
3. Wykonaj czynność do końca. Wyślij fikcyjną kandydaturę lub zgłoszenie podatności. Jeśli system to obsługuje, dołącz nieszkodliwy plik. Sprawdź przyjęty rekord we właściwym interfejsie wewnętrznym.
4. Wywołaj zwykły błąd. Podaj nieprawidłową wartość pola lub użyj wygasłego linku testowego. Sprawdź, czy wyjaśnienie jest przydatne i nie ujawnia informacji o innej osobie.
5. Zmień stan publicznych informacji. Zamknij fikcyjne ogłoszenie albo zmień testową politykę. Sprawdź aktualność odpowiedzi i ponów odpowiednią czynność ze starszej strony.
6. Sprawdź każdego klienta. Osobno zbadaj żądania przeglądarki i integracji. Zapisz typy treści, przebieg weryfikacji ruchu i to, czy klient potrafi wznowić działanie po błędzie.

Uwzględnij osoby, które korzystają z serwisu bez myszy. Ten obszar opisuje nasza checklist obsługi portalu kandydata klawiaturą. Ekran weryfikacji lub ponowienia działania dodany podczas incydentu zasługuje na taką samą uwagę jak pierwotny formularz.

Ustal warunki wdrożenia zmiany

Jeszcze przed testami uzgodnij, jakie dowody pozwolą wdrożyć zmianę. Dla fikcyjnego zespołu rozsądne kryteria to poprawne informacje publiczne, izolacja odpowiedzi prywatnych, skuteczne wysyłanie prawidłowych zgłoszeń i zgodne z rzeczywistością komunikaty po odrzuceniu działań. Wyznacz osobę odpowiedzialną za usunięcie każdego błędu, zamiast sprowadzać wszystkie wyniki do procentowej dostępności usługi.

Zachowaj krótką notatkę: zmieniona reguła, testowane stany, zaobserwowane wyniki i kroki wycofania zmiany. Tam, gdzie masz odpowiednie dane, porównaj zachowanie sieci brzegowej z zachowaniem aplikacji. Niewyjaśnione kwestie opisuj precyzyjnie: niesprawdzone wywołanie zwrotne to inny problem niż nieudane wysłanie kandydatury.

Powtarzaj odpowiednie testy po zmianie reguły lub procesu. Wielokrotne sprawdzanie niezmienionej strony głównej niewiele daje, jeśli nowa ścieżka przesyłania plików pozostaje nietestowana. Zakres przeglądu powinien wynikać z zakresu zmiany.

Jak Kit oddziela publiczne informacje od prywatnych działań?

Jeden produkt może zawierać publiczne informacje i poufne procesy wymagające różnych zasad. Zanim zdecydujesz o zasadach cache, sprawdź rzeczywistą odpowiedź, nawet jeśli nazwa kontrolera lub ścieżki zawiera słowo „public”.

W kodzie Kit sprawdzonym 10 września odpowiedź JSON dla ogłoszenia przyjmującego kandydatury deklaruje pięć minut ważności w publicznym cache. Odpowiedź security.txt aktywnego programu bezpieczeństwa deklaruje godzinę. To konkretne deklaracje aplikacji, nie pomiary działania wdrożonej sieci CDN ani dostępności wysyłania zgłoszeń.

Proces kandydata działa inaczej. Token magic link służy do odnalezienia kandydata oraz jego aplikacji, rozmów, ofert i powiązanych danych. Publiczna ścieżka HTML ogłoszenia może również odczytać z sesji uprawnienie kandydata. Nie można zatem uznać wszystkich stron dostępnych bez logowania za jednakową publiczną treść.

Kit ogranicza też liczbę wysyłanych zgłoszeń w middleware aplikacji. To jedna warstwa obsługi żądania, nie dowód, że ruch docierający do wcześniejszych warstw nie wyczerpie zasobów. Ten artykuł nie zawiera audytu odpowiedzi produkcyjnych, testu obciążeniowego ani gwarancji ochrony przed DDoS. Zabezpieczenia dotyczące referrera i indeksowania również nie dowodzą, że odpowiedź ma nagłówek Cache-Control: no-store.

Przygotuj taki wykaz odpowiedzi dla własnego portalu. Ogranicz koszt udostępniania sprawdzonych informacji publicznych, ustal osobne zasady dla części prywatnej i sprawdź, czy osoba wysyłająca zgłoszenie może polegać na otrzymanym potwierdzeniu.