Tízből kilenc esetben a fenti reakciót tapasztalhatja az ügyfél, ha a megkeresett informatikai vállalkozással Joomla (Wordpress, Drupal) honlapot szeretne készíttetni.
De miért? Valóban ennyire gáz ezekkel a CMS rendszerekkel dolgozni? Valóban feltörnek 10 Joomla (Wp, Drupal) oldalból kettőt? Tényleg ennyivel biztonságosabb más, egyedi fejlesztésű motorral dolgozni? És vajon megéri e a sokszor tízszeres ár szorzó az egyedi fejlesztésért?
A rövid válasz a fenti kérdésekre egyértelműen az, hogy nem, de mint minden érmének, ennek is két oldala van. Az alábbiakban megkísérlem néhány bekezdésben, a laikus oldalgazdák számára is érthetően összefoglalni azt, hogy hogyan is működik az ilyesmi.
Amennyiben rögtön nagyvonalúan továbblépünk azon - az egyébként egyáltalán nem érdektelen - tényen, hogy a fejlesztőnek a saját rendszerét anyagilag sokkal jobban megéri értékesíteni, mint bármelyik "nyílt forrású" CMS-t, azt tapasztalhatjuk, hogy a webfejlesző cégek továbbra is gyanakvóak az ilyen oldalakkal szemben. Ez a gyanakvás sok lábon áll, és az esetek többségében meghatározhatatlan, a fő építőkövei mégis ugyanott gyökereznek:
- A fejlesztő nem ismeri annyira (vagy éppenséggel túl jól ismeri) az ingyenes CMS-t, hogy szívesen belenyúljon. A programozók mindig a saját kódjukat részesítik előnyben, nem pedig a másét. A legrosszabb munka az, amikor más szemetében kell turkálni – sokan ezért zsigerből elutasítják a CMS rendszereket.
- A többi fejlesztő tapasztalatai / publikált cikkek / esti sör melletti beszélgetés által ismételgetett „biztonsági zsolozsma” - szöget ütöttek a fejében. Több ezer veréb nem tévedhet alapon tényleg elhiszi, hogy a rendszer nem biztonságos, és mivel éppen ezért nincsenek tapasztalatai, ebben nem is kételkedik.
- A fejlesztő nem csak egy oldal külsejét látja: belát az egész mögé, és pontosan látja azt is, hogy az adott oldal nem készíthető el (biztonságosan?) a megrendelő kérése szerint az adott CMS rendszerrel.
Az első ponthoz nincs hozzáfűznivalóm: mindenki maga dönti el, hogy mivel hajlandó dolgozni és mivel nem. Ha valaki nem vesz francia kocsit, szíve joga eldönteni, és nem kell megmagyaráznia. Ezen túlmenően pedig az ilyen programozó valószínűleg tényleg elhiszi, hogy az általa létrehozott kód szuperbiztos, és soha senki nem fogja feltörni. (Ebben valószínűleg igaza is van).
A második pont viszont maga a dolog Achilles-sarka. Való igaz, hogy rossz híre van az open source CMS rendszereknek, és az is tény, hogy biztonságosság szempontjából van hová fejlődniük. A neten számtalan találatot kapunk, hogy hogyan kell feltörni a különböző WORDPRESS , DRUPAL és JOOMLA oldalakat, és ezen leírások egy része biztosan működik is – de csak bizonyos esetekben.
Ennek pedig egyszerű az oka, a leírt metódusok egytől-egyig általános hackelési technikák, amikkel gyakorlatilag bármilyen weboldalt fel lehet törni, de míg az egyéni fejlesztésű weblapok esetében a biztonsági rést kutatni kell, egy nyilt forráskódú oldal (és a telepített kiegészítők) egy egyszerű google kereséssel azonosíthatóak. 
WordPress oldalak listája a Google-ben
Ráadásul az említett CMS rendszerek használata esetén (az adott motor rendkívüli elterjedtsége miatt) ezek a „bizonyos esetek” rendkívüli gyakorisággal fordulnak elő, azaz sarkítva a dolgot: irtó könnyű fogást találni az oldalon.
Fontos megjegyezni, hogy az esetek többségében ilyenkor sem a CMS biztonsági hibájáról van szó, mivel a nagyobb keretrendszerek mindegyike óriási erőforrással dolgozik azon, hogy ilyen ne létezzen, hanem a telepített kiegészítők valamelyikéről derül ki, hogy az erősen sebezhető, esetleg egy harmadik szoftver (például az FTP kezelő) hibájából kikerült jelszavak keserítik meg a felhasználó életét.
A kutya ott van elásva, hogy míg az alaprendszerekben felfedezett hibákat az adott CMS mögött álló több ezres önkéntes fejlesztő - közösség szinte azonnal orvosolja, a feltelepített kiegészítők biztonságáról már jóval kevesebben gondoskodnak. Van ugyan (jobb-rosszabb) előszűrés a feltöltött kiegészítők között, ez azonban nem mindig elégséges, és extrém esetben akár az is előfordulhat, hogy a kevésbé elterjedt kiegészítők mögött álló maréknyi fejlesztő nem is értesül a felfedezett hibáról.
Van mitől félnem?
Jó, jó, de akkor miért állítom mégis azt, hogy nyugodtan meg lehet bízni ezekben a tartalomkezelő rendszerekben? Azért mert egy kevés odafigyeléssel és karbantartással – és természetesen egy megbízható és segítőkész fejlesztővel – ezek a CMS-ek biztonságossá válnak:
- A közösségi fejlesztésű keretrendszereknél a tagság nagyon hamar észleli a hibákat – és befoltozza azokat, majd egy javítócsomag keretében közreadja, így naprakészen tarthatod a rendszeredet – és bátran kijelenthetjük, hogy ilyenformán az alaprendszered feltörhetetlen lesz.
Ezeket a biztonsági javításokat biztosan nem kapod meg ha külső fejlesztő készíti az oldaladat, így soha nem lehetsz biztos abban, hogy nincsenek e biztonsági rések az oldaladon kivéve ha zárt forráskódú rendszert lízingelsz (Sense/Net, Ms Sharepoint), és komoly cég áll mögötte, mert ilyen esetekben természetesen történnek hibajavítások, viszont ezt a pénztárcád is érezni fogja.
- A nyílt forráskódú tartalomkezelőkben rengeteg pénz van, és erre számos cég felfigyelt. Megteheted, hogy az oldaladon csak és kizárólag elismert és évtizedes múltú fejlesztők kiegészítőit futtasd. Ezek biztonságosak, és ha mégsem azok, biztos lehetsz benne, hogy az alaprendszerhez hasonlóan még a hiba ismerté válása előtt ki lesznek javítva. Természetesen ezek némelyike már nem ingyenes (vagy csak részben az – az opensource üzleti model igen különleges dolog), de még több fizetős modul beépítése esetén is jóval alacsonyabb költségekkel számolhatsz, mintha nem Open Source motort használnál.
- Vannak módszerek és kiegészítők, amik kifejezetten arra szolgálnak, hogy biztonságossá tedd az oldaladat. Ezek egy része ingyenesen elérhető, egy részük pénzbe kerül, viszont egy második/harmadik szintet építenek az oldalad és a hacker közé. Már akkor is nagy lépést teszel, ha egyszerűen csak elrejted az oldalad valódi mibenlétét néhány egyszerű beállítással, de léteznek olyan kiegészítők is amik kifejezetten az elterjedt támadási formákkal (Sql injection, Bruteforce) szemben védenek.
Itt kell megjegyezni, hogy mindez mit sem ér, ha az oldalt üzemeltető személy felelőtlen vagy hülye. Mindig, minden esetben válassz olyan jelszót, amit nehéz megfejteni, és minimum tartalmaz kis és nagy betűt, valamint számot is.
Nem szaporítom tovább a szót, rá is térek a harmadik pontra, a fejlesztő mérlegelésére. A „nem biztonságos” ugyanis néha amolyan szitokszóként jelenik meg: az esetek egy részében egyszerűen erre a bűvös szókombinációra van szükség ahhoz, hogy az ügyfél észrevegye, hogy ahhoz amit akar, több munka, több pénz és jóval több tudás szükséges, mint amennyit ő a projektbe kíván invesztálni.
A megrendelő azt látja, hogy ott van az a Drupal rendszer, olvasott is róla, és remek webáruházat lehet belőle tákolni. Megkeres egy fejlesztőt és elmondja az igényeit, de a szakember rögtön rájön, hogy valójában nem arra van szüksége, amit a rendszer nyújtani tud. Ekkor finoman megpróbálja rávezetni az ügyfelet a helyes útra: bemutatja a rendszert és megpróbálja megértetni, hogy a számára nem az a jó választás – nem azért mert nem tudná elkészíteni amit kér, csak egyszerűen többe lenne neki a leves, mint a hús. Végül ha ezt sem érti meg a kliens, akkor jöhet az adu: „nem lenne biztonságos”.
Aztán persze rögtön a rémtörténetek a feltört oldalakról és a távol (és közel) keleti hekkerekről, amitől rögtön az ügyfél inába száll a bátorság és lemond a választott keretrendszerről. Viszont megrendeli azt a másikat, amit a fejlesztő javasol nekei.
Ráadásul az esetek nagy részében ezt jól is teszi, mert alighanem még anyagilag is jobban jár: egy létező kiegészítő átírása rémálom a programoznak, rengeteg keresgélés és dokumentáció olvasás, tesztelés és idő, idő, idő - noha egyébként csak egy pár órányi munka lenne megvalósítani amit az ügyfél szeretne.
A nyílt forráskódú keretrendszerekre ugyanis nem úgy kell tekinteni mint a „webfejlesztés szent kelyheire”, hanem úgy, mint univerzális tartalomkezelő alkalmazásokra – hiszen erre találták ki őket. A határaikon belül ugyan a végtelenségig rugalmasak, de azért csak vannak határaik, amiket nem illik feszegetni.
Ha egyszerű hírportált, nagy tudású, de funkcióiban klasszikus webáruházat, esetleg céges weboldalt szeretnél, válaszd nyugodtan ezeket a remek keretrendszereket, és ne rezelj be az olvasott mendemondáktól. Kis odafigyeléssel és minimális időbefektetéssel tökéletesen ki fogák a Te honlapodat is szolgálni, mint ahogyan kiszolgálnak több millió egyéb weboldalt is. Cserébe pedig élvezd, hogy könnyen kezelhető, keresőbarát és facebook kompatibilis, "mobile ready" weboldalad van - közösségi alapokon. (többek között ők , ők és ők is megbíznak a nyílt rendszerekben :) ).
