Nyílt forráskód vagy zárt forráskód

Mit válassz a weboldaladnak? Pro és kontra sok cikket olvashatsz a nyílt forráskód és a zárt forráskód előnyeiről, hátrányairól a weben, vannak akik nyílt forráskódra esküsznek, míg mások a zártra. Most megpróbálom tárgyilagosan, független véleményekkel, példákkal, saját tapasztalatokkal alátámasztva elemezni az előnyöket és hátrányokat. Ezzel az alap ellentéttől kicsit mélyebbre ásunk. Bekukkantunk még a hackerek lelkivilágába is.

Kezdjük az elején! Kell valaki, aki elkészíti a honlapot.

Webfejlesztő, webprogramozó, sitebuilder, vérpistike.

Vannak kiválóak, jók, kevésbé jók és kontárok is.

Vérpistike összerak neked egy weboldalt ingyenes sablonból, ingyenes alkalmazásokkal, 20-30-40e forintért. Extra igényed ne legyen, mert nem tudja teljesíteni. Átadja a honlapot és viszlát.  Nagy valószínűséggel, ha szükséged lenne rá, akkor sem éred el többé.

A sitebuilder klasszikus értelemben a designer által megálmodott designból működőképes sablont készít, amiből majd a webprogramozó készíti el a működő weboldalt. A jó sitebuilder ismeri a css, html5 trükköket, minimum tisztában van azzal, hogy mi kell a jó SEO-hoz.  Sok múlik rajta a weboldal betöltési gyorsaságának szempontjából. Szépérzéke meghatározó lehet a felhasználói élmény tekintetében.
Bár a legtöbb honlap kész sablonra épül, még itt is 99%-ban szükség van sitebuild munkára, mert nem responsive a sablon vagy mert néhány elem szétesik, összecsúszik mobil nézetben.

Ma már egyre összetettebb a sitebuilderek feladata. Gyakran várunk el tőle programozói munkát is, programhibák javítását is, főleg a kész tartalomkezelő rendszerek esetén.  Ezért egy kicsit a programozáshoz is értenie kell. És itt lehet megrendelői oldalon nagyobbat bukni. Ha nem körültekintően választ az ember. Sok a magát szakértőnek képzelő, aki a már kész kódrészletekből össze tud rakni „valamit”, ami nagyjából az elvárásoknak megfelelően működik, de ha valami extra igényed van, azt már nem tudja teljesíteni. (Olyanról is tudok, aki WordPress szakértőnek tartja magát, de kijelentette, hogy ő nem tud a kódsorokba belenyúlni.)

A webprogramozó felel azért, hogy működőképes legyen a weboldal. Klasszikus értelemben. Csakhogy a programozó feladata nemcsak abból áll, hogy kódsorokat ír. Sőt, ez teszi ki a munkája kisebb részét. Tervez, tervez és tervez. A munkája főleg: php (szerveroldali programozás), mysql (adatbázis programozás), javascript (kliensoldali programozás), stb. És ezek működésének a megtervezése. Azaz strukturált programkódokat készít.

És van még egy kategória, a full stack developer. Ő az, aki több ember munkáját végzi el egy személyben, a frontend-hez és backend-hez is ért. Kevés van belőlük és a kevés között is kevés az igazán mindenhez jól értő szakember.

A webfejlesztő pedig az, aki „egy kicsit ebből is, egy kicsit abból is”. HTML, CSS, PHP, SQL, Javascript… Ami szükséges a munkájához. Ma már általában egy-egy részterületre specializálódnak, így vannak WordPress fejlesztők, Joomla fejlesztők, Magento fejlesztők és így tovább.  Aki huzamosabb ideig a szakmában akar maradni, azt a területet, amire specializálódik oda-vissza kiismeri és folyamatosan képben van az adott tartalomkezelő rendszer fejlődésében. Nyilván nem egyik napról a másikra, így egy kezdő nem tud olyan minőséget biztosítani számodra, mint egy néhány éve a szakmában lévő vállalkozás.

A biztonság a weben is fontos.

Tisztázzuk: 100%-os biztonság nincs a weben.

De a biztonság fontos. Még akkor is, ha csak a saját adataid vannak tárolva, de ha ügyfelek adatai is, akár még csak az email címük is, akkor még fontosabb. A hackerek folyamatosan keresik a hibákat, biztonsági réseket. Ezért lehetőleg be kell zárni előttük a kapukat. Erre zárt forráskód esetén a forráskód auditálása és a talált hibák, rések javítása lehet megoldás (hacsak nem értesz annyira a programozáshoz, hogy magad is megtaláld a biztonsági réseket). Nyílt forráskód esetén a weboldal biztonságának megerősítése bővítményekkel, .htaccess szabályokkal, több szintű beléptetéssel, stb.

Mit is csinálnak a hackerek?

Fehérkalapos és feketekalapos hacker?

Károkozás szerinti csoportosítása a hackereknek. A fehérkalapos nem okoz kárt. Még az is előfordul, hogy javítja a hibát, de legalábbis értesíti a talált hibáról a weboldal gazdáját (pl. a Prezi esete is ide tartozik). A célrendszert véletlenszerűen választja ki. Általában egyedül „dolgozik”.
(Az etikus hacker pedig az a személy, aki a megrendelő – weboldal tulajdonos – tudtával és megbízása alapján dolgozik, teszteli a rendszer feltörhetőségét.)
A feketekalapos hacker kártékonykodik. Megszerzi a számára értékes adatokat, esetenként lecseréli a weboldalt, hátsó kaput hagy maga után, hogy később könnyen vissza tudjon jönni. Vagy akár teljesen átveszi az irányítást a weboldalad fölött. Rendszerint csoportban, szervezetten dolgoznak. (Egyébként pontosabban crackernek kellene nevezni azokat, akik ártó szándékkal törik fel a rendszereket.)

Hogyan dolgozik a kártékony hacker?

Az internetes bűnözés kifizetődő üzlet. Ezért rengeteg script, program létezik, ami hibákat, biztonsági réseket keres. Ezeket a programokat hacker fórumokon meg is osztják egymással. Vannak olyan adatbázisok is, ahol a tört weboldalak vannak listázva, illetve olyanok is, ahol a hiba/rés mibenléte is megismerhető számukra.
Ritka eset az, amikor ott ül a gép előtt, és kézzel próbálja feltörni a honlapokat. Általában scripteket „küld” a szerverekre és azzal keresi a törhető oldalakat.
Néha az is előfordul, hogy a szerveroldali szoftvereket törik, pl. ha a tárhelyszolgáltató hagy valahol egy kiskaput. Még ritkábban az is előfordul, hogy a szerveroldali szoftverben van sebezhetőség (volt már a népszerű cpanelben is). Ha pedig szerveroldalról jön a hacker, akkor lehet bármilyen drága, lehet bármilyen biztonságosnak hitt zárt forráskódú weboldalad…

Milyen a hackerek lelkivilága?

Adott egy nyílt forráskódú rendszer és egy zárt forráskódú.

A nyílt forráskód ott hever a hacker orra előtt, szabadon megkeresheti benne a hibákat, a támadási lehetőséget és – ha nem elég védett a weboldal -, sikeresen ki is használhatja. Kihívás ez neki? Nem! Egy nyílt forráskódú rendszer feltörésével nem verheti a mellét, hogy milyen ügyes hacker is ő? Épp ezért előfordul az is, hogy a hacker maga javítja a hibát. Ez utóbbi inkább dicsőség számára.

A zárt forráskód feltörése kihívás? Igen! próbálkozni fog vele? Igen! Hibátlan, feltörhetetlen a zárt forráskód? A cikkben felsorolt példák is azt mutatják, hogy nem. Döngetheti a mellét, ha bejut egy zárt forráskódú rendszerbe? Igen.

A hackerek számára az a kihívás, hogy megtalálják a szoftveren a kiskapukat és ezen átjussanak. Persze a kártékonykodó fajtájuk a főkapura is ráereszti a scriptet, ami pl. login url-eket keres pl. admin/admin felhasználó/jelszó párosítással.

Nyílt vagy zárt forrású weboldalad legyen?

Ennyi bevezető után nézzük a nyílt és zárt forráskód alap ellentétét.

Az általános összehasonlításban a nyílt forráskód javára írják, hogy

• könnyen, gyorsan telepíthető
• nem igényel programozói tudást
• olcsó az egyedihez képest
• rengeteg kiegészítő, extra van hozzá

A nyílt forráskód hátrányának szokták emlegetni, hogy

• hibák lehetnek a frissítéskor
• az internetes bűnözők támadhatják
• sok fájlt és kódot tartalmaznak, amik lassíthatják, így hátrébb kerül a találati listán
• nehezebben optimalizálhatók

A zárt forráskód előnyei között sorolják, hogy

• olyanra alakítod, ami megfelel az elképzeléseidnek
• könnyebben optimalizálható
• nagyobb biztonságot nyújt
• nem lassítják fölösleges elemek

A zárt forráskód hátrányaként emlegetik:

• drága
• elkészítése hosszadalmasabb
• nincsenek biztonsági frissítések
• új funkciók beépítése fejlesztőt igényel

Mi a helyzet a nyílt forráskóddal?

WordPress, Drupal, Joomla, Opencart, Magento, és még számtalan rendszer. Rengeteg programozó fejleszti, nem egy-két ember vagy egy kis csapat. Sok szem sokat lát. Ha előjön egy hiba, arra nagyon gyorsan reagálnak, gyorsan javítják, van, hogy a hiba kiderülését követő 1-2 órán belül javításra is kerül.

Könnyen, gyorsan telepíthető, az alapvető beállításához sem szükséges szaktudás. De ha már funkcionálisan módosítani szeretnéd, akkor bizony kell némi programozói tudás. Ha csak a designt szeretnéd módosítani, akkor néha elég a css ismeret is. Valóban rengeteg kiegészítő van hozzájuk ingyen vagy pénzért, így funkcionálisan alaposan felturbózhatóak. Mivel keretrendszerek, gyakran valóban többet tudnak, mint amire éppen szükséged van. A fölösleges funkciók azonban letilthatók (ehhez is kell már némi szakértelem).
Valóban sok fájlt és kódot tartalmaznak, azonban ez az alaprendszert nem lassítja. A rosszul megválasztott, gyenge minőségű kiegészítők használata szokott problémákat okozni.

Ezért sem árt megfontolnod, hogy kire bízod a honlapod elkészítését. Kaphatsz már ilyen honlapot 30-40 ezer forintért is, alapfunkciókkal, ingyenes sablonnal, esetenként szedett-vedett bővítményekkel. Ahol a rengeteg lehetőség közül vagy jól választ a honlap készítője és nem fog 120 adatbázis lekérést futtatni egy alkalmazás, sablon, vagy nem jól választ ki és valóban belassul a honlapod. Nem utolsósorban azt se felejtsük el, hogy nagyon sok múlik a szoftver mögött lévő webszerveren, a tárhely minőségén is. Egy túlterhelt szerveren szinte törvényszerűen lassúbb honlapot fogunk kapni.

Azt, hogy mi a megfelelő bővítmény egy-egy funkcióhoz, több, a funkcióra alkalmas bővítmény kipróbálásával lehet kideríteni. Hogy melyik sablon van jól megírva, a tapasztalatlan felhasználó valószínűleg nem tudja kiszűrni, főleg, hogy ma már egyik-másik funkciókban gazdag sablon akár több száz fájlból is áll. Ugyanígy zárt forráskódnál is ugyanazt a funkciót két programozó egyformán nem írja meg. A tapasztaltabb jobb kódsorokat fog írni. Tehát leszögezhetjük, hogy a tapasztalati részt nem lehet kispórolni. Sem nyílt forráskód esetén, sem zárt forráskód esetén.

Nehezen seozható. Válaszul álljon itt két megtörtént eset, egyik történet zárt forráskódú, másik nyílt forráskódú weboldallal kapcsolatos.

Kaptunk egy megkeresést SEO tanácsadásra egy zárt forráskódú weboldalra. A szokásos módon felmértük, elemeztük a weboldal állapotát. Majd megszületett a válasz: „…felelősséggel nem tudunk árajánlatot adni a hibák megszüntetése előtt, jelenlegi állapotában csak a Google Adwords kampányt tudjuk nyugodt lelkiismerettel ajánlani…”
Az oldalon nagyon súlyos szerkezeti hibák voltak. A www és www nélküli elérésből fakadó duplikáción kívül egy-egy aloldal 5-6 URL-en keresztül is elérhető volt, azaz 10-12-szeres duplikációkat találtunk más jellegű szerkezeti hibák mellett. Gyakorlatilag olyan állapotban találtuk a honlapot, hogy azt erősen fenyegette egy Panda büntetés.
A honlap részletes elemzése és a fejlesztők részére készített javítási útmutató segítségével az eredeti fejlesztők helyett a saját informatikusaik először rendbetették a honlap szerkezetét, majd készült Adwords kampány is.

Egy másik ügyfelünknek WordPressben készült weboldalát 3 héten belül visszahoztuk az első-második oldalra, ami előtte jó pozícióból hirtelen eltűnt a találati listáról (első 1000 találatról beszélünk és ebben az esetben is szerkezeti problémákat találtunk, még nem volt büntetésben az oldal). Külső „javítás” annyi volt ebben a történetben, hogy 2, azaz kettő darab honlapra mutató linkre figyelmen kívül hagyást kértünk a Google-tól. Azaz a nyílt forráskódú rendszerek is rendkívül jól optimalizálhatók, csak tudni kell, hová kell nyúlni.

A frissítési hibák leginkább régi, illetve gagyi kódolású bővítmények, sablonok kódolásából fakadnak. Leginkább azokat a honlapokat érinthetik, amit a tulajdonos maga rak össze találomra választott kiegészítőkkel, vagy költséghatékonysági okból vérpistikét kéri fel a honlap elkészítésére, ritkábban: 1- 2 hete működő, tapasztalatlan vállalkozóval készítteti. Tagadhatatlan, vannak nagyon gyenge minőségű kiegészítők a nyílt forráskódú CMS-ekhez, és ugyanígy vannak extra minőségűek is. Ez utóbbit már a pár éves tapasztalattal rendelkező honlapkészítő cégek jól ismerik és csak a megbízható alkalmazásokat használják az ügyfelek honlapjainál.

Lehet olvasni olyan véleményt is, aki szerint, ha valamit belefejlesztünk, azt közkinccsé kell tenni. Ez így leírva hülyeség. A GPL (General Public License) nem egészen erről szól… Először is, a nyílt forráskódú szoftver motorjába nem szoktunk belefejleszteni, hiszen azzal, ha belefejlesztenénk, azt érnénk el, hogy nem frissíthetnénk, amikor kijön egy frissítés, illetve, ha mégis frissítünk, a belefejlesztett elemeket minden frissítésnél újra meg újra bele kellene dolgozni. Másodszor, amit saját használatra fejlesztetsz, az bizony a tiéd (a GPL licenc alatt kiadott szoftver szabadon módosítható, továbbfejleszthető). Sőt, ha az alaprendszert az igényeid szerint módosíttatod, az is teljesen a tiéd, soha senkivel nem kell megosztanod.

Mi történik, ha megszűnik a honlapot készítő cég, eltűnik a honlapot készítő vállalkozó? Gyakorlatilag annyi, hogy keresel egy másik szimpatikus, hozzáértő céget, aki az adott nyílt rendszerre specializálódott.

Mi a helyzet a zárt forráskóddal?

1-2 ember vagy egy csapat fejleszti. Ha vannak benne hibák, azok nem nagyon kapnak nyilvánosságot. Így nem tudod, hogy van-e benne hiba. Értened kell a programkódhoz, ha tudni szeretnéd, hogy van-e benne hiba vagy rendszeresen auditáltatni a kódot. Csak így tudod kideríteni, van-e benne és ha van, mennyire súlyos hiba.

Mivel néhány ember fejleszti, így hosszadalmasabb egy zárt forráskódú rendszer elkészítése. Annak ellenére is, hogy legtöbbször itt sem nulláról indul a fejlesztés, hanem már meglévő modulokból. De ha éppen az igényeidnek megfelelő modul nincs még, akkor azt le kell fejleszteni, tesztelni és csak ezután állhat munkába. És minden egyes későbbi fejlesztésért/módosításért is (mélyen) a zsebedbe kell nyúlnod.

Leggyakoribb érv mellette, hogy a zártság miatt nehezen törhető. Ezt a webrontgen.hu szakemberei cáfolják. A profitline.hu-n olvasható cikkből kiderül, hogy közepes vagy súlyos hibáktól tátongó rések vannak a vállalkozások honlapjainak többségében. A tesztelés során ellenőrzött honlapok esetében az derült ki, hogy míg az egyedi fejlesztésű honlapok több mint fele sérülékeny, nyílt forráskód esetén ez az arány 20-29 százalék. Ha csak a súlyos hibákat nézzük, akkor a teszt még rosszabb eredményt hozott az egyedi fejlesztéseknek, ott kb. a hibák harmada súlyos besorolású, míg nyílt forrásnál a tizede.

„Tévhit, hogy az egyedi fejlesztésű honlapok biztonságosak. Míg az egyedi honlapokat egy-két programozó készíti, addig például a nyílt forráskódú WordPress tartalomkezelő motoron több ezer fejlesztő közössége dolgozik folyamatosan, ami törvényszerűen biztonságosabb rendszert eredményez. A forráskódot bárki megnézheti, így sokkal gyorsabban kiderülnek a hibák, amiket nagyon gyorsan ki is javítanak.” – mondta Csermák Szabolcs, a webrontgen.hu szakembere.

Ehhez itt hozzáteszem, hogy a webszerverek túlnyomó többsége nyílt forráskódú Linuxon fut, alacsony Windows alapú szerverek aránya. Ha a zárt forráskód a biztonságosabb, akkor ennek nem fordítva kellene lenni? Itt egy cikk, ami szépen szembeállítja a nyílt és zárt forráskódot (konkrétan a Linux és a Windows biztonságát, angolul). Itt pedig egy régi cikk, amiből azt tudod meg, hogy a nagyobb hazai cégek úgy vélték már évekkel ezelőtt, hogy a saját, több szerveres IT infrastruktúrájukat illetően jobban járnak a nyílt forráskódú szoftverekkel.

Ebből látszik, hogy egy jól felépített nyílt forráskódú rendszer biztonságosabb, mint az egyedi fejlesztés. Hangsúlyozom: csak a jól felépített. Lehet a nyílt forráskódú rendszereknél is szarvashibákat véteni.

Nem lehet tagadni, hogy sok nyílt forráskódú honlapot feltörnek. Azonban ennek az alaprendszerek biztonságához nem túl sok köze van. A feltörés oka sajnos legtöbbször a felhasználó gondatlanságára vezethető vissza. Gyakran telepít olyan kiegészítőket, sablont, ami nem jól van programozva, sebezhetőséget tartalmaz. Mindez leginkább a „sprórolásra” vezethető vissza. Hiszen az ingyenesen használható rendszert minimális hozzáértéssel lehet telepíteni, így gyakorlatilag a domain és tárhely költségén is lehet honlapja a vállalkozásnak. Azonban a hozzáértés hiányából fakadó nem kellő körültekintés később biztonsági problémákat okozhat, és sokszor okoz is.

A nyílt forráskódú rendszer esetén a keretrendszert fejlesztik. Ha találnak benne hibát, sebezhetőséget, azt legtöbbször olyan gyorsan javítják, hogy a hacker robotja nem lesz elég gyors, hogy kihasználja. Míg zárt forráskód esetén, ha valaki talál valahol egy rést, ahol bejuthat, az nagy eséllyel nemhogy 1-2 nap alatt nem lesz javítva, de ha elég ügyesen tünteti el a saját nyomait, jó eséllyel észre sem fogod venni, így a hacker akár hosszú évekig ki-be járkálhat a honlapodon.

Hogy melyik a nagyobb biztonsági kockázat? Felfogás kérdése, hogy ki mit gondol nagyobb kockázatnak.

A második leggyakoribb érv a zárt forráskódú weboldal mellett, hogy elérhetetlen a háttérben futó kód, csak a fejlesztő tudja módosítani. Van, aki megemlíti, hogy ez egyben hátrány is, hiszen más fejlesztőnek nem tudod átadni a honlap további fejlesztését, hiszen a fejlesztők védik a kódjaikat. Mivel a kód egyedi, a kód minősége, esetenként a dokumentációja is lehet kérdéses.

Tudni kell, hogy a hacker nem kódsorokat olvas, hanem sebezhetőséget keres. Nem a lakatokkal őrzött főbejáraton akar bemenni, hanem a hátsó nyitott kiskaput (vagy nagykaput) keresi. Pl. egyik módszer: űrlapmezőn keresztül megpróbál kódsort, adatbázis-kezelői utasítást futtatni. És ha a rendszerben ott a hiba, akkor a hacker által kiadott utasítás végrehajtásra is kerül. És vannak olyan scriptek, programok is, amik kifejezetten gyenge pontokat keresnek a weboldalakon.

Mi történik, ha megszűnik a honlapot készítő cég, eltűnik a honlapot készítő vállalkozó? Könnyen lehet, hogy bajban vagy. Nehezen találsz új fejlesztőt. Aminek több oka is van. Egyrészt az egyedi fejlesztésekre specializálódott szakemberek, főleg a jobb szakemberek, kifejezetten utálnak másnak a kódjaiban kotorászni. A gyengébb képességű pedig nem biztos, hogy át fogja látni. Nagyon kevés olyan fejlesztő van, aki megfelelően dokumentálja a saját kódjait. Ez is csak nehezíti a váltást. Másrészt az egyedi kódot rendszerint jogilag is védik, azaz nem adják át másnak továbbfejlesztésre. Még te is csak akkor kaphatod meg, ha benne van a szerződésben. Ebben az esetben dobhatod kukába a weboldalt és kezdheted újra a fejlesztését.

Hibátlan szoftvert akarsz a honlapod alapjának?

Az nehezen fog menni, mint nagyobb cégek példái mutatják. Hogy jön ide a Google, Twitter, Apple, Microsoft? Ők azok – a számtalan példa közül kiragadott – cégek, akik a fejlesztésekre nem forint milliókat, hanem dollár milliókat költenek, mégis…

Mégis, tavaly tavasszal olvashattál egy olyan sérülékenységről a Youtube körül, amit kihasználva bárki törölhette volna akár az összes videót. Történetesen itt nem sérülékenységről, hanem logikai hibáról volt szó, amit – a Google szerencséjére – egy jóindulatú hacker talált meg.

A Microsoft folyton csak felfedezett sebezhetőségeket toldoz-foltoz. Ki tudja, éppen most ki jár a gépeden, ki lopja az adataidat…

Nem olyan rég történt, hogy feltörték a Twittert is.

Vagy ott vannak az autók szoftverei. Jeep Cherokee, Tesla Model S. Kész élmény lehetett egy távolról leállítható-indítható autó.

Az Apple Activation Lock sérülékenysége is nyilvánosságot kapott.

Ezek a fenti példák is mutatják, hogy minden szoftverben ott van a hiba, mindegy, hogy nyílt vagy zárt forráskódú, mindegy, hogy a fejlesztése mekkora összeget emészt fel. Ezek a cégek azért váltak kiragadott példákká, mert nyilvánvaló, hogy nem középszerű, de mégcsak nem is szimplán jó, hanem válogatott programozókkal veszik körül magukat.

De ugyanígy szerencséjük volt a Prezi fejlesztőinek (tudod, hogy ez egy magyar startup?). Itt is egy hacker talált súlyos sebezhetőséget, majd kicsivel később egy újabbat. Amiket ők gyorsan javítottak is. Csak hogy magyar példa is legyen…

Az pedig, hogy hackerek találták meg a hibákat, jó példája annak, hogy több szem többet lát és annak, hogy bizony, a hackerek nemcsak a nyílt, de a zárt szoftverekben is keresik a támadhatóságot.

Mindez azt mutatja, nem biztos, hogy jobban jársz a zárt forráskóddal. Azt viszont eléred, hogy még te sem tudod, hogyan működik a honlapod, milyen hibák vannak benne.

Persze érthető, ha az egyedi CMS-t 1,5-2 év alatt lefejlesztő vállalkozásnak nem tetszik, ha a potenciális vásárlók nem a drágábbat választják. De el kell fogadniuk, hogy a piaci igények ebben a szegmensben is változnak. Minőséget mindenben lehet készíteni, nyílt forrásban és zárt forrásban is. Az elavult megoldásokat mindegyikben fejleszteni kell, ez alól az egyedi rendszerek sem lehetnek kivételek. És alkalmazkodni kell az ügyfelek igényeihez. Ez pedig zárt forráskódnál is magával vonja, hogy egyre nagyobb és nagyobb lesz a szoftver kódja.

Nyílt vagy zárt forráskódot válassz?

Azt már tudod, hogy hibátlan szoftver nincs, így ez nem lesz számodra szempont. A fő szempontod az lesz, hogy

• jobb a gyorsan nyilvánosságra kerülő hiba, sebezhetőség, ami lehet, hogy mire nyilvánosságra kerül, már javítva is van vagy
• jobb, ha még magad sem tudod, hogyan működik a honlapod és milyen sebezhetőségek vannak benne (vagy bevállalod a kód auditálás – általában pár százezres –  többletköltségeit).

Mi a nyílt forráskód mellett állunk. És ha profi nyílt forráskódú, szerkezetileg optimalizált honlapot akarsz, akkor bízz meg minket!