Model zagrożeń

Frontmail pozwala wysyłać e-maile prosto z przeglądarki. To wygodne, ale oznacza, że część twojej integracji siedzi w kodzie, który każdy może przeczytać i skopiować. Na tej stronie opisujemy wszystkie znane nam ataki na ten model, to, jak Frontmail się przed nimi broni, co musisz ustawić sam – i otwarcie ryzyko, które zostaje. Jeśli czegoś tu brakuje, napisz na security@frontmail.dev.

Podstawowy model

• Klucz publiczny jest publiczny. Jest w kodzie źródłowym twojej strony. Traktuj go jak nazwę użytkownika, nie jak hasło. Każdy może go skopiować i wywoływać API ze skryptu.
• Nagłówek Origin to nie uwierzytelnianie. Przeglądarki ustawiają go uczciwie, ale skrypt może wysłać dowolną wartość. Dozwolone domeny nie pozwalają innym stronom używać twojego klucza w przeglądarkach ich odwiedzających – zdeterminowanego atakującego jednak nie zatrzymają.
• Naprawdę chroni cię to, czego atakujący nie może zmienić:
  1. szablon – atakujący może wysyłać tylko twoje szablony i wypełniać tylko ich parametry,
  2. CAPTCHA (Turnstile) – każda wysyłka kosztuje go jedno rozwiązanie, jak u człowieka,
  3. limity – na IP, na klucz, na organizację, na odbiorcę oraz twoje kredyty.
• Klucz prywatny jest tajny. Jego miejsce jest wyłącznie na twoim serwerze. Omija dozwolone domeny i CAPTCHA i może czytać historię wiadomości.

Reszta tej strony wynika z tych czterech punktów.

Ataki i obrona

1. Phishing z twojej domeny (najważniejszy)

Atak. Szablon bierze odbiorcę z parametrów – reset hasła, powiadomienie, potwierdzenie zapisu do newslettera. Atakujący kopiuje twój klucz publiczny, wysyła ten szablon ofierze i w reset_url wpisuje własną stronę. E-mail przychodzi z twojej domeny, przechodzi SPF i DKIM, wygląda dokładnie jak twój i prowadzi do atakującego.

Co robi Frontmail. Żądanie z kluczem publicznym do szablonu z dynamicznym odbiorcą dostaje zablokowaną treść:

• CAPTCHA jest obowiązkowa (dynamic_recipient_requires_captcha),
• każdy link musi prowadzić do twoich dozwolonych domen – sprawdzane są linki w atrybutach, CSS, zwykłym tekście (także gołe evil.com/login, które klienty poczty zamieniają w linki) i temacie, łącznie ze sztuczkami typu https://ty.pl@evil.com, odwrotne ukośniki, podobnie wyglądające domeny Unicode czy zakodowane znaki (link_not_allowed),
• adres nadawcy, nazwa nadawcy i Reply-To nie mogą pochodzić z parametrów (dynamic_field_not_allowed),
• żadnych parametrów HTML, parametry tekstowe najwyżej 500 znaków,
• każdy odbiorca dostaje od twojej organizacji najwyżej 5 takich e-maili dziennie (do ustawienia).

Wszystko jest sprawdzane zanim zostanie zużyty kredyt. Automatyczne odpowiedzi są zablokowane w ten sam sposób.

Co robisz ty. Wypełnij Bezpieczeństwo → Dozwolone domeny linków, jeśli twoje linki prowadzą gdzieś poza domenę twojej strony. Skonfiguruj własne klucze Turnstile. Szablony wysyłane tylko przez twój serwer (potwierdzenia zamówień, resety hasła generowane na backendzie) wysyłaj kluczem prywatnym.

Pozostałe ryzyko. Atakujący wciąż może wysłać obcej osobie twój prawdziwy e-mail – np. „Potwierdź zapis do newslettera” z linkiem do twojej strony. Nie ma w nim nic, co atakujący kontroluje, więc to nie phishing, ale może być uciążliwe. Limit na odbiorcę i CAPTCHA utrzymują to na niskim poziomie. Zwykły tekst bez linku (np. „zadzwoń pod ten numer”) w parametrze tekstowym wciąż da się wstawić w ramach 500 znaków – ogranicz więc dynamiczne parametry tekstowe do tego, czego e-mail naprawdę potrzebuje.

2. Spam do twojej własnej skrzynki

Atak. Skrypt zalewa szablon formularza kontaktowego śmieciami.

Co robi Frontmail. Limit na IP (domyślnie 10 żądań / 60 s, IPv6 liczone według sieci /64), limity na klucz i organizację, wykrywanie anomalii, sprawdzanie przeglądarek headless i listy blokad po stronie serwera, opcjonalna CAPTCHA dla każdego szablonu.

Co robisz ty. W publicznych formularzach włącz Wymagaj CAPTCHA. Znane wartości spamowe dodaj do listy blokad.

Pozostałe ryzyko. Bez CAPTCHA cierpliwy atakujący, który zmienia adresy IP, przejdzie przez limity. Z CAPTCHA musi płacić serwisowi rozwiązującemu za każdy e-mail.

3. Wywoływanie API ze skryptu lub fałszywej „aplikacji”

Atak. Atakujący wysyła żądania bez przeglądarki, z podrobionym Origin albo zupełnie bez niego.

Co robi Frontmail. Żądania bez Origin i Referer (typowe dla skryptów) są odrzucane, jeśli nie masz włączonego Zezwól na aplikacje mobilne – także wtedy, gdy lista dozwolonych domen jest pusta. Ze wspólnej mobilnej CAPTCHA Frontmail korzystają tylko organizacje z tą opcją; wszystkie pozostałe muszą przejść przez twój własny widget Turnstile, a jego token musi pochodzić z domeny, z której przyszło żądanie.

Co robisz ty. Zostaw Zezwól na aplikacje mobilne wyłączone, jeśli nie masz aplikacji natywnej. Kod po stronie serwera powinien używać klucza prywatnego.

Pozostałe ryzyko. Podrobiony Origin nadal przechodzi przez listę dozwolonych domen; zatrzymują go CAPTCHA i limity (zobacz punkt 2).

4. Wyczerpanie twoich kredytów lub karty

Atak. Z twoim kluczem publicznym atakujący wysyła tyle e-maili, na ile pozwalają limity, żeby spalić twój limit miesięczny – a gdyby mógł, także debet i automatyczne doładowania.

Co robi Frontmail.

• Ruch z kluczem publicznym nie korzysta z debetu i nie uruchamia automatycznego doładowania, chyba że wyraźnie na to zezwolisz (Płatności → Wydatki z ruchu na kluczu publicznym).
• Kolejka wstrzymanych wiadomości ma górny limit; powyżej niego żądania są odrzucane zamiast trafiać do kolejki, więc śmieci nie zjedzą kredytów, które kupisz później.
• Automatyczne doładowanie ma miesięczny limit liczby i kwoty.

Co robisz ty. Zostaw ustawienia domyślne, używaj CAPTCHA, czytaj e-maile o anomaliach.

Pozostałe ryzyko. Twój zwykły limit miesięczny i pakiety kredytów wciąż mogą zostać zużyte przez śmieci, które przejdą przez CAPTCHA i limity. Kosztuje cię to kredyty, nie dodatkowe pieniądze.

5. Zablokowanie formularza prawdziwym odwiedzającym

Atak. Tani zalew nieprawidłowych żądań wyczerpuje limity twojej organizacji i prawdziwi odwiedzający dostają 429.

Co robi Frontmail. Limity organizacji i wykrywanie anomalii liczą tylko żądania, które przeszły sprawdzenie szablonu i CAPTCHA; wcześniej obowiązuje tylko limit na IP i hojne zabezpieczenie przed zalewem.

Pozostałe ryzyko. Duży rozproszony atak wciąż może spowolnić działanie; większość z niego przechwytuje firewall na brzegu sieci (WAF).

6. Ominięcie firewalla

Atak. Wywoływanie serwerów Frontmail bezpośrednio zamiast przez CDN, żeby ominąć web application firewall i podrobić adres IP klienta.

Co robi Frontmail. Serwery przyjmują tylko żądania, które przeszły przez nasz CDN, i ufają tylko adresowi IP klienta przekazanemu przez CDN. Nie musisz nic konfigurować.

7. Wyciek klucza prywatnego

Atak. Klucz prywatny trafia do kodu przeglądarkowego (często po migracji z EmailJS, gdzie accessToken to klucz prywatny) i ktoś go kopiuje.

Co robi Frontmail. Przeglądarkowe SDK odmawiają działania z kluczem prywatnym (private_key_in_browser), a API odrzuca żądania z kluczem prywatnym ze strony internetowej, chyba że masz włączone Zezwól na klucze prywatne w przeglądarkach. Klucze prywatne przechowujemy tylko jako hashe.

Co robisz ty. Nigdy nie umieszczaj sk_… w kodzie frontendu ani w zmiennych VITE_ / NEXT_PUBLIC_. Jeśli wyciekł, natychmiast go wymień.

Pozostałe ryzyko. Ktoś, kto ma twój klucz prywatny, może wysyłać bez CAPTCHA i czytać historię wiadomości (w tym dane z formularzy). Chroń go jak hasło.

8. Niebezpieczne załączniki

Atak. Wysłanie złośliwego oprogramowania tobie albo dynamicznemu odbiorcy jako załącznik.

Co robi Frontmail. Załączniki z przeglądarki są wyłączone, dopóki szablon na nie nie pozwoli. Pliki wykonywalne, skrypty, HTML/SVG, obrazy dysków, dokumenty Office z makrami i podobne typy są blokowane, także gdy ukrywają się za sztuczkami typu faktura.pdf.exe., znakami odwracającymi kierunek tekstu czy niewidocznymi znakami. Przesyłanie z kluczem publicznym ma dzienny limit objętości.

Pozostałe ryzyko. Zwykłe dokumenty (PDF, DOCX) wciąż mogą zawierać złośliwą treść; ostatnią linią obrony jest antywirus twojego klienta poczty.

9. Wstrzyknięcie HTML lub skryptu do e-maila

Atak. Wstawienie do parametru <script>, piksela śledzącego albo fałszywego formularza.

Co robi Frontmail. Parametry są zawsze escape’owane w HTML (nawet w {{{ }}}), parametry html są sanityzowane według allowlisty i nie mogą wydostać się z atrybutów, niebezpieczne URL-e są neutralizowane, z nagłówków usuwane są znaki końca linii (brak wstrzykiwania nagłówków), a klucze zanieczyszczające prototyp są odrzucane.

10. Nękanie jednej osoby (mail bombing)

Atak. Użycie szablonu z dynamicznym odbiorcą do wysłania wielu e-maili na jeden adres.

Co robi Frontmail. Dzienny limit na odbiorcę (domyślnie 5), wspólny z automatycznymi odpowiedziami; lista wykluczeń dla adresów, które odbiły wiadomość lub złożyły skargę.

11. Przejęcie twojego konta w panelu

Atak. Zgadywanie hasła, skradziona sesja, skradziona skrzynka pocztowa.

Co robi Frontmail. Limity logowania, uwierzytelnianie dwuskładnikowe wymuszane przy każdej metodzie logowania, linki do resetu hasła działające tylko raz i wylogowujące ze wszystkich urządzeń, zmiana e-maila potwierdzana ze starego adresu, powiadomienia o nowym urządzeniu, role z minimalnymi uprawnieniami i dziennik zdarzeń.

Co robisz ty. Włącz 2FA, a członkom zespołu dawaj najniższą rolę, która wystarczy.

12. Kradzież danych z twoich formularzy

Atak. Odczytanie cudzej historii wiadomości lub plików.

Co robi Frontmail. Historię może odczytać tylko klucz prywatny albo członkowie twojej organizacji; każde wyszukiwanie jest ograniczone do twojej organizacji, łącznie z plikami dołączonymi do szablonów.

13. Podrobione zdarzenia doręczenia

Atak. Wysłanie fałszywych zdarzeń „odbity” lub „skarga”, żeby wpisać twoich klientów na listę wykluczeń.

Co robi Frontmail. Webhooki dostawców są weryfikowane podpisem, jeśli dostawca to obsługuje, i zawsze tajnym tokenem w URL-u; zdarzenie dotyczy wyłącznie faktycznego odbiorcy danej wiadomości.

Co robisz ty. Tam, gdzie dostawca to oferuje, skonfiguruj klucz do podpisywania.

14. Przejęte SDK

Atak. Złośliwy kod w skrypcie, który ładuje twoja strona.

Co robi Frontmail. Wydania są budowane bez sekretów, publikowane z potwierdzonym pochodzeniem (provenance), a akcje CI są przypięte do dokładnych wersji.

Co robisz ty. Ładuj SDK z URL-a z konkretną wersją i atrybutem integrity (zobacz SDK dla przeglądarki) albo dołącz pakiet z npm do swojego bundla.

15. Frontmail w rękach przestępców

Atak. Strona phishingowa używa własnego konta Frontmail, żeby wysyłać sobie skradzione hasła – to zdarza się każdej usłudze tego typu.

Co robi Frontmail. Zweryfikowany e-mail właściciela, monitorowanie nietypowego ruchu, szybkie zawieszanie zgłoszonych kont. Nadużycia zgłaszaj na abuse@frontmail.dev.

Co zostaje po twojej stronie – lista kontrolna

• Wypełnij Dozwolone domeny swoimi domenami.
• Dodaj własne klucze Turnstile i wymagaj CAPTCHA w publicznych formularzach.
• Używaj dynamicznego odbiorcy tylko tam, gdzie jest potrzebny; wypełnij Dozwolone domeny linków.
• Zostaw Zezwól na aplikacje mobilne i Zezwól na klucze prywatne w przeglądarkach wyłączone, jeśli ich nie potrzebujesz.
• Klucz prywatny tylko na serwerze; w razie wątpliwości wymień go.
• Zostaw debet i automatyczne doładowanie dla ruchu z kluczem publicznym wyłączone (domyślnie).
• Włącz 2FA wszystkim w zespole.
• Ładuj SDK z przypiętej wersji z atrybutem integrity.