Securitatea unei aplicatii web: ce trebuie verificat dincolo de certificatul SSL

1. Ce protejeaza HTTPS si ce nu protejeaza

HTTPS foloseste TLS pentru a crea un canal protejat intre client si server. Acest strat este esential pentru transmiterea credentialelor, tokenurilor de sesiune si a altor informatii care nu trebuie expuse in tranzit.

Dar HTTPS nu decide daca utilizatorul A are voie sa vada documentul utilizatorului B. Nu valideaza regulile de business, nu actualizeaza bibliotecile vulnerabile, nu elimina parolele sau cheile API introduse accidental in cod si nu garanteaza ca un endpoint administrativ verifica permisiunile corect.

HTTPS protejeaza transportul datelor; securitatea aplicatiei trebuie implementata si verificata la nivelul codului, identitatii, datelor, infrastructurii si operatiunilor.

Exemplu: o aplicatie HTTPS cu autorizare defectuoasa

Presupunem ca o platforma afiseaza factura curenta la o adresa interna de forma /invoice/1234. Conexiunea poate fi perfect criptata. Daca un utilizator autentificat schimba identificatorul in 1235, iar serverul returneaza factura altui client fara sa verifice dreptul de acces, problema este de autorizare. TLS nu poate corecta aceasta eroare.

2. Autentificarea: cine incearca sa intre in aplicatie?

Autentificarea stabileste identitatea utilizatorului. Pentru aplicatiile cu informatii importante, discutia nu ar trebui sa se opreasca la existenta unei pagini de login.

Trebuie analizate fluxurile complete: autentificare, recuperarea accesului, schimbarea parolei, autentificarea administratorilor, expirarea si revocarea sesiunilor, blocarea sau limitarea atacurilor automate si autentificarea multifactor acolo unde riscul o justifica.

NIST SP 800-63B-4 trateaza separat nivelurile de asigurare ale autentificarii si prevede, pentru contexte care necesita AAL2, oferirea unei optiuni de autentificare rezistente la phishing. Documentul subliniaza si faptul ca parolele nu sunt, prin ele insele, rezistente la phishing.

Ce merita verificat

• cum sunt stocate si verificate parolele;
• daca exista protectie impotriva incercarilor automate si a abuzului;
• daca actiunile sensibile necesita o verificare adecvata contextului;
• daca MFA este disponibila sau obligatorie pentru rolurile cu risc ridicat;
• daca resetarea parolei poate fi exploatata pentru preluarea unui cont;
• daca sesiunile pot fi invalidate dupa schimbarea parolei, compromiterea unui cont sau revocarea accesului;
• daca evenimentele importante de autentificare sunt logate si monitorizate.

3. Autorizarea: ce are voie sa faca utilizatorul dupa login?

Autentificarea si autorizarea nu sunt acelasi lucru. Faptul ca un utilizator s-a autentificat corect nu inseamna ca trebuie sa poata accesa orice obiect, functie sau endpoint din aplicatie.

OWASP Top 10:2025 plaseaza Broken Access Control pe prima pozitie. Recomandarile OWASP pentru autorizare includ aplicarea principiului privilegiului minim, refuzul implicit al accesului si validarea permisiunilor la fiecare cerere relevanta.

Exemple practice de control al accesului defectuos

• un angajat modifica un ID din URL si vede comanda altei companii;
• un utilizator standard apeleaza direct un endpoint rezervat administratorului;
• interfata ascunde un buton, dar API-ul permite in continuare operatia;
• un utilizator dintr-un tenant poate solicita prin API date apartinand altui tenant;
• un cont dezactivat pastreaza o sesiune activa sau un token cu drepturi vechi.

Ascunderea elementelor din interfata nu este o masura suficienta de autorizare. Permisiunea pentru operatiile protejate trebuie verificata in partea de server, acolo unde utilizatorul nu poate ocoli controlul prin modificarea interfetei sau a cererii HTTP.

4. Validarea inputului: aplicatia nu trebuie sa aiba incredere in datele primite

Datele pot veni din formulare, query string, headere HTTP, fisiere incarcate, API-uri, webhook-uri sau integrari cu alte sisteme. Faptul ca un camp este ascuns, dezactivat sau validat in JavaScript nu inseamna ca valoarea primita de server este sigura.

OWASP recomanda validarea cat mai devreme posibil in fluxul de procesare si preferarea regulilor de tip allowlist atunci cand structura datelor este cunoscuta. Validarea din browser poate imbunatati experienta utilizatorului, dar controalele de securitate trebuie aplicate si server-side.

Exemplu practic

Daca un formular accepta un identificator numeric, serverul trebuie sa verifice formatul si limitele acceptate, apoi sa foloseasca metode sigure pentru operatiile asupra bazei de date. Daca aplicatia permite upload, verificarea trebuie sa trateze separat extensia, tipul real al fisierului, dimensiunea, numele, locul de stocare si modul in care fisierul va fi servit ulterior.

Validarea inputului este importanta, dar nu trebuie folosita ca substitut pentru controalele specifice vulnerabilitatii: parametrizarea interogarilor, encoding contextual pentru output, autorizare si configurarea corecta a componentelor raman necesare.

5. Dependintele: codul aplicatiei nu este singurul cod care conteaza

Aplicatiile moderne folosesc framework-uri, biblioteci, pachete, componente server, imagini de container si instrumente de build. OWASP Top 10:2025 include Software Supply Chain Failures, extinzand perspectiva de la simpla existenta a componentelor vulnerabile catre ecosistemul de dependinte, build si distributie.

Un inventar al componentelor si un proces pentru identificarea vulnerabilitatilor sunt importante, dar detectarea nu este suficienta. OWASP arata explicit ca instrumentele pentru dependinte vulnerabile detecteaza probleme; remedierea necesita actualizare, patch, masuri temporare sau o alta decizie tehnica verificata prin teste.

Un proces practic pentru dependinte

1. identifica dependintele directe si tranzitive;
2. urmareste vulnerabilitatile relevante pentru versiunile folosite;
3. testeaza versiunea remediata intr-un mediu separat;
4. ruleaza testele functionale si de securitate relevante;
5. documenteaza situatiile in care actualizarea este temporar imposibila;
6. revino periodic asupra exceptiilor, in loc sa le transformi in exceptii permanente.

6. Secretele: cheile API si parolele nu trebuie tratate ca simple configurari

Credentialele pentru baze de date, cheile API, tokenurile, cheile SSH, cheile private si alte credentiale de serviciu pot oferi acces direct la resurse critice. Introducerea lor in repository, fisiere publice, loguri sau configurari accesibile inutil mareste impactul unei brese.

OWASP recomanda controlul accesului la secrete, reducerea privilegiilor, rotatia si revocarea acestora, precum si evitarea inregistrarii secretelor in clar in loguri. O strategie buna trebuie sa raspunda inclusiv la intrebarea: ce facem daca aceasta cheie este compromisa astazi?

Intrebari pentru echipa tehnica

• Unde sunt pastrate secretele de productie?
• Cine si ce servicii au acces la ele?
• Pot fi rotite fara interventii riscante sau perioade mari de indisponibilitate?
• Au fiecare doar privilegiile necesare?
• Pot fi revocate rapid?
• Exista posibilitatea ca ele sa ajunga in loguri, erori, repository sau backup-uri distribuite necontrolat?

7. Logarea: poti detecta si investiga un incident?

O aplicatie poate avea controale bune si totusi sa fie atacata. Diferenta operationala apare atunci cand echipa poate observa comportamentul suspect, poate investiga evenimentul si poate identifica actiunile efectuate.

OWASP Top 10:2025 include Security Logging and Alerting Failures. Ghidurile OWASP trateaza logarea ca o functie atat operationala, cat si de securitate.

Ce evenimente pot necesita logare

• autentificari reusite si esuate, in functie de politica aplicatiei;
• blocari si evenimente relevante de securitate ale conturilor;
• modificari de roluri si permisiuni;
• actiuni administrative importante;
• erori si exceptii cu relevanta pentru securitate;
• incercari de acces neautorizat;
• operatii sensibile asupra datelor sau configurarii, in functie de modelul de risc.

In acelasi timp, logurile nu trebuie transformate intr-un depozit de parole, tokenuri, chei sau alte secrete. Accesul la loguri, integritatea lor si perioada de retentie trebuie stabilite in functie de scop, risc si obligatiile aplicabile.

8. Backup: o copie existenta nu este suficienta daca nu poate fi restaurata

Backup-ul este parte din rezilienta unei platforme, nu doar o sarcina administrativa. CISA recomanda pentru sistemele critice mentinerea unor backup-uri offline si criptate si testarea periodica a disponibilitatii si integritatii lor in scenarii de recuperare.

Pentru o aplicatie web trebuie stabilit ce se salveaza: baza de date, fisiere generate sau incarcate, configurari, componente necesare reconstructiei si alte resurse fara de care serviciul nu poate fi recuperat. Strategia trebuie adaptata arhitecturii concrete.

Testul care conteaza: restaurarea

Un mesaj automat care spune ca backup-ul a fost creat confirma executarea unei operatii, nu recuperabilitatea completa a platformei. Periodic, restaurarea trebuie testata intr-un mediu controlat, iar echipa trebuie sa stie ce dependinte si ce ordine a operatiilor sunt necesare pentru revenire.

Un backup pe care nimeni nu l-a testat prin restaurare nu trebuie tratat ca o garantie de recuperare.

9. Configurarea: setarile implicite pot deveni vulnerabilitati

Security Misconfiguration ocupa pozitia a doua in OWASP Top 10:2025. Riscul nu se limiteaza la serverul web: configurarea poate afecta framework-ul, baza de date, cloud-ul, containerele, API-urile, serviciile auxiliare si mediul de administrare.

Trebuie eliminate serviciile si functionalitatile care nu sunt necesare, limitat accesul administrativ, protejate interfetele interne si evitate mesajele de eroare care dezvaluie inutil informatii despre infrastructura. Mediile de dezvoltare, staging si productie trebuie tratate distinct, iar configurarea de productie nu trebuie sa depinda de presupunerea ca setarile implicite sunt sigure.

10. Securitatea nu este un test facut o singura data

O aplicatie se schimba. Apar functionalitati, endpoint-uri, dependinte, integrari, roluri si configurari noi. Un control validat la lansare poate fi afectat de o modificare ulterioara.

OWASP recomanda integrarea securitatii in procesele existente de dezvoltare si operare si indica Application Security Verification Standard (ASVS) ca standard destinat verificarii cerintelor de securitate. Versiunea stabila curenta indicata de proiectul OWASP este ASVS 5.0.0.

Pentru o companie, abordarea utila este una bazata pe risc: aplicatiile si functionalitatile care proceseaza date mai sensibile sau permit operatii cu impact mai mare necesita controale si verificari proportionale.

Cand merita reluata verificarea

• dupa introducerea unui modul nou de autentificare sau autorizare;
• dupa schimbari importante de infrastructura;
• dupa integrarea unui API sau serviciu extern;
• dupa modificarea rolurilor si permisiunilor;
• dupa upgrade-uri majore de framework sau runtime;
• dupa identificarea unei vulnerabilitati relevante;
• dupa un incident sau un comportament anormal care poate indica o problema de securitate.

Pentru aplicatiile deja aflate in productie, aceste verificari pot fi incluse intr-un proces mai larg de mentenanta pentru website-uri si aplicatii web, alaturi de actualizari, monitorizare si interventii tehnice.

11. Checklist: ce sa verifici dincolo de certificatul SSL

Checklist-ul nu inlocuieste o analiza adaptata arhitecturii si riscului aplicatiei. O platforma publica fara conturi si o aplicatie B2B care gestioneaza utilizatori, documente, API-uri si roluri administrative necesita niveluri diferite de verificare.

Intrebari frecvente

Este suficient un certificat SSL pentru ca aplicatia sa fie securizata?

Nu. HTTPS/TLS protejeaza canalul de comunicatie, dar aplicatia poate avea in continuare probleme de autorizare, autentificare, injectare, configurare, dependinte, secrete sau logare.

Care este diferenta dintre autentificare si autorizare?

Autentificarea verifica identitatea, iar autorizarea stabileste ce resurse si operatii sunt permise acelei identitati. Un utilizator poate fi autentificat corect si totusi sa obtina acces nepermis daca autorizarea este implementata gresit.

Este suficienta validarea formularului in JavaScript?

Nu pentru securitate. Validarea din browser poate fi ocolita, astfel incat serverul trebuie sa valideze datele primite si sa aplice controalele corespunzatoare contextului in care acestea sunt folosite.

De ce conteaza dependintele daca propriul cod este bine scris?

Aplicatia executa si cod provenit din framework-uri, biblioteci si alte componente. Vulnerabilitatile sau compromiterea lantului software pot afecta aplicatia chiar daca problema nu se afla in codul scris direct de echipa.

Unde ar trebui pastrate cheile API si credentialele tehnice?

Ele trebuie gestionate ca secrete, cu acces limitat conform principiului privilegiului minim, posibilitate de rotatie si revocare si fara expunere inutila in cod, repository sau loguri. Solutia concreta depinde de infrastructura si modelul de deployment.

Cum stim daca backup-ul chiar functioneaza?

Prin testarea restaurarii intr-un mediu controlat. Existenta fisierului de backup sau confirmarea automata a jobului nu demonstreaza singure ca aplicatia si datele pot fi recuperate corect.

Securitatea trebuie verificata doar la lansare?

Nu. Aplicatiile, dependintele, infrastructura si amenintarile se modifica. Verificarile trebuie integrate in ciclul de dezvoltare si mentenanta si reluate in functie de schimbari, vulnerabilitati, incidente si nivelul de risc.

Concluzie: lacatul din browser este inceputul, nu finalul verificarii

Pentru un decident, cea mai utila intrebare nu este doar „avem SSL?”, ci „ce se intampla daca un cont este compromis, o permisiune este implementata gresit, o dependinta devine vulnerabila, o cheie se scurge sau trebuie sa restauram platforma?”.

O aplicatie web mai bine protejata combina criptarea comunicatiei cu autentificare si autorizare adecvate, validarea datelor, administrarea dependintelor si secretelor, configurare sigura, logare, monitorizare si un proces de backup verificat. Aceste controale trebuie adaptate datelor, functionalitatilor si impactului real asupra businessului.