Dobre skrypty, które zmieniły webdev
Historia, którą warto znać
W erze przed WordPressem, przed Squarespace, zanim ktokolwiek mówił o "no-code", żył sobie licealista o imieniu Matt Wright. Postanowił podzielić się skryptami w Perlu, które napisał.
W 1995 roku uruchomił Matt's Script Archive – skromną kolekcję narzędzi webowych: formularze kontaktowe, księgi gości, liczniki odwiedzin i jeden wynalazek, który rozprzestrzenił się jak wirus. Mowa o WWWboard. W ciągu miesięcy tysiące stron internetowych korzystały z jego kodu. Zwykli ludzie – którzy nie mieli zielonego pojęcia, czym jest Perl czy CGI – nagle mogli mieć działające fora i elementy interaktywne na swoich witrynach.
To był pierwszy smak zdemokratyzowanych narzędzi w internecie. I wiązało się to ze wszystkimi bałaganami, jakie ten termin ze sobą niesie.
Przepaść między twórcami a użytkownikami
To, co sprawiło, że skrypty Matta stały się tak popularne, było jednocześnie tym, co wywoływało dreszcze u profesjonalnych programistów: działały. Nie elegancko. Nie bezpiecznie. Ale działały.
Wright natknął się na fundamentalną prawdę o adopcji oprogramowania: większość ludzi nie chce rozumieć swoich narzędzi. Chcą, żeby narzędzia rozumiały ich. Właściciel małej firmy w 1996 roku nie przejmował się walidacją danych wejściowych ani ochroną przed SQL injection. Zależało mu na tym, żeby odwiedzający mogli zostawić wiadomość na jego ręcznie robionej stronie.
Tymczasem doświadczeni programiści patrzyli na kod Wrighta i widzieli koszmar. Hasła przechowywane w dostępnych katalogach. Zmienne środowiskowe wystawione w URL-ach. Jedna szczególnie paskudna podatność w skrypcie tekstowego licznika osiągnęła idealny wynik 10.0 w skali CVSS – czyli de facto otwarta tylna furtka do serwera.
Społeczność Perla w końcu odpowiedziała projektem nms (nongreedy's modifications), który dostarczał zamienniki działające "out of the box", ale bez narażania użytkowników na kompromitację root. Ich ocena była brutalna, ale uczciwa: "Skrypty są dobrze znane w społeczności Perla jako źle napisane, pełne błędów i niebezpieczne."
Paradoks bezpieczeństwa popularności
I tutaj robi się filozoficznie ciekawie.
Skrypty Matta nie były wyjątkowo tragiczne jak na swoją epokę. Dużo wczesnego kodu webowego miało dziury. To, co czyniło kod Wrighta niebezpiecznym, to jego zasięg. Kiedy tysiące stron korzystają z tego samego podatnego oprogramowania, powstaje ogromna powierzchnia ataku. Nagle teoretyczna podatność staje się prawdziwą epidemią.
Ten wzorzec powtarza się bez końca. Windows. WordPress. jQuery. Każde narzędzie wystarczająco popularne staje się celem nie dlatego, że jest źle zaprojektowane, ale dlatego, że jest wszędzie. Zadanie społeczności zajmującej się bezpieczeństwem to nie tylko naprawianie błędów – to przekonywanie ludzi, że "na teraz wystarczy" może nie wystarczyć później.
Ale jest tu napięcie: czasami "na teraz wystarczy" to dokładnie to, co umożliwia wzrost. Startup korzystający z niestabilnego wczesnego narzędzia może zbudować następnego WordPressa. Uniemożliwianie ludziom budowania z niedoskonałymi narzędziami oznacza uniemożliwianie im budowania w ogóle.
Witaj, vibe coding
Przewińmy trzydzieści lat do przodu. Mamy nową generację narzędzi "wystarczy na teraz": platformy kodowania z asystą AI, vibe-coded aplikacje, snippetów generowanych przez LLM wdrażanych prosto do produkcji.
Reakcja społeczności bezpieczeństwa już się rozgrywa. Tak, są obawy o kod generowany przez AI z subtelnymi podatnościami. Tak, trwają gorące debaty, czy vibe coding jest odpowiedzialny. I tak, niektórzy absolutnie wdrażają niebezpieczny syf do produkcji.
Ale oto co krytycy przeoczają: vibe coding robi dokładnie to, co skrypty Matta. Pozwala ludziom, którzy nie są zawodowymi programistami, dostarczać działające produkty. Solo przedsiębiorca może teraz zbudować działającą aplikację webową w jedno popołudnie. To nie jest nic – to demokratyzacja tworzenia.
Pytanie nie brzmi, czy vibe-coded aplikacje są bezpieczne. Często nie są. Pytanie brzmi, czy korzyści z dostępności przewyższają kompromisy w bezpieczeństwie. A historia sugeruje, że odpowiedź jest skomplikowana, ale generalnie pozytywna – z zastrzeżeniem, że potrzebujemy lepszych narzędzi, lepszych domyślnych ustawień i lepszej edukacji.
Historia domeny
Jest epilog tej opowieści, który jest szczególnie istotny dla każdego, kto myśli o domenach jako więcej niż tylko adresach.
Worldwidemart.com – domena, która kiedyś hostowała Matt's Script Archive – w końcu wygasła. Przez jakiś czas hostowała ten rodzaj spamerskich treści hazardowych, od których antywirusy dostają wysypki. Potem, pod koniec ubiegłego roku, ktoś wykupił wygasłą domenę specjalnie po to, by zachować historię archiwum.
Ktoś zależało na historii internetu na tyle, by uratować jej fragment od cybersquatterów. To warto odnotować. Domeny to nie tylko aktywa techniczne – to artefakty kulturowe. Czasami historia, którą opowiada domena, ma większe znaczenie niż jej wartość SEO.
Co to oznacza dla Ciebie
Więc jaki jest morał dla współczesnych programistów, założycieli startupów i przedsiębiorców technologicznych?
Po pierwsze, "wystarczy na teraz" zawsze napędzało adopcję. Nie lekceważ narzędzi tylko dlatego, że eksperci nimi gardzą. Narzędzia, których ludzie faktycznie używają, mają większe znaczenie niż te, które eksperci akceptują.
Po drugie, dług bezpieczeństwa się kumuluje. Jeśli budujesz na fundamentach "wystarczy na teraz", rozumiej, co dziedziczysz. Planuj dług techniczny. Wbuduj audyty bezpieczeństwa w swoją mapę drogową.
Po trzecie, dostępność i jakość nie są wrogami, ale wymagają równowagi. Celem nie jest uniemożliwianie ludziom budowania – to ułatwianie bezpiecznego budowania bardziej niż niebezpiecznego. To zadanie dla twórców narzędzi. Dla platform. Dla nas wszystkich.
Matt Wright nie zamierzał kształtować internetu. Po prostu udostępnił skrypty ludziom, którzy ich potrzebowali. Czasami to jest dokładnie to, czego świat potrzebuje. Tylko może dbaj o aktualizacje swoich zależności.