Bezpieczeństwo, nawet gdy „tylko prototypujesz"
Dlaczego myślę o bezpieczeństwie od pierwszego dnia — nawet budując małe narzędzia wewnętrzne — i jak architektura Lovable ułatwia zrobienie tego dobrze.
Bezpieczeństwo, nawet gdy „tylko prototypujesz"
Gdy budujesz nowy produkt — zwłaszcza sam i na wczesnym etapie — bardzo łatwo odkładać myślenie o bezpieczeństwie.
„Korzystam z tego tylko ja." „Naprawię to później." „Wciąż eksperymentuję."
Problem w tym, że bezpieczeństwa nie dodaje się później. Bezpieczeństwo się projektuje — albo przypadkiem wyprojektowuje — od samego początku.
Oto prosty model myślowy, którym się kieruję przy budowaniu swoich narzędzi.
Frontend to nie jest aplikacja
Wszystko, co działa w przeglądarce, jest publiczne, możliwe do podejrzenia i do zmodyfikowania.
Oznacza to, że frontend nigdy nie powinien zawierać:
- Sekretów ani kluczy API
- Logiki uprawnień
- Reguł walidacji
- Decyzji biznesowych
Frontend odpowiada tylko za:
- Wyświetlanie danych
- Zbieranie danych od użytkownika
- Wysyłanie żądań
Cała ważna logika mieszka gdzie indziej.
Backend to miejsce, gdzie istnieje zaufanie
Całe uwierzytelnianie, walidacja i logika biznesowa muszą żyć po stronie serwera — w Edge Functions.
Daje to:
- Jedno miejsce, w którym sprawdzane są uprawnienia
- Jedno miejsce, w którym walidowane są dane
- Jedno miejsce, w którym dzieją się wrażliwe operacje
Dzięki temu system jest łatwiejszy do ogarnięcia i bezpieczniejszy z założenia.
Row Level Security definiuje własność danych
Row Level Security nie jest funkcją opcjonalną.
Bez niego:
- Użytkownicy widzą dane, które do nich nie należą
- Rozdzielenie danych między najemcami przestaje działać
- Jedna pomyłka może odsłonić całe tabele
RLS definiuje:
- Kto co widzi
- Kto co może zmienić
- Jak oddzieleni są użytkownicy, zespoły i organizacje
Jeśli RLS brakuje albo jest źle ustawiony, system jest zły — nawet jeśli reszta wygląda w porządku.
Uwierzytelnianie to infrastruktura, nie interfejs
Ekrany logowania to doświadczenie użytkownika. Samo uwierzytelnianie to infrastruktura.
Interfejs reaguje na stan uwierzytelnienia, ale nigdy nie decyduje, co jest dozwolone. Wszystkie sprawdzenia uprawnień dzieją się po stronie serwera.
To rozdzielenie jest kluczowe.
Wewnętrzne nie znaczy bezpieczne
Nawet narzędzia wewnętrzne:
- Mogą być źle skonfigurowane
- Mogą zostać przypadkiem opublikowane
- Mogą urosnąć w prawdziwe produkty
Dlatego narzędzia wewnętrzne i tak powinny mieć:
- Włączone uwierzytelnianie
- Skonfigurowany RLS
- Zero sekretów we frontendzie
Teraz kosztuje to niewiele, a zapobiega dużym problemom później.
Na koniec
Bezpieczeństwo nie jest listą kontrolną do odhaczenia przed startem.
Jest decyzją strukturalną, którą podejmujesz na początku.
Szybko nie znaczy pomijać strukturę. Szybko znaczy wybrać strukturę, która nie pęka, gdy rośniesz.