Cześć! Nazywam się Bartosz Bryniarski, jestem doświadczonym Full Stack Web Developerem z ponad 20-letnim stażem w branży IT. Posiadam umiejętności w technologiach frontendowych (HTML, CSS, vanilla JavaScript, AJAX) oraz backendowych (PHP, Symfony, Laravel, Python, Java, Spring Boot). Tworzę również aplikacje mobilne na Androida i iOS w React Native (Expo) oraz Flutterze. Specjalizuję się także w pracy z różnymi bazami danych, takimi jak PostgreSQL, MySQL i SQLite, w konteneryzacji (Docker) oraz skalowaniu aplikacji, a także w zarządzaniu systemami sieciowymi opartymi na Windows, Linux i Unix.
Jestem absolwentem studiów inżynierskich z inżynierii komputerowej, a także studiów magisterskich na specjalności Internet rzeczy i sieci przyszłości. Ukończyłem również kilka studiów podyplomowych związanych z programowaniem, testowaniem oprogramowania, cyberbezpieczeństwem i informatyką śledczą. Dzielę się swoją wiedzą jako wykładowca akademicki, nauczyciel programowania w szkole średniej oraz prywatnej.
Wolny czas lubię spędzać jako przewodnik górski, a moje pasje to turystyka górska, biegi ultra, motoryzacja i fotografia. Na moim blogu dzielę się wiedzą i doświadczeniem z zakresu programowania, systemów operacyjnych i cyberbezpieczeństwa. Pomagam czytelnikom lepiej zrozumieć te zagadnienia i stawiać czoła wyzwaniom technologicznym. Jeśli interesujesz się tematyką IT, to zapraszam do odwiedzenia mojego bloga i poznania mnie bliżej.
Trzecia część cyklu Wychowany na PHP, tym razem osobiście. Z Perla przesiadłem się na PHP 4, przeprowadziłem na nie swoje i cudze projekty, przeszedłem przez piątkę i zatrzymałem się na siódemce. Dziś nowe projekty zaczynam zwykle w Pythonie – nie dlatego, że PHP jest zły, tylko dlatego, że wzorzec MVC poznany w Laravelu i Symfony znalazłem we Flasku i Django, a razem z nim wersje przypięte w repozytorium, migracje, panel admina i jeden język do backendu i skryptów. Plus jeden przypadek, w którym nadal sięgam po PHP: jeden plik index.php i SQLite na najtańszym hostingu.
PHP2Shell zaatakował, zanim aplikacja zdążyła się odezwać – więc jakość jej kodu nie miała znaczenia. To dobry pretekst, żeby zapytać o coś, o czym na tanim hostingu nikt nie myśli: co stoi między internetem a moim kodem, kto wybiera wersję interpretera i co staje się punktem wejścia. Cztery modele wdrożenia, od mod_php po statyczną stronę, porównane pod kątem tego, co atakujący dostaje za darmo. Bez tezy, że PHP jest zły – bo PHP podany porządnie wygląda dziś prawie tak samo jak Python.
20 października 2026 wyciekły szczegóły dwóch krytycznych luk w samym silniku PHP (CVE-2026-109618 i CVE-2026-109619, razem nazywanych PHP2Shell): zdalne wykonanie kodu bez logowania, zanim aplikacja zdąży się w ogóle uruchomić. W Polsce COI wyłączył strony BIP w systemie SSDIP, za granicą gasły serwisy rządowe w Holandii, Finlandii i Francji. Co dokładnie się zepsuło, ile serwerów było wystawionych, co wiemy o włamaniach – i dlaczego najgorsza liczba w tej historii to nie CVSS, tylko 69 procent.
W dużym projekcie nie da się pamiętać, że gdzieś już jest funkcja licząca to samo – więc pisze się ją drugi i trzeci raz. To nie lenistwo, to koszt pamięci. Problem w tym, że kopie z czasem się rozchodzą: ta sama najlepsza próba ucznia potrafiła być inna na ekranie i w PDF-ie, a w aplikacji mobilnej ten sam egzamin pokazywał czas raz jako 12:05, raz jako 12 min 5 s. Ta sama choroba złapała niezależnie backend Django i aplikację w React Native. O tym, dlaczego duplikacja to fabryka takich rozjazdów, i jak posprzątać ją bezpiecznie: najpierw dopisać testy, potem scalać, a zielona suita ma świecić tak samo przed i po.
Trzy lata temu pokazałem na blogu klasyczny SQL Injection: formularz logowania w PHP, sklejane zapytanie i wpisane w pole username „' OR 1=1#. Wróćmy do tamtego kodu i zadajmy inne pytanie: czy dziś dałoby się go tak w ogóle napisać? Bo domyślna ścieżka współczesnego PHP i frameworków – obsługa formularza, ORM, zapytania parametryzowane z pudełka – prowadzi do kodu bezpiecznego, a żeby wstrzyknąć SQL, trzeba dziś z tej ścieżki świadomie zejść. Z uczciwym rozdziałem o tym, gdzie wstrzyknięcie wciąż jest łatwe.
Teza krąży po branży od lat: gdyby programiści porządnie testowali własny kod, testerzy byliby zbędni. Patrzę na nią z nietypowej pozycji, bo jestem programistą po studiach podyplomowych z testowania – i rozkładam ją na łopatki trzema argumentami: moje testy testują moją wyobraźnię, tester patrzy na aplikację inaczej niż ja, a testowanie to zawód z własnym warsztatem. Z uczciwym rozdziałem o tym, co się w tej tezie mimo wszystko broni.
