Bezpieczeństwo aplikacji Laravel: CSRF, XSS, SQL injection i OWASP
Włamania do stron i paneli nie biorą się z „pecha”. Biorą się z pominiętych zabezpieczeń. Laravel ma wbudowaną ochronę przed najczęstszymi atakami — pod warunkiem, że ktoś jej naprawdę używa.
Właściciel firmy zwykle nie pyta o token CSRF. Pyta, czy ktoś wyciągnie bazę klientów, czy konkurencja podejrzy cennik, i czy panel nie padnie w piątek wieczorem. Te pytania sprowadzają się do kilku klasycznych wektorów ataku — i właśnie przed nimi Laravel broni się „z pudełka”, jeśli aplikacja jest zbudowana porządnie.
Trzy ataki, które wciąż działają na tanie strony
SQL injection — kradzież danych przez formularz
Atakujący wkleja złośliwy fragment SQL w pole wyszukiwania albo logowania. Źle napisana aplikacja wykonuje to zapytanie na bazie. W Laravelu Eloquent i Query Builder używają parametrów powiązanych (prepared statements), więc surowy SQL z formularza nie trafia do bazy. Surowych zapytań używamy tylko wyjątkowo — i zawsze ze związanymi parametrami.
XSS — złośliwy skrypt w przeglądarce użytkownika
Jeśli aplikacja wyświetla imię klienta albo komentarz bez escapowania, ktoś może wstawić skrypt, który kradnie sesję albo zmienia treść strony. Blade, silnik szablonów Laravela, domyślnie escapuje zmienne. We Vue.js treść też jest escapowana, chyba że ktoś świadomie użyje v-html. Tego nie robimy na danych od użytkownika.
CSRF — akcja w Twoim imieniu
Użytkownik jest zalogowany. Otwiera inną stronę, która po cichu wysyła żądanie „zmień hasło” albo „przelej środki” do Twojej aplikacji. Laravel wymaga tokenu CSRF przy formularzach i żądaniach zmieniających stan — bez niego serwer odrzuca request.
OWASP Top 10 — checklista, nie marketing
OWASP Top 10 to lista najgroźniejszych ryzyk w aplikacjach webowych. W projektach GESOFT traktujemy ją jako listę kontrolną, nie ozdobnik na stronie:
- Złamana kontrola dostępu — role i policy w Laravelu, testy uprawnień, brak „ukrytych” URL-i jako jedynego zabezpieczenia.
- Błędy kryptograficzne — hasła przez bcrypt/argon2, HTTPS wszędzie, sekrety tylko w .env, nigdy w Git.
- Wstrzyknięcia (injection) — ORM, walidacja requestów, lista dozwolonych wartości zamiast zaufania do klienta.
- Zła konfiguracja — wyłączony debug na produkcji, osobne środowiska, minimalne uprawnienia bazy.
- Komponenty z lukami — regularne aktualizacje dependencji, monitoring CVE, brak porzuconych paczek.
- Błędy identyfikacji — limity logowań, 2FA, wygasające sesje, reset hasła z jednorazowym tokenem.
Co dokładamy poza standardem Laravela
- Rate limiting na logowanie, formularze i API — utrudnia zgadywanie haseł i spam.
- Nagłówki bezpieczeństwa (HTTPS, HSTS, ograniczenie iframe, polityka referrer).
- Logi audytowe: kto, kiedy i z jakiego IP zmienił dane wrażliwe.
- Kopie zapasowe bazy i plików, testowane odtwarzanie — backup, którego nikt nie sprawdzał, to nie backup.
- Dwuskładnikowe logowanie tam, gdzie panel ma dostęp do pieniędzy albo danych osobowych.
- Hardening serwera: firewall, SSH tylko na klucz, aktualizacje systemu.
Jeśli masz już aplikację PHP i nie jesteś pewien, czy te rzeczy są zrobione — warto zacząć od audytu bezpieczeństwa. Nowy projekt budujemy od razu z tymi mechanizmami. Napisz, co chcesz zabezpieczyć — powiemy konkretnie, od czego zacząć.
Opisz projekt