Przepływ danych — krok po kroku
Strona Bezpieczeństwo tłumaczy zasady w skrócie. Tu jest ta sama historia, ale dokładniej — z nazwami usług i z uczciwą odpowiedzią na pytanie „co konkretnie ogranicza szkodę, gdyby coś poszło nie tak”.
1. Podłączasz skrzynkę pocztową
Wpisujesz login i hasło do swojej poczty w Ustawieniach. Hasło leci przez szyfrowane połączenie (HTTPS) i od razu trafia do Google Cloud KMS — usługi szyfrowania kluczy. W bazie danych nie ma nigdy zwykłego tekstu hasła, tylko szyfrogram.
2. Dedykowany serwer odbiera Twoją pocztę
Osobny serwer (nie ten sam co strona) łączy się co kilka minut z Twoją skrzynką przez IMAP — zawsze szyfrowanym połączeniem. Hasło jest odszyfrowywane z KMS na chwilę potrzebną do połączenia i nigdy nie jest trzymane „na zapas” w pamięci między cyklami.
3. Mail trafia do bazy danych
Nowa wiadomość zapisuje się w Postgresie (Supabase). Ten serwer korzysta z osobnej, wąskiej roli bazodanowej — ma dostęp tylko do tabel związanych z pocztą, nie do rozliczeń ani reszty appki.
4. Powstaje szkic odpowiedzi
Treść maila leci szyfrowanym połączeniem do wybranego dostawcy AI (OpenAI, Anthropic, Google albo Mistral — zależnie od Twojego wyboru). Jeśli używasz własnego klucza API, on też jest szyfrowany w KMS i odszyfrowywany tylko na czas tego jednego zapytania.
5. Ty decydujesz
Szkic czeka w Twojej skrzynce Skrzynka. Nic nie wychodzi do klienta, dopóki nie klikniesz „Zatwierdź”.
6. Wysyłka
Dopiero po Twojej zgodzie wiadomość leci szyfrowanym połączeniem SMTP, z Twojego konta, z Twoim podpisem.
7. Płatności
Numer karty nigdy nie trafia na serwery Skrzynka — płatność obsługuje Stripe. Sama appka ma dostęp do konta Stripe przez klucz ograniczony do dokładnie tych operacji, które są jej potrzebne (klient, płatność, panel klienta) — nic więcej, nawet gdyby ten klucz wyciekł.
8. Logowanie
Przez Google/Microsoft (appka nigdy nie widzi Twojego hasła do tych kont) albo e-mail i hasło — chronione testem odróżniającym człowieka od bota (captcha).
Co, jeśli coś pójdzie nie tak
Żaden system nie jest w 100% odporny, więc zamiast obiecywać nieomylność, opisujemy uczciwie, co ogranicza zasięg szkody na każdym poziomie — żebyś wiedział, co faktycznie jest w grze.
Przejęcie serwera obsługującego pocztę
Ma dostęp wyłącznie do tabel poczty przez wąską rolę bazodanową — nie do rozliczeń, nie do haseł logowania, nie do kluczy szyfrowania. Hasła IMAP przechodzą przez ten serwer tylko w locie, nie są tam magazynowane.
Podanie fałszywego adresu serwera pocztowego
Zanim serwer poczty faktycznie połączy się z adresem podanym przy podłączaniu skrzynki, sprawdza, czy to naprawdę zewnętrzny serwer pocztowy, a nie adres wskazujący z powrotem na naszą własną infrastrukturę. To sprawdzenie powtarza się przy każdym połączeniu, nie tylko raz przy zapisie skrzynki.
Wyciek samej bazy danych
Hasła do skrzynek i klucze API są zaszyfrowane — sam zrzut bazy nie daje ich w czytelnej postaci, bo klucz odszyfrowujący żyje w zupełnie innym systemie (Google Cloud KMS), z osobnymi poświadczeniami. Mówimy wprost: treść samych e-maili nie jest szyfrowana drugi raz w bazie, bo appka musi ją na bieżąco odczytywać i pokazywać Tobie. Chroni ją standardowe szyfrowanie w spoczynku po stronie Supabase oraz separacja kont (RLS) — logując się na swoje konto, nie zobaczysz cudzych maili, i odwrotnie.
Przejęcie samej aplikacji
Appka nie trzyma sekretów w pamięci między żądaniami. Każde użycie klucza szyfrowania czy klucza Stripe czyta go świeżo z bezpiecznego magazynu sekretów hostingu — nie z bazy i nie z kodu appki.
Przejęcie konta czy sprzętu kogoś z zespołu Skrzynka
Appka i serwer pocztowy mają osobne, rozdzielone poświadczenia dostępu do usługi szyfrowania — przejęcie jednego nie odblokowuje drugiego.
Próba osadzenia strony Skrzynka w cudzej witrynie
Przeglądarka dostaje od nas jednoznaczną instrukcję: strony Skrzynka nie wolno otwierać wewnątrz żadnej innej strony (ochrona przed tzw. clickjackingiem — podszyciem prawdziwej strony pod fałszywy interfejs), a połączenie zawsze musi być szyfrowane.