Podsumowanie artykułu
- O bezpieczeństwie należy myśleć już na etapie projektowania — nie dopiero przy wdrożeniu czy testach.
- Każda rola w zespole deweloperskim (UX, analityk, architekt, programista, tester, DevOps) ma realny wpływ na poziom zabezpieczeń.
- Klient nie zawsze ma świadomość zagrożeń — rolą zespołu jest edukowanie i proponowanie odpowiednich rozwiązań.
- Unikanie uproszczeń (np. ukryte linki, przewidywalne identyfikatory w URL) to fundament bezpiecznego projektu.
- Warto korzystać z istniejących narzędzi i bibliotek zamiast pisać własne mechanizmy szyfrowania czy autoryzacji.
- Najlepsze, co można zrobić: być uważnym, nie ufać zbyt łatwo i wdrażać bezpieczeństwo jako integralny element całego procesu tworzenia aplikacji.
Żyjemy w czasach bezprecedensowego wzrostu cyberprzestępczości. Dlatego tym bardziej warto zadbać o to, by tworzona aplikacja internetowa była odpowiednio zabezpieczona. Ten artykuł to nie tylko przestroga przed błędami, które można popełnić przy projektowaniu i budowie aplikacji internetowych, ale też przypomnienie o złudnym poczuciu bezpieczeństwa, któremu łatwo ulec.
Przedstawiamy sprawdzone praktyki, które warto wdrażać na każdym etapie pracy: od analizy i projektowania po kodowanie, testowanie i utrzymanie. Co najważniejsze, są one uniwersalne: mają zastosowanie niezależnie od języka programowania czy wykorzystywanego frameworka.
Kiedy należy myśleć o bezpieczeństwie aplikacji webowej?
Choć może się to wydawać oczywiste, bezpieczeństwo aplikacji webowej nie zaczyna się gdzieś w połowie jej budowy, gdy podstawowe funkcjonalności są już gotowe. Nie zaczyna się nawet w momencie rozpoczęcia kodowania. Zaczyna się o wiele wcześniej, już na etapie projektowania, a niekiedy nawet podczas szacowania kosztów czy składania oferty. Warto mieć świadomość, że potencjalne konsekwencje zaniedbań na tym etapie mogą być bardzo poważne. W grę wchodzi nie tylko reputacja marki, ale w najgorszym scenariuszu również sankcje finansowe czy postępowania prawne.
Dlatego warto zacząć od zadania sobie (lub klientowi) właściwych pytań dotyczących bezpieczeństwa aplikacji. To one pozwolą zbudować solidne fundamenty zabezpieczeń.
Jakie są wymagania klienta w zakresie bezpieczeństwa aplikacji?
Zdarza się, że klient ma już sprecyzowane oczekiwania dotyczące bezpieczeństwa aplikacji. Może dysponować narzędziami, które trzeba będzie zintegrować z nowym rozwiązaniem. Częściej jednak nie posiada ani jasnych wytycznych, ani żadnych wdrożonych mechanizmów. Bywa, że nie jest nawet świadomy, iż ochrona danych i aplikacji to obszar, którym należy się zająć.
W takich sytuacjach rola edukatora spada na twórców oprogramowania. To oni powinni uświadomić klientowi, że pytanie nie brzmi: „czy dojdzie do cyberataku?”, ale raczej: „kiedy to nastąpi?”. Warto więc od razu zakładać, że aplikacja będzie musiała się z nim zmierzyć w trakcie swojego cyklu życia i już na wstępie wdrożyć odpowiednie polityki bezpieczeństwa.
W jaki sposób aplikacja będzie wykorzystywana?
Czy będzie ogólnodostępna, czy może dostępna tylko w ramach sieci intranetowej? Kim będą jej końcowi użytkownicy? Czy będzie działać pod dużym obciążeniem, czy też nie? Czy wybrany framework lub platforma aplikacyjna zawierają już jakieś wbudowane mechanizmy bezpieczeństwa?
Odpowiedzi na te pytania umożliwią zaprojektowanie aplikacji w sposób przemyślany i adekwatny do kontekstu jej działania.
Jakie narzędzia do zabezpieczania aplikacji internetowej będą używane?
Czy będą to rozwiązania darmowe, czy wymagające zakupu licencji? Czy są intuicyjne w obsłudze, czy też konieczne będzie zatrudnienie lub przeszkolenie dedykowanego specjalisty? Czy bezproblemowo zintegrują się z infrastrukturą klienta? Wszystkie te kwestie mają bezpośredni wpływ na budżet projektu oraz skład zespołu, dlatego warto rozważyć je jeszcze przed rozpoczęciem prac.
Gdy wszystkie powyższe zagadnienia zostaną już doprecyzowane, konieczne jest uwzględnienie aspektów bezpieczeństwa aplikacji w kosztorysie. Trzeba też uświadomić potencjalnym klientom, jak kluczowe jest zadbanie o ten obszar od samego początku dodatkowe wydatki na starcie pozwolą uniknąć znacznie poważniejszych problemów w przyszłości. Utrata danych użytkowników nie tylko podważy wiarygodność firmy, ale może również skutkować poważnymi karami finansowymi i konsekwencjami prawnymi.
Praktyki bezpieczeństwa na każdym etapie tworzenia aplikacji
Przyjrzyjmy się teraz kolejnym etapom procesu deweloperskiego i sprawdźmy, jakie najlepsze praktyki powinni stosować analityk biznesowy lub projektant UX, architekt rozwiązań, tester, programista oraz inżynier DevOps, a także czego zdecydowanie należy unikać.
Jestem analitykiem biznesowym lub projektantem UX
Analityk biznesowy czy projektant UX również może, często nieświadomie, popełnić wiele błędów w kontekście bezpieczeństwa aplikacji. Wcale nie musi to wynikać z braku wiedzy technicznej, ale raczej z tego, że sam klient nie zdaje sobie sprawy z powagi problemu.
Oczywiście aplikacja powinna być łatwa w obsłudze i zarządzaniu. Jednak nie oznacza to, że należy iść na kompromisy w zakresie jej zabezpieczeń. Pokusa „pójścia na skróty” może być duża, ale rolą specjalisty technicznego jest uświadomienie klientowi, że każdy taki wybór zwiększa podatność systemu na ataki. Nawet jeśli klient nie ma doświadczenia technologicznego, to właśnie na Tobie spoczywa obowiązek przedstawienia wszystkich możliwych zagrożeń.
Przykłady realnych błędów, których należy unikać
Oto kilka praktyk, które — o ile klient nie jest w pełni świadomy ryzyka i go nie akceptuje — należy zdecydowanie wyeliminować na etapie projektowania:
- logowanie jednego użytkownika w kontekście drugiego,
- podnoszenie uprawnień bez właściwej autoryzacji,
- Dostęp do chronionych funkcjonalności przez nieautoryzowany (choćby zaciemniony) publiczny URL
- możliwość podejrzenia danych innych użytkowników przez publiczny adres URL
- używanie łatwych do odgadnięcia haseł (np. dat urodzin) do „zabezpieczania” danych udostępnianych użytkownikom,
- łączenie funkcji administracyjnych z kontem użytkowanym na co dzień,
- brak zabezpieczeń przed botami (np. brak captchy), zwłaszcza w aplikacjach dostępnych publicznie,
- brak silnych mechanizmów uwierzytelniania, najlepiej wieloskładnikowego (MFA)
- brak systemów wykrywania intruzów (IDS),
- brak mechanizmów identyfikujących i reagujących na podejrzane zachowania użytkowników (np. wielokrotne błędne logowania, iteracja identyfikatorów w URL-ach, blokowanie znanych złośliwych adresów IP),
- komunikaty o błędach ujawniające zbyt wiele informacji, np. rozróżnienie między „konto z tym adresem e-mail nie istnieje” a „błędne hasło” umożliwia atakującemu identyfikację zarejestrowanego użytkownika, co otwiera drogę do działań typu spear phishing.
Najlepsze praktyki dla analityków biznesowych i projektantów UX
Co zatem należy robić, by zwiększyć poziom bezpieczeństwa projektowanego systemu?
- Sugerować wykorzystanie zewnętrznego dostawcy usług uwierzytelniania. Na rynku dostępnych jest wielu dostawców rozwiązań klasy enterprise (takich jak ADFS, RSA Link, Evidian, One Identity), jak i publicznych: OAuth, OpenID, Google, Facebook, Twitter, Amazon, Microsoft.
- Rekomendować wprowadzenie mechanizmów wieloskładnikowego uwierzytelniania (MFA). Wybór dostępnych opcji jest szeroki, zarówno w modelu SaaS, jak i on-premise.
- W przypadku braku zaawansowanej wiedzy technicznej — konsultować się z architektem rozwiązań. Współpraca z taką osobą pozwala przygotować bezpieczne i realistyczne rekomendacje dla klienta.
- Być stanowczym i asertywnym w rozmowach z klientem, jeśli chodzi o bezpieczeństwo. Kompromisy w tym obszarze powinny być jasno nazwane i świadomie podejmowane, a najlepiej w ogóle ich unikać.
Jestem architektem rozwiązań
Jako architekt rozwiązań masz wyjątkowy przywilej — i zarazem odpowiedzialność — by odegrać kluczową rolę w projektowaniu bezpieczeństwa aplikacji. Na tym etapie to właśnie do Ciebie zwracają się analitycy biznesowi i projektanci UX z pytaniami o to, co należy zaproponować klientowi (a przynajmniej powinni to robić, jeśli przeczytali ten artykuł). Teraz Twoja kolej, by dobrać odpowiednie narzędzia i frameworki. Oto lista najlepszych praktyk, oparta na doświadczeniu autora.
Warto przy tym zapoznać się z zestawieniem OWASP Top 10 — regularnie aktualizowaną listą najczęstszych podatności w aplikacjach webowych — i upewnić się, że projekt jest odporny na każdą z nich.
Rozmawiaj z działem IT klienta
Taka rozmowa może przynieść wiele cennych informacji, które albo uproszczą Twoje decyzje, albo je utrudnią, ale na pewno sprawią, że będą one bardziej świadome. I dotyczy to nie tylko kwestii bezpieczeństwa. Może się okazać, że istnieje już infrastruktura, z którą aplikacja musi być kompatybilna (np. load balancing, serwery proxy, ESB). Albo że trzeba będzie zintegrować ją z innymi systemami zgodnie ze standardami korporacyjnymi klienta. Może w firmie działa już SSO lub inny system uwierzytelniania. Wszystkie te informacje warto zebrać zanim rozpocznie się właściwe projektowanie.
Wykorzystuj istniejące mechanizmy szyfrowania, uwierzytelniania i autoryzacji
Nie trzeba już nikomu przypominać o konieczności stosowania SSL — to absolutna podstawa. Znacznie ważniejsze jest to, by środowiska deweloperskie i testowe konfigurować od razu z pełnym zestawem mechanizmów szyfrowania, uwierzytelniania i autoryzacji. Tak, ich konfiguracja zajmie czas, a debugowanie będzie trudniejsze. Ale w dłuższej perspektywie oszczędzi to mnóstwo pracy przy wdrażaniu aplikacji w środowisku produkcyjnym. I co równie ważne, zabezpieczy środowiska testowe przed wyciekiem danych czy atakami ransomware.
Zaprojektuj i wdrażaj uwierzytelnianie oraz autoryzację między komponentami aplikacji
Niezależnie od tego, czy chodzi o architekturę mikroserwisową, rozproszony system czy aplikację monolityczną z dostępem do bazy danych, anonimowy dostęp, nieszyfrowane endpointy czy brak śladów audytowych to zły pomysł. Nawet jeśli komponenty nie są wystawione do Internetu, a działają wyłącznie w sieci korporacyjnej. Warto wziąć pod uwagę, np. certyfikaty X.509.
Projektuj prawidłowe obsługi błędów
To szczególnie istotne, gdy aplikacja jest dostępna publicznie. Nawet jeśli strona błędu w czcionce Times New Roman wygląda niezgrabnie, to i tak lepiej wyświetlić komunikat w stylu „wystąpił błąd wewnętrzny”, niż ujawniać dane konfiguracyjne, kod źródłowy czy stack trace.
Prawidłowo loguj błędy
Użytkownik końcowy powinien otrzymać token korelacyjny, dzięki któremu będzie można później powiązać zdarzenie z odpowiednim wpisem w logach. A zespół techniczny — odpowiednie narzędzia do przeszukiwania logów i wykrywania nieprawidłowości. Tu również istnieje wiele gotowych rozwiązań, np. Graylog, Nagios czy Elastic Stack.
Ukrywaj szczegóły błędów przed użytkownikiem
Jeśli można przewidzieć, co może pójść nie tak, wyświetl sensowny komunikat, z którym użytkownik może coś zrobić. Resztę ukryj za uniwersalnym „wystąpił nieoczekiwany błąd”.
Informuj administratorów i power userów o błędach
Jeśli skonfigurujesz Seriloga tak, by wysyłał maila przy każdym wyjątku, to licz się z tym, że po pierwszym dniu aplikacja wyląduje w spamie. Warto stosować poziomy logowania i odpowiednio klasyfikować komunikaty, tak by istotne informacje naprawdę się wyróżniały.
Spróbuj włamać się do własnej aplikacji
Zadaj sobie lub innym pytanie: jak można by włamać się do tej aplikacji? Zazwyczaj punktem wejścia będzie formularz logowania, bo to jedyny publicznie dostępny komponent. Dlatego warto:
- ograniczać treść komunikatów błędów,
- blokować wielokrotne nieudane logowania (per użytkownik, IP, czas itp.),
- bronić się przed atakami timingowymi,
- reagować na podejrzane wzorce zachowań.
Inne dobre praktyki dla architekta rozwiązań:
- Nie przechowuj haseł ani danych wrażliwych, jeśli to niekonieczne. A jeśli już, przechowuj je poprawnie!
- Szyfruj pliki konfiguracyjne.
- Automatyzuj wdrożenia, by zminimalizować ryzyko błędów ludzkich.
- Nie zgadzaj się na „wrzutki” last-minute bez przejścia przez pełny proces testów i releasu.
- Nie zakładaj, że „to tylko aplikacja intranetowa, więc nie potrzeba zabezpieczeń”.
- Korzystaj z cheat sheetów OWASP dla danej technologii — są bardzo pomocne.
Jestem testerem
Czy jesteś testerem penetracyjnym? Jeśli tak, możesz pominąć ten fragment. Jeśli nie, stań się nim! Choćby na podstawowym poziomie. W świecie tworzenia oprogramowania wciąż panuje błędne przekonanie, że testerzy powinni skupiać się wyłącznie na funkcjonalnościach, a kwestie bezpieczeństwa zostawić programistom. Jeśli pracujesz w ten sposób, masz szczęście — trafiasz na wybitnych deweloperów. Albo właśnie jesteś o krok od zatwierdzenia aplikacji, do której za moment ktoś się włamie. Zastanów się, który scenariusz jest bardziej prawdopodobny.
Tematyka testów penetracyjnych znacząco wykracza poza ramy tego artykułu, ale pamiętaj — nawet podstawowe testy bezpieczeństwa powinny być zaplanowane, usystematyzowane i faktycznie wykonywane:
- Testuj mechanizmy uwierzytelniania, zarówno w interfejsie użytkownika, jak i w API.
- Testuj autoryzację — uprawnienia, role — również w frontendzie i API.
- Nie testuj wszystkiego na użytkowniku z uprawnieniami „Boga”.
- Naucz się korzystać z narzędzi testowych: zarówno manualnych (konsola przeglądarki, dodatki developerskie, Fiddler, Postman), jak i automatycznych (OWASP ZAP, Metasploit, W3af). Te drugie są trudniejsze w obsłudze, ale pozwalają odkryć luki, o których wcześniej nawet nie pomyślałeś.
- Umów się z architektem lub programistą i przeprowadźcie wspólne testy:
- Spróbuj zalogować się, używając nieprawidłowych danych.
- Wygeneruj wyjątek i sprawdź, czy błąd został zapisany w logach oraz czy informacje tam zawarte pozwalają zespołowi technicznemu szybko zdiagnozować problem.
- Celowo „zepsuj” integracje: wyłącz jeden z komponentów, zmodyfikuj plik z danymi, zatrzymaj aplikację w trakcie przetwarzania zadań w tle — i sprawdź, czy oraz jak system się z tego „podniesie”.
Jestem programistą
Masz już przydzielone zadania, zaraz zaczynasz pisać kod. Wszystko zostało zaplanowane i zaprojektowane jak należy. A przynajmniej powinno. Jeśli widzisz potencjalną lukę bezpieczeństwa — zgłoś to. W najgorszym razie ktoś wyjaśni, że problem już został rozwiązany przez inny komponent. W najlepszym — uświadomisz komuś coś, o czym wcześniej nie pomyślał.
Nie ufaj zabezpieczeniom frameworka
Możesz uważać, że Twój framework ma „wszystko załatwione”. W większości przypadków tak jest. Ale co, jeśli coś drobnego zawiedzie? Dlatego warto mimo wszystko stosować się do podstawowych zasad:
Nigdy nie implementuj własnego szyfrowania ani uwierzytelniania
Wyjątki od tej reguły są nieliczne i bardzo specyficzne. Tworząc własne mechanizmy szyfrowania, na pewno popełnisz błąd. Po prostu tego nie rób. Istnieje zbyt wiele sprawdzonych bibliotek i narzędzi, by uzasadnić pisanie własnego rozwiązania.
Każdy framework oferuje własne komponenty bezpieczeństwa, używane i testowane w tysiącach aplikacji. Owszem, warto przeprowadzić research — które z nich są najlepsze, najbezpieczniejsze, najbardziej elastyczne — ale nigdy nie pisz ich samodzielnie.
Waliduj wszystko — wszędzie i zawsze
Niezależnie od tego, czy dane pochodzą od użytkownika, z frontendu, mikroserwisu czy systemu zewnętrznego — waliduj je bez litości. Rob to natychmiast po otrzymaniu danych i w każdym kolejnym kroku, zwłaszcza jeśli nie masz absolutnej pewności co do źródła (a nie powinieneś jej mieć nigdy). Użytkownik może być złośliwy, ale równie dobrze może być po prostu nieuważny — z punktu widzenia bezpieczeństwa to bez różnicy.
Jeśli dane trafiają do formularza — waliduj je w interfejsie (dla szybszego feedbacku), następnie w API, potem w każdej usłudze, przez którą przechodzą. I na końcu: przed zapisem do bazy — escapuj. Lepiej dmuchać na zimne niż być szkołą z komiksu xkcd.
Błędy, których programista aplikacji powinien unikać
Lista nie jest wyczerpująca, ale oto kilka typowych błędów — na przykładzie klasycznej aplikacji trójwarstwowej (frontend, backend, baza danych):
Brak walidacji po stronie backendu lub zbyt powierzchowna walidacja
Walidacje powinny być równie dokładne lub nawet dokładniejsze w miarę jak dane „schodzą w dół” aplikacji. Nigdy nie stosuj precyzyjnych walidacji w frontendzie i pobieżnych w backendzie. Zawsze korzystaj z whitelist, nie z blacklist.
Brak uwierzytelniania lub autoryzacji w backendzie
To poważne zaniedbanie. Nawet jeśli użytkownik działa w dobrej wierze — może, np. udostępnić komuś link albo przekazać wiadomość e-mail z linkiem prowadzącym do wrażliwych danych.
Bezgraniczne zaufanie do danych pochodzących z frontendu (lub innych kontrolowanych komponentów)
Dane mogą zostać zmodyfikowane, żądania sfałszowane, nadawcy podszyci. Parametry URL (GET i POST/PUT), ukryte pola formularzy, ciasteczka, local storage, nagłówki HTTP — wszystko to można zmienić bez żadnych zaawansowanych narzędzi. „Oto zrzut ekranu z przeglądarki Firefox w standardowej konfiguracji, bez żadnych dodatków (zob. rysunek 1):
Rys. 1: Firefox w wersji standardowej, bez dodatków
Liczby całkowite lub inne łatwo iterowalne identyfikatory w URL-ach
Jeśli za kulisami działa prawidłowa autoryzacja, to czasem można na to przymknąć oko, ale i tak lepiej unikać sytuacji, które zachęcają użytkownika do sprawdzenia, co kryje się pod adresem ?id={n+1}.
„Sekretne linki” do udostępniania informacji lub plików użytkownikom
(np. długie, losowe linki prowadzące do zasobów na serwerze)
To nie jest kryptografia — to steganografia. Może być zabawna i bywa przydatna, ale nie chroni danych. Jasne, prawie nikt nie zgadnie takiego linku. Ale istnieje masa narzędzi służących do ich wykrywania, linki mogą wyciec, użytkownicy mogą je udostępniać publicznie, algorytm ich generowania może być prosty do złamania itd. Jeśli coś jest publicznie dostępne w Internecie, należy z góry założyć, że już wpadło w niepowołane ręce.
Brak aktualizacji pakietów, bibliotek i frameworków używanych przez aplikację
Może aplikacja już działa, została wdrożona i wszystko wygląda dobrze. Albo prace deweloperskie trwają na tyle długo, że wyszły nowe wersje zależności. W zdecydowanej większości przypadków będą one zawierały poprawki bezpieczeństwa, które chcesz mieć w swoim kodzie. Oczywiście — najpierw trzeba sprawdzić, czy nowe wersje nie wprowadzają niezgodności. Ale jeśli nie — aktualizuj. Oczywiste błędy, których nie trzeba już opisywać
Są powszechnie znane, a większość z nich znajduje się na liście OWASP Top 10. Unikanie ich to absolutna podstawa przy tworzeniu aplikacji webowych. Zatem z kronikarskiego obowiązku:
- SQL/XML/JSON injection — atakujący wstrzykuje złośliwe zapytania w miejsca oczekujące danych wejściowych, co może prowadzić do nieautoryzowanego dostępu do bazy danych lub manipulacji jej zawartością.
- XSS (Cross-Site Scripting) — umożliwia wstrzyknięcie i wykonanie złośliwego kodu JavaScript w przeglądarce innego użytkownika, często w celu kradzieży danych lub przejęcia sesji.
- CSRF (Cross-Site Request Forgery) — atak polegający na nakłonieniu zalogowanego użytkownika do nieświadomego wykonania nieautoryzowanej akcji w aplikacji, której ufa.
- Niezabezpieczone ciasteczka — brak odpowiednich flag (np. HttpOnly, Secure, SameSite) może sprawić, że ciasteczka sesyjne staną się łatwym celem dla ataków typu przechwytywanie sesji.
- Access-Control-Allow-Origin: * — globalne zezwolenie na dostęp z dowolnego źródła naraża aplikację na ataki typu cross-origin, zwłaszcza w kontekście wymiany danych API.
- Brak HSTS (HTTP Strict Transport Security) — bez wymuszenia HTTPS, użytkownicy mogą być narażeni na ataki typu man-in-the-middle podczas połączeń nieszyfrowanych.
- Brak CSP (Content Security Policy) — brak polityki ograniczającej źródła treści umożliwia łatwiejsze przeprowadzenie ataków XSS lub ładowanie złośliwych skryptów.
- Brak nagłówków x-xss-*, x-frame-options itd. — pominięcie tych nagłówków może otworzyć drogę do takich ataków jak XSS czy clickjacking, które da się zablokować jednym wpisem w konfiguracji serwera.
Jestem inżynierem DevOps
Jeśli monitorujesz sieci i środowiska — najpewniej jesteś mądrzejszy ode mnie i nie zamierzam mówić Ci, jak masz wykonywać swoją pracę. Ale na podstawie doświadczenia mogę podpowiedzieć, czego unikać:
- Maszyny deweloperskie w chmurze nie powinny mieć włączonych interfejsów sieciowych publicznych.
- Domeny testowe powinny mieć polityki bezpieczeństwa — najlepiej tak samo restrykcyjne jak środowiska produkcyjne.
- Kont nie należy używać ponownie między projektami, usługami ani — tym bardziej — użytkownikami.
- Maszyny deweloperskie powinny być regularnie aktualizowane.
- Dane produkcyjne nie powinny trafiać do środowisk deweloperskich (a jeśli już, to przynajmniej trzeba je zanonimizować!).
- Hasła nie powinny być przechowywane w repozytorium kodu.
- Hasła nie powinny być przekazywane przez publiczne kanały komunikacji.
- Trzeba być czujnym wobec nietypowych żądań związanych z bezpieczeństwem.
- W sytuacjach wymagających kompromisu — być asertywnym i bronić zasad bezpieczeństwa.
Bezpieczeństwo aplikacji webowych — najważniejsze wnioski
W zdecydowanej większości przypadków związanych z bezpieczeństwem, które napotkasz w trakcie tworzenia oprogramowania, wystarczy na chwilę się zatrzymać i pomyśleć, zamiast automatycznie powtarzać znane schematy.
Podsumowując:
- Bądź asertywny — od fazy ofertowej, przez projektowanie, aż po utrzymanie aplikacji.
- Nie ufaj nikomu, kto próbuje obniżyć standardy bezpieczeństwa.
- Zanim sam coś napiszesz, sprawdź, czy ktoś już nie rozwiązał podobnego problemu — szczególnie w kwestii uwierzytelniania czy szyfrowania.
- Bądź leniwy — korzystaj z bibliotek i kodu innych osób.
- Traktuj serwer i komputer deweloperski jak swój domowy komputer: instaluj aktualizacje, rób kopie zapasowe, zmieniaj hasła.
Mam nadzieję, że ten artykuł nauczył czegoś nowego — albo przynajmniej skłonił do refleksji nad własnymi złymi nawykami w tworzeniu oprogramowania. Prawdę mówiąc, jeszcze bardziej cieszyłoby mnie to drugie.
