A biztonság nem külön funkció

Egy webalkalmazás élesítésekor könnyű a látható feladatokra koncentrálni: működjenek a képernyők, menjen ki az e-mail, legyen gyors a betöltés. A biztonsági problémák viszont gyakran nem látványos hibák. A rendszer látszólag működik, miközben egy felhasználó más adataihoz férhet hozzá, egy adminfelület nyilvánosan elérhető, vagy a mentésből nem lehet visszaállni.

A biztonság nem egyszeri pecsét. Tervezési, fejlesztési és üzemeltetési gyakorlat. Az élesítés előtti ellenőrzés célja a legfontosabb kockázatok csökkentése és annak biztosítása, hogy incidens esetén legyen észlelés és helyreállítás.

Az OWASP Top 10:2025 kiemelt témái között szerepel a hibás hozzáférés-kezelés, a biztonsági konfiguráció, a szoftverellátási lánc, a kriptográfia, az injekció, a nem biztonságos tervezés, a hitelesítés, az integritás, a naplózás és a kivételes helyzetek kezelése. Az alábbi lista ezeket laikus számára is használható ellenőrzési pontokká fordítja le.

1. Hozzáférés-kezelés

A legfontosabb kérdés: minden felhasználó csak azt látja és módosítja, amire jogosult?

Ellenőrizendő:

  • szerepkörök és jogosultságok;
  • ügyféladatok elkülönítése;
  • adminfunkciók védelme;
  • közvetlen URL-lekérés;
  • export és letöltés;
  • státuszváltás és jóváhagyás;
  • API-végpontok jogosultsága;
  • törölt vagy inaktív felhasználó hozzáférése.

Nem elegendő, hogy a gomb nincs megjelenítve. A backendnek is minden műveletnél ellenőriznie kell a jogosultságot.

2. Biztonsági konfiguráció

Gyakori probléma a hibakeresési mód, alapértelmezett jelszó, túl részletes hibaüzenet vagy nyitva hagyott szolgáltatás.

Élesítés előtt:

  • debug mód kikapcsolva;
  • titkos értékek nem a repositoryban;
  • felesleges portok zárva;
  • adminútvonalak védve;
  • directory listing tiltva;
  • biztonságos HTTP headerek beállítva;
  • CORS szabályok szűkítve;
  • production környezeti változók ellenőrizve;
  • hibák nem szivárogtatnak stack trace-t vagy titkot.

3. Szoftverellátási lánc és függőségek

A saját kód mellett keretrendszerek, csomagok, konténerek és buildeszközök is futnak.

Ellenőrizendő:

  • támogatott verziók;
  • ismert sérülékenységek;
  • lock fájl és reprodukálható build;
  • csomagforrások;
  • fölösleges függőségek;
  • CI/CD jogosultságok;
  • image és artifact eredete;
  • harmadik fél scriptjei.

A frissítés nem egyszeri projekt, ezért a működési modellnek tartalmaznia kell a sérülékenységek követését.

4. Titkosítás és titkok

Adatátvitel

Minden érzékeny kommunikáció HTTPS-en történjen. Ellenőrizni kell a tanúsítványt, a kényszerített átirányítást és a biztonságos cookie-beállításokat.

Tárolás

A jelszavakat korszerű, erre szolgáló hash algoritmussal kell tárolni, nem visszafejthető formában. Különösen érzékeny adatoknál adatbázis- vagy mezőszintű titkosítás is szükséges lehet.

Titkok

API-kulcs, adatbázisjelszó és privát kulcs ne kerüljön forráskódba, logba vagy kliensoldali csomagba. Legyen rotálható és hozzáférés szerint korlátozott.

5. Inputvalidáció és injekció elleni védelem

Minden kívülről érkező adatot ellenőrizni kell:

  • űrlap;
  • URL-paraméter;
  • fájlfeltöltés;
  • API-kérés;
  • webhook;
  • importfájl;
  • külső rendszer válasza.

Fontos a szerveroldali validáció, paraméterezett adatbázis-lekérdezés, megfelelő output encoding és a veszélyes fájltípusok korlátozása.

A kliensoldali validáció jó felhasználói élményt ad, de önmagában nem biztonsági kontroll.

6. Hitelesítés és munkamenet

Ellenőrzési pontok:

  • erős jelszókezelés;
  • brute-force és credential stuffing elleni rate limit;
  • biztonságos jelszó-visszaállítás;
  • többfaktoros hitelesítés adminoknak;
  • session lejárat;
  • kijelentkezés és token-visszavonás;
  • secure, HttpOnly és SameSite cookie-k;
  • inaktív vagy törölt fiókok kezelése;
  • jogosultságváltozás azonnali érvényesítése.

7. Biztonságos tervezés és üzleti logika

Sok hiba nem technikai injekció, hanem rosszul megtervezett folyamat.

Példák:

  • kupon korlátlanul újrahasználható;
  • negatív mennyiség rendelhető;
  • jóváhagyás megkerülhető közvetlen API-hívással;
  • ugyanaz a fizetés többször könyvelődik;
  • státuszok tetszőleges sorrendben válthatók;
  • versenyhelyzet miatt dupla foglalás jön létre.

Ezeket üzleti szabályokkal, tranzakcióval, idempotenciával és célzott tesztekkel kell kezelni.

8. Szoftver- és adatintegritás

Ellenőrizni kell, hogy a telepített kód és adat megbízható forrásból származik-e, és nem módosult-e jogosulatlanul.

Hasznos kontrollok:

  • védett branch;
  • code review;
  • aláírt vagy ellenőrzött build artifact;
  • CI/CD minimális jogosultsággal;
  • migrációk verziózása;
  • webhook aláírás ellenőrzése;
  • importok ellenőrzése;
  • release és rollback dokumentálása.

9. Naplózás, monitoring és riasztás

A log nem azért kell, hogy minél több adatot gyűjtsünk. Arra kell, hogy hiba vagy incidens esetén rekonstruálható legyen, mi történt.

Érdemes naplózni:

  • belépési kísérletek;
  • adminműveletek;
  • jogosultságváltozás;
  • kritikus adat módosítása;
  • integrációs hiba;
  • háttérfolyamat sikertelensége;
  • rate limit esemény;
  • rendszerhiba és korrelációs azonosító.

Nem szabad logolni teljes jelszót, tokent, bankkártyaadatot vagy indokolatlan személyes adatot.

A kritikus eseményhez riasztási küszöb és felelős szükséges. A soha senki által nem nézett log kevés értéket ad.

10. Kivételes helyzetek kezelése

A rendszernek biztonságosan kell viselkednie akkor is, ha:

  • külső API nem válaszol;
  • adatbázis-kapcsolat megszakad;
  • fizetés késik;
  • dupla webhook érkezik;
  • fájl túl nagy;
  • üzenetsor leáll;
  • hibás konfiguráció kerül ki;
  • elfogy a tárhely.

A cél nem az, hogy soha ne legyen hiba, hanem hogy a hiba ne okozzon kontrollálatlan adatvesztést vagy többszörös végrehajtást.

11. Adatvédelem

Az élesítés előtt tisztázni kell:

  • milyen személyes adatot kezel a rendszer;
  • mi a cél és jogalap;
  • meddig őrzi;
  • ki fér hozzá;
  • mely szolgáltatók dolgozzák fel;
  • hogyan teljesíthető törlés vagy hozzáférési kérelem;
  • milyen cookie és külső tracking működik;
  • van-e szükség adatvédelmi tájékoztató frissítésére.

A technikai adatminimalizálás gyakran a legegyszerűbb biztonsági intézkedés: amit nem szükséges gyűjteni, azt ne tároljuk.

12. Backup és incidensfelkészültség

Élesítés előtt legyen:

  • automatikus mentés;
  • retention;
  • elkülönített másolat;
  • visszaállítási próba;
  • incidenskapcsolat;
  • eszkalációs út;
  • kulcsok visszavonási terve;
  • kommunikációs sablon;
  • rollback eljárás.

13. Teljesítmény és túlterhelés

A lassú vagy erőforrás-kimerülő rendszer biztonsági problémává is válhat. Ellenőrizni kell a legfontosabb lekérdezéseket, fájlfeltöltést, rate limitet, cache-t, háttérfolyamatot és várható csúcsforgalmat.

14. Akadálymentesség és használhatóság

A biztonságos folyamatnak használhatónak is kell lennie. Ha a jelszó-visszaállítás, a hibaüzenet vagy a megerősítés nem érthető, a felhasználó kerülőutat kereshet. A WCAG 2.2 szerinti alapelvek a fogyatékkal élő felhasználók mellett általában mindenki számára javítják a használhatóságot.

Indulás előtti minimum checklist

  • Minden szerepkör jogosultságtesztje elkészült.
  • Production debug kikapcsolva.
  • Titkok nem szerepelnek a kódban.
  • Függőségek és sérülékenységek ellenőrizve.
  • HTTPS és cookie-beállítások rendben.
  • Inputok szerveroldalon validálva.
  • Adminfiókokon 2FA elérhető vagy kötelező.
  • Kritikus műveletek auditálva.
  • Monitoring és riasztás működik.
  • Backup elkészült és visszaállítás tesztelve.
  • Incidens- és rollbackfolyamat dokumentált.
  • Adatkezelési és cookie-tartalom egyezik a valós működéssel.
  • Fő folyamatok regressziós tesztje sikeres.

A BT Digital megközelítése

Nem azt ígérjük, hogy létezik „100%-ban feltörhetetlen” rendszer. Ilyen felelős ígéret nem tehető. A cél a kockázat arányos csökkentése, a minimális jogosultság, a biztonságos alapbeállítás, a rendszeres frissítés és az észlelhető működés.

A biztonság nem egyetlen teszt eredménye, hanem a rendszer teljes életciklusának tulajdonsága.

Szakmai háttér

A checklist az OWASP Top 10:2025 alkalmazásbiztonsági kockázati területeit közérthető üzemeltetési és fejlesztési ellenőrzésekké alakítja. Az akadálymentességi megjegyzések a W3C WCAG 2.2 irányához igazodnak.