zmienne globalne a aplikacje webowe

Często czytam rady, by tworzyć oprogramowanie w taki sposób, aby nie używać zmiennych globalnych. Żeby używać OOP itd. Ok, ma do sens jak dla mnie.

Ale co jeżeli mam do czynienia z aplikacjami webowymi, gdzie jak by nie patrzeć muszę "łapać" niektóre elementy DOMu. Czy faktycznie tworzenie takiego kodu:

const okienko = document.getElementById...
function blablalba (elementDOM) {
...
}

jest złe?

Nie lepiej raz "złapać", zamiast zmuszać każdą funkcję do ponownego szukania elementu na DOMie?

No chyba, że co innego zmienne typu liczniki, a co innego elementy DOMu.

Jeśli chodzi o backend to oczywiście da się żyć bez globali. Frontend to trochę inna bajka: łączenie widoku i stanu to zawsze był koszmar, po to właśnie są te wszystkie frameworki jak React, żeby w pewien sposób nad tym zapanować

Ale przecież to nie są zmienne globalne w takiej sytuacji, bo przecież każdy request to osobna instancja? Poza tym masz tu stałą a nie zmienną. Problem zmiennych globalnych jest taki, że taką zmienną można nagle zmodyfikować z jakiegoś losowego miejsca w kodzie i zmienić zachowanie innego miejsca i trudno nad tym panować. Jak masz coś co jest immutable to nie jest problem.

Raczej nikt nie robi dużych aplikacji korzystając bezpośrednio z DOM - bo umar by na XSSach - to pierwsze.
Po drugie poza jakąś inicjalizacją, gdzie ten document przekazujesz do aplikacji (jedna funkcja) nie ma potrzeby używania zmiennych globalnych. Można, ale nie trzeba. Im większa aplikacja i więcej osób nad nią pracuje tym mniej zmiennych globalnych warto mieć.

Co też oznacza (z drugiej strony), że w małej aplikacji, możesz po prostu się nie przejmować i nawrzucać sobie trochę zmiennych.

Widok się nie ma nijak do globalnego stanu; to są całkowicie inne koncepty.

UI Twojej aplikacji tylko wtedy będzie globalny, jeśli będziesz go używał jak zmiennych globalnych. Tzn, tak, document niby jest globalny, ale nie musisz przez całą Twoją aplikację wszędzie robić document.getElementBy*(). Możesz zaenkapsulować tylko w kodzie odpowiedzialnym za UI; i update'ować go na podstawie domeny i modeli Twojej aplikacji; tak że modele nie będą wiedzieć o UI.

PS: To tak na prawdę Twoje pytanie nie powinno brzmieć "Zmienne globalne, a a aplikacje webowe" tylko "Zmienne globalne, a interfejsy użytkownika"; bo wszystko co powiedziałeś o DOM'ie można powiedzieć o dowolnym UI innych aplikacji, np desktopowych i aplikacjach mobilnych.

jarekr000000 napisał(a):

Raczej nikt nie robi dużych aplikacji korzystając bezpośrednio z DOM - bo umar by na XSSach - to pierwsze.

Bzdura. Tylko jeśli nie wiesz co robisz.

kosmonauta80 napisał(a):

Nie lepiej raz "złapać", zamiast zmuszać każdą funkcję do ponownego szukania elementu na DOMie?

Nie musisz nic szukać, jeśli będziesz te elementy sam tworzyć. Np.

const foo = document.createElement('div');
...
document.body.appendChild(foo);

zamiast

const foo = document.getElementById('foo');

Myślę, że to już jest błędne założenie, że musisz szukać element w DOMu. Bo jak robisz coś większego na czystym DOM, to zapewne większość rzeczy będziesz tworzył dynamicznie (choć getElementById przydaje się do łapania np. głównych pojemników).

Jeśli używasz zbyt dużo getElementById (i łapiesz większość elementów w ten sposób) to albo robisz coś trywialnego, gdzie nie ma to różnicy, albo masz źle przemyślaną architekturę (bo co z dynamicznymi elementami, które tworzysz w trakcie działania programu i których może być więcej niż jeden? Wtedy musisz gdzieś zapamiętać referencję do tego elementu, bo przecież musisz je jakoś odróżniać. No ew. mogę sobie jeszcze wyobrazić jakąś zmyślną sytuację, gdzie id jest generowane przy tworzeniu jako unikalny string i zapamiętywane gdzieś.

Nie lepiej raz "złapać", zamiast zmuszać każdą funkcję do ponownego szukania elementu na DOMie?

Możesz przekazywać gdzieś referencje do elementów.
Np. masz funkcję doSomething, która działa na jakimś elemencie, to możesz przekazać do niej ten element jako argument:

function doSomething(element) {
   element.style.color = 'red';
}

wtedy sam masz kontrolę nad tym, gdzie i jakie referencje do elementów są przekazywane do której funkcji.

To co mówi @LukeJL wyżej to jest bardzo dobry pierwszy krok; powinieneś zrobić dokładnie tak jak jest napisane wyżej.

Tylko uwaga ode mnie; to co mówi @LukeJL to prawda; ale też nie znaczy że każdy "złapany" element powinien być porozrzucany po całej aplikacji; tylko w tej w której jest UI. Jak masz pliki np ui.js, main.js i ajax.js, to tylko ten ui.js powinien o nich wiedzieć.

są Zmienne spoko globalne

@TomRiddle:

Raczej nikt nie robi dużych aplikacji korzystając bezpośrednio z DOM - bo umar by na XSSach - to pierwsze.

Bzdura. Tylko jeśli nie wiesz co robisz.

Bzdura. Możesz sobie wiedzieć co robić. W teorii jeśli nigdy się nie mylisz to możesz korzystać z DOM.
Doświadczenie pokazuje jednak, że ludzie zwykle się w końcu mylą. Co gorsza do zespołu przychodzą nowi ludzie, trzeba im robić szkolenia z pułapek, a oni i tak się potem wywalają po kilka razy na każdej minie.
Dodatkowo: kodowanie, z myślą, że każda linia to pole minowe to średnia przyjemność.

jarekr000000 napisał(a):

@TomRiddle:

Raczej nikt nie robi dużych aplikacji korzystając bezpośrednio z DOM - bo umar by na XSSach - to pierwsze.

Bzdura. Tylko jeśli nie wiesz co robisz.

Bzdura. Możesz sobie wiedzieć co robić. W teorii jeśli nigdy się nie mylisz to możesz korzystać z DOM.
Doświadczenie pokazuje jednak, że ludzie zwykle się w końcu mylą. Co gorsza do zespołu przychodzą nowi ludzie, trzeba im robić szkolenia z pułapek, a oni i tak się potem wywalają po kilka razy na każdej minie.
Dodatkowo: kodowanie, z myślą, że każda linia to pole minowe to średnia przyjemność.

Nope; stosujesz uproszczenie.

Stworzyć XSS możesz tylko w jeden sposób: kiedy niepoprawnie łączysz HTML + plain text. Kiedy łączysz HTML+HTML albo plain text + plain text, to nic zlego się nie może stać (w tym miejscu przynajmniej). To samo jest z resztą prawdziwe przy SQL Injection, kiedy łączysz SQL + plain text to masz SQL Injection. Kiedy łączysz Regexp + plain text to masz ReDos attack. Jeśli nigdy nie łączysz HTML'a z plaintextem, to nie masz się czego obawiać. Jeśli zawsze robisz element.innerHTML = something, a nigdy element.innerHTML to nie masz szans na XSS. Ale again; musisz wiedzieć co robić; rozumieć konswkwencje swoich działań; musisz wiedzieć jaka modyfikacja jest podatna na XSS, a jaka nie. Mówienie "Wszystko może spowodować XSS" to droga do nikąd.

Poza tym, to nie chodzi o DOM ani o web i XSS.

Prawdą jest że jak pracujesz z dowolnymi spójnymi formatami danych (jak np plain text i SQL, HTML i Markdown, dowolne właściwie tekstowe formaty, string i JSON), nie poprawnie jest ze sobą zintegrujesz, to dostaniesz buga. Czasem ten bug jest po prostu bugiem, czasem jest glitchem, czasem jest luką w bezpieczeństwie, czasem jest zagrożeniem performance'u.

• Przykładem niepoprawnego łączenia tekstu z HTML'em są glitche że widać > tekście, albo XSS
• Przykładem niepoprawnego łączenia tekstu z SQL'em są statement errory, syntax errory, gdzie polecenie się nie wykona; albo SQL Injection
• Przykładem niepoprawnego łączenia tekstu i JSON'a np (milion razy widzieliśmy np echo '{"' + key + '": "' + value + '"}';, jest to że często jak jest " w stringu, to nie jest on wyescape'owany, i mamy syntax error. Innym case'm jest to że nie są zaencodowane UTF-8, przez co mamy json'a {"key":"łść"}, który poprawny oczywiście nie jest, ale znajdą się ludzie którzy powiedzą że jest.
• Masa innych

Tak się zdarzyło że akurat przyłączyć coś do SQL'a i do HTML'a jest w miare łatwo, więc takie bugi są najczęstsze. Ale to wszystko różne strony tej samej monety, nie umiejętne obchodzenie się z formatami danych.

Doświadczenie pokazuje jednak, że ludzie zwykle się w końcu mylą. Co gorsza do zespołu przychodzą nowi ludzie, trzeba im robić szkolenia z pułapek, a oni i tak się potem wywalają po kilka razy na każdej minie.

No ale co w tym dziwnego; to samo jest prawdą w każdej innej dziedzinie, nie tylko w IT.

Stworzyć XSS możesz tylko w jeden sposób: kiedy niepoprawnie łączysz HTML + plain text

Jeśli masz aplikację, w której korzystasz z DOM do renderowania to prawie cały cały twój output tak wygląda. Najwyżej nie wprost.

Moja teza jest taka - zamiast chodzić po polu minowym i rozwijać umiejętności saperskie można po prostu te pola omijać.
W każdym z podanych przez Ciebie przykładów injectionów frameworki (templatowe) zajmują się ogarnianiem eskejpowania.
W przypadku HTML jest to szczególnie istotne, bo mamy przynajmniej 5 różnych typów eskejpowania jakie należy stosować, w zależności od kontekstu - naprawdę łatwo się pomylić.

Dlatego uważam, że regularne korzystanie z gołego DOM w większym projekcie to sabotaż. Podobnie jak sklejanie SQLi.
Można to robić w wyjątkowych sytuacjach - powiedzmy raz na dwa tygodnie.

jarekr000000 napisał(a):

Moja teza jest taka - zamiast chodzić po polu minowym i rozwijać umiejętności saperskie można po prostu te pola omijać.

Wiedza nt tego co można a co nie można jest kluczowa; raz nabyta z Tobą zostaje, kiedy się już nauczysz co może coś zepsuć a co nie, to już będzie potem prosto.

To nie jest tak, że jak skorzystasz z biblioteki to ona machnie magiczną różdżką, i już możesz być bezmuzgiem który tylko jej użyje. Nawet jak korzystasz z perfekcyjnego narzędzia, musisz mieć z tyłu głowy to co on za Ciebie robi; i co mogłoby się stać jeśli byś go nie użył; ewentualnie co musiałbyś sam zrobić, żęby znaleźć alternatywę.

Dodatkowe biblioteki owszem, są pomocne w utrzymaniu; ale nie są cudownymi dżinami dzięki którym amator lub ktoś bez know-how może być tak samo wydajny jak ekspert.

W każdym z podanych przez Ciebie przykładów injectionów frameworki (templatowe) zajmują się ogarnianiem eskejpowania.
W przypadku HTML jest to szczególnie istotne, bo mamy przynajmniej 5 różnych typów eskejpowania jakie należy stosować, w zależności od kontekstu - naprawdę łatwo się pomylić.

To prawda; jeśli masz do dyspozycji bibliotekę do UI, która to zrobi za Ciebie, to możesz jej użyć.

Ale:

• Po pierwsze, nie wszystkie biblioteki są dobre, i nie escape'ują wszystkie w 100% przykadków. Jeśli nie masz tej "saperskiej wiedzy", to możesz wpaść w pułapke libki. Taki React jest bardzo bezpieczny pod tym względem, ale nie wszystkie takie są.
• Po drguie, nie zawsze masz możliwość pracy z taką libkę. Możesz trafić na zadanie w legacy projekcie; i jedyne co Cię wtedy może uratować to ta saperska wiedza
• Po trzecie, raz nabyta wiedza saperska (jak to nazwałeś) jest tranzytywna do każdej innej technologii na świecie, nie ważne czy to DOM, JSP, balde, twig, czy jakiekolwiek inne rozwiązanie do tego typu rzeczy. Polegając na bibliotece, ograniczasz się tylko do niej.

Dlatego uważam, że regularne korzystanie z gołego DOM w większym projekcie to sabotaż. Podobnie jak sklejanie SQLi.

Jeśli mówiąc "sabotaż" masz na myśli podatność na XSS, to podtrzymuje zdanie - Tylko wtedy jeśli nie wiesz co robisz.

Jeśli móiąc "sabotaż" masz na myśli kod niskiej jakości, to zgadzam się. Ale nie dlatego że jesteś podatny na XSS przez to; tylko dlatego że zbyt związałeś swoją plikacje ze szczegułem implementacyjnym. Jeśli staje się to powtarzalne i uciążliwe, to należy to albo wydzielić, albo napisać swoje rozwiązanie, albo skorzystać z istniejącego; wtedy kiedy będzie ku temu faktyczny powód.

Mam wrażenie że pomyliłeś podatność na błędy w bezpieczeństwie z utrzymywalnością aplikacji.

@TomRiddle: W zespole możesz być tym ekspertem i mieć 15 lat doświadczenia ale przyjdzie osoba, która ma 2 lata doświadczenia coś pominie i masz podatność. A Ty nawet nie będziesz o tym wiedział bo przerzucą Cię już do innego projektu. W idealnym świecie, każdy ma tę wiedzę ale świat nie jest idealny a zwłaszcza gdy ktoś pyta o zmienne globalne - to już wskazuje, że nie ma 15 lat doświadczenia i może mieć braki.

W Twoim świecie byłoby 5% programistów z obecnej puli bo reszta by się nie nadawała ale w tym świecie nie miałbyś 90% aplikacji, które aktualnie istnieją.

anonimowy napisał(a):

@TomRiddle: W zespole możesz być tym ekspertem i mieć 15 lat doświadczenia ale przyjdzie osoba, która ma 2 lata doświadczenia coś pominie i masz podatność. A Ty nawet nie będziesz o tym wiedział bo przerzucą Cię już do innego projektu.

Noi często dokładnie tak właśnie jest. Amatorzy popełniają błędy, bo nie wiedzą co robią. Dokładnie to się staram wykazać przez całą rozmowę.

Pracowanie z gołym DOM'em jest niebezpieczne tylko wtedy kiedy nie wiesz co robisz; i osoby z 2-letnim doświadczeniem podpadają w tą kategorię, tych którzy nie wiedzą co robią.

Jeśli nie jesteś amatorem, wiesz co robisz; i wiesz co może skutkować XSS'em a co nie, to nie masz się czego obawiać. Inna sprawa, że kiedy projekt rośnie trzeba dołożyć starań żeby interakcję z UI'em jakoś trzymać w ryzach, utrzymywalną; ale to nie oznacza oderwania się tego tego, że trzeba wiedzieć czym XSS i jak sobie z tym radzić. Biblioteki to nie sposób żeby wrzucić amatorów do projektów spokojnym, że już nic nie zepsują, bo to się stanie prędzej czy później. Jedyną tarczą przeciwko temu jest ich edukacja, mówienie co jest czym.

W Twoim świecie byłoby 5% programistów z obecnej puli bo reszta by się nie nadawała ale w tym świecie nie miałbyś 90% aplikacji, które aktualnie istnieją.

W moim świecie to znaczy w jakim, bo nie rozumiem? :D

Chodzi mi o to, że uważasz za amatorów osoby, które mają kilka lat doświadczenia i są w stanie przeoczyć XSS

anonimowy napisał(a):

Chodzi mi o to, że uważasz za amatorów osoby, które mają kilka lat doświadczenia i są w stanie przeoczyć XSS

Przeoczyć jeszcze bym zrozumiał; każdemu się zadarza coś przeoczyć.

Ale co innego jest przeoczyć, a co innego nie zdawać sobie sprawy z tego co może powodować XSS a co nie.

co innego nie zdawać sobie sprawy z tego co może powodować XSS a co nie

Ciekawe ile osób zdaje sobie sprawę z takich cudów jak mutation XSS. Ty chyba nie, skoro piszesz, że HTML+HTML nie może zrobić nic złego :) Podpowiem: przeglądarski są dość skomplikowanym ustrojstwem i jak robisz .innerHTML=cośtam wcale nie oznacza że to cośatm będzie tam wrzucone verbatim tak jak masz w kodzie. Przeglądarka moze sobie zmienić kolejność tagów, albo je podomykać, albo zrobić jeszcze inne cyrki. Polecam poczytać np. https://securityboulevard.com/2020/07/mutation-cross-site-scripting-mxss-vulnerabilities-discovered-in-mozilla-bleach/

Shalom napisał(a):

co innego nie zdawać sobie sprawy z tego co może powodować XSS a co nie

Ciekawe ile osób zdaje sobie sprawę z takich cudów jak mutation XSS. Ty chyba nie, skoro piszesz, że HTML+HTML nie może zrobić nic złego :)

Słyszałem o mutation XSS; ale mamy chyba na niego odmienne zdanie. I mi chodziło o to, że HTML1+HTML2 nie może zrobić nic złego, zakładając oczywiście że HTML1 osobno i HTML2 osobno są git, wiadomo że gdyby w tym HTML2 sobie siedział alert("you have been hacked"); to wtedy co innego.

Podpowiem: przeglądarski są dość skomplikowanym ustrojstwem i jak robisz .innerHTML=cośtam wcale nie oznacza że to cośatm będzie tam wrzucone verbatim tak jak masz w kodzie. Przeglądarka moze sobie zmienić kolejność tagów, albo je podomykać, albo zrobić jeszcze inne cyrki. Polecam poczytać np. https://securityboulevard.com/2020/07/mutation-cross-site-scripting-mxss-vulnerabilities-discovered-in-mozilla-bleach/

To prawda; przeglądarka robi różne machloje, ale ona zawsze będą zgodne z HTML'em (chyba że istnieje bug w przeglądarce); i jeśli tylko dasz im poprawnego HTML'a to zrobią z nim nic nieszkodliwego.

W artykule który podlinkowałeś istnieje pewna manipulacja; ponieważ ktoś tam dokleja HTML <noscript><a title="</noscript><img src=x onerror=alert(1)>, co przeglądarka potem błędnie buduje jako <noscript> oraz <img z JS'em.

Problem polega tylko na tym, że <a title="</noscript> to nie jest poprawny HTML, bo znak < ani > nie może wystąpić w atrybucie. Żeby to był poprawny HTML to musiałoby to być zapisane <a title="&gt;/noscript&lt;" (wow, encje w atrybutach, dziwne wiem).

Więc, oczywiście że jak masz Bubu html 1 + bubu html2 to może Ci wyjść bubu HTML ;>

Od razu odpowiadam na pytanie; że jeśli już masz taki niepoprawny HTML <a title="</noscript> , który chciałbyś gdzieś wkleić; to nie w momencie klejenia go jest dupa; ani nawet nie kiedy robisz eleme.innerHTML = , tylko w momencie w którym go dostałeś skądś. Albo, jeśli sam go zbudowałeś, to niepoprawnie go zbudowałeś; albo jeśli przjmujesz od kogoś input HTML to niepoprawnie go zparsowałeś; właśnie dlatego że mogą wystąpić takie kwiatki jak sam podlinkowałeś, z mutation XSS; bo dopuściłeś Tag'a <img onerror do swojego inputa traktowanego jak HTML.

Mam pytanie do @Shalom.

Czy powiedziałbyś, że stwierdzenie Nie znam HTML'a i wszystkich kruczków DOMu, więc skorzystam z pufiera jest tożsame koncepcyjnie z powiedzeniem Nie znam niemieckiego, więc użyję tłumacza google (lub innego)?

Bo jeśli tak, to zgadzam się - jeśli nie znasz języka; lepiej się posiłkować narzędziem, które, jest spora szansa wie lepiej niż Ty.

Tylko pytanie czemu pracujesz w środowisku (np. niemieckim) jeśli nie znasz dobrze języka? :D

Dążę do tego, że podobnie jak z językiem; jeśli nie jesteś profcient; to powinieneś się dokształcić; a zanim to zrobisz, to nie powinieneś pracować w środowisku w którym ktoś od Ciebie wymaga takiej wiedzy; bo gość który pisze z tłumacza prędzej czy później coś palnie.

jest tożsame koncepcyjnie z powiedzeniem

Nie jest. Nie da się być specjalistą we wszystkim. Jak masz do napisania umowę, to może warto wynajać do tego prawnika? Jak masz do zrobienia oficjalne tłumaczenie dokumentów to może lepiej wziąć tłumacza? Świat jest dziś zbyt skomplikowany żeby być człowiekiem renesansu i znać się na wszystkim. Specjaliści mają zwykle wąskie specjalizacje, bo nie da się fizycznie porządnie poznać zbyt dużego zakresu. I jeśli komuś się wydaje że on zna, to ma racje: wydaje mu się.

Shalom napisał(a):

Nie jest. Nie da się być specjalistą we wszystkim. Jak masz do napisania umowę, to może warto wynajać do tego prawnika? Jak masz do zrobienia oficjalne tłumaczenie dokumentów to może lepiej wziąć tłumacza? Świat jest dziś zbyt skomplikowany żeby być człowiekiem renesansu i znać się na wszystkim. Specjaliści mają zwykle wąskie specjalizacje, bo nie da się fizycznie porządnie poznać zbyt dużego zakresu. I jeśli komuś się wydaje że on zna, to ma racje: wydaje mu się.

To prawda; zgadzam się, nie da się być człowiekiem renseansu.

bo nie da się fizycznie porządnie poznać zbyt dużego zakresu. I jeśli komuś się wydaje że on zna, to ma racje: wydaje mu się.

Zależy jak definiujesz "duży". Z dziedziny całej IT; czy nawet programowania, faktycznie na pewno nie. Ale jeden format taki jak HTML, moim zdaniem da się ogarnąć do perfekcji, przynajmniej w takiej wersji jakiej jest, bo wiadomo że z update'ami taka wiedza może stać się obsolete; tak samo jak biblioteki do niego.

Poza tym, wydaje mi się że mamy niezrozumienie.

To co ja się starałem przekazać w poprzednim wątku; to to że jeśli ktoś mówi że "operowanie na gołym domie", czyli innymi słowy korzystanie z dosyć skomplikowanego API; "to sabotaż", bo możemy się narazić na XSS; to trochę nie do końca prawda; bo jesli ktoś jest zaawansowany w tej dziedzinie, zna zarówno API jak i sam format (HTML) to nie ma się czego bać, bo taka wiedza wystarczy. I odpowiadając, nie wliczam w to osób którym się tylko wydaje że są mistrzami; tylko o osobach które na prawdę wiedzą co robią.

Naiwnością jest myśleć, że umie się więcej niż umie na prawdę; ale taką samą naiwnością jest myśleć że umie się mniej niż się umie.

Shalom napisał(a):

Tylko że im więcej takiego kodu sklejanego na kolanie, zamiast użycia dobrze przetestowanej biblioteki, tym ta szansa jest większa ;)

Mam wrażenie że powstało takie dziwne przekonanie, na froncie i w innych dziedzinach. Że jesli pracujemy z czymś często; np z klejeniem HTML'a i plain-textu; to może się wytworzyć takie przekonanie że zrobienie tego bezpiecznie i dobrze powinno być proste. I na podstawie tego przekonania szukamy bibliotek i purifier'ów, żeby uświadczyć nas w tym przekonaniu że to może być jednak proste.

No, może i powinno; ale nie jest. Takie samooszukiwanie się trochę, nie uważasz?

@TomRiddle:

Wiedza nt tego co można a co nie można jest kluczowa; raz nabyta z Tobą zostaje

no nie wiem. różne przeglądarki, różne parsery, różne bugi.

Po trzecie, raz nabyta wiedza saperska (jak to nazwałeś) jest tranzytywna do każdej innej technologii na świecie, nie ważne czy to DOM, JSP, balde, twig, czy jakiekolwiek inne rozwiązanie do tego typu rzeczy. Polegając na bibliotece, ograniczasz się tylko do niej.

nie sądzę, bo zazwyczaj opiera się ona na tiny, implementation details.

Zależy jak definiujesz "duży". Z dziedziny całej IT; czy nawet programowania, faktycznie na pewno nie. Ale jeden format taki jak HTML, moim zdaniem da się ogarnąć do perfekcji, przynajmniej w takiej wersji jakiej jest, bo wiadomo że z update'ami taka wiedza może stać się obsolete; tak samo jak biblioteki do niego.

Biblioteki będą obsolete, jednakże te najpopularniejsze pewnie relatywnie szybko zostaną zpatchowane i opublikowane (likely), a twój customowy kod w ostatnich N firmach dostanie patcha? (unlikely)

@Shalom:

oczywiście, a XSSy w jakimś google search to sabotaż masonów i cyklistów
Tylko że im więcej takiego kodu sklejanego na kolanie, zamiast użycia dobrze przetestowanej biblioteki, tym ta szansa jest większa

zagram diabła i przypomnę że:

Co było przyczyną błędu? Problem w bibliotece Closure. We wrześniu usunięto w niej pewne walidacje („bo rozwalał się interface użytkownika” :) – pod koniec lutego 2019 przywrócono je, z dość niewinną adnotacją:

https://github.com/google/closure-library/commit/c79ab48e8e962fee57e68739c00e16b9934c0ffa