Listă de verificare pentru securitatea site-ului: 20 de lucruri de verificat acum

Atacurile cibernetice nu mai sunt rezervate companiilor Fortune 500 și agențiilor guvernamentale. În 2025, 43% din toate breșele înregistrate au vizat întreprinderi mici și mijlocii, potrivit raportului Data Breach Investigations Report al Verizon. Atacatorii știu că organizațiile mai mici adesea nu au echipe dedicate de securitate, ceea ce le face o țintă ușoară pentru kiturile automate de exploatare care scanează internetul non-stop. Un singur formular de contact compromis sau un plugin învechit poate expune datele clienților, poate prăbuși pozițiile în căutări și poate declanșa amenzi de reglementare care depășesc cu mult costul prevenirii.

La GRADAX, am văzut consecințele pe viu. Un client care administra un magazin online regional a apelat la noi după ce pagina sa de finalizare a comenzii a fost infectată cu un skimmer de carduri de credit care a funcționat nedetectat timp de unsprezece zile. Daunele financiare au fost semnificative, dar daunele de reputație au fost mai grave, rata clienților fideli a scăzut cu 38% în trimestrul următor dezvăluirii. Acel incident a cristalizat un principiu pe care îl aplicăm acum în fiecare proiect: securitatea este infrastructură, nu un gând ulterior.

Această listă de verificare sintetizează cele mai impactante douăzeci de măsuri de securitate pe care le implementăm în proiectele noastre de găzduire și dezvoltare web. Nu aveți nevoie de un buget de securitate de șase cifre pentru a le executa. Majoritatea pot fi finalizate într-o singură după-amiază și, împreună, elimină marea majoritate a vectorilor de atac pe care îi exploatează actorii reali de amenințare. Fie că vă administrați singuri serverele sau vă bazați pe un furnizor de găzduire administrată, aceste verificări vi se aplică.

Fiecare pagină de pe site-ul dumneavoastră ar trebui să se încarce prin HTTPS cu un certificat SSL valid. Acest lucru este obligatoriu în 2026. Browserele semnalează site-urile HTTP ca nesigure, motoarele de căutare le penalizează în clasamente, iar orice date transmise fără criptare, date de autentificare, trimiteri de formulare, detalii de plată, pot fi interceptate de oricine din aceeași rețea. Certificatele gratuite de la Let's Encrypt au eliminat costul ca scuză, așa că nu există niciun motiv de amânare.

Dincolo de instalarea certificatului, verificați că serverul dumneavoastră impune HTTPS prin redirecționarea tuturor cererilor HTTP cu un redirect 301. Verificați că antetul HSTS (HTTP Strict Transport Security) este setat cu un max-age de cel puțin un an și include directiva includeSubDomains. Aceasta spune browserelor să se conecteze întotdeauna prin HTTPS, chiar dacă un utilizator tastează URL-ul fără prefixul de protocol. De asemenea, recomandăm adăugarea domeniului dumneavoastră în lista de preîncărcare HSTS menținută de producătorii de browsere, care integrează cerința HTTPS direct în Chrome, Firefox și Safari.

Capcanele frecvente includ avertismentele de conținut mixt, când o pagină se încarcă prin HTTPS dar face referire la imagini, scripturi sau foi de stil prin HTTP. Rulați un crawl cu un instrument precum Screaming Frog sau folosiți consola pentru dezvoltatori a browserului pentru a identifica problemele de conținut mixt. Fiecare resursă, fonturi, scripturi de analiză, iframe-uri încorporate, endpoint-uri API, trebuie să folosească URL-uri HTTPS. O singură resursă HTTP poate face lacătul să dispară și poate eroda încrederea vizitatorilor.

Software-ul neactualizat este cel mai exploatat vector de atac de pe web. Nucleul WordPress, pluginurile, temele, sistemele de operare ale serverelor, runtime-urile PHP, motoarele de baze de date, fiecare strat al stivei dumneavoastră primește patch-uri de securitate în mod regulat, iar fiecare componentă neactualizată este o vulnerabilitate documentată pe care atacatorii o pot exploata cu instrumente gata făcute. Breșa de la Equifax care a expus 147 de milioane de înregistrări a fost cauzată de o singură dependență Apache Struts neactualizată. Amploarea nu este o condiție prealabilă pentru catastrofă.

Recomandăm un ritm disciplinat de actualizări: patch-uri de securitate critice în 24 de ore de la lansare, toate celelalte actualizări în șapte zile. Pentru site-urile WordPress, activați cel puțin actualizările automate minore și de securitate. Pentru aplicațiile personalizate, integrați scanarea dependențelor în pipeline-ul de implementare, instrumente precum Dependabot, Snyk sau Renovate vor semnala pachetele vulnerabile înainte de a ajunge în producție. Dacă rulați pe găzduirea noastră gestionată, ne ocupăm automat de patch-urile pentru sistemul de operare și runtime, dar dependențele la nivel de aplicație rămân responsabilitatea dumneavoastră.

Testați actualizările într-un mediu de testare înainte de a le aplica în producție. Am văzut patch-uri de securitate bine intenționate care au stricat gateway-uri de plată, formulare de contact și fluxuri de autentificare pentru că o actualizare de plugin a introdus o incompatibilitate. Un test de cinci minute într-un mediu de testare previne o întrerupere de cinci ore în producție. Dacă furnizorul dumneavoastră de găzduire nu oferă un mediu de testare cu un singur clic, acest lucru singur este un motiv suficient pentru a lua în considerare trecerea la un furnizor care o face.

Parolele rămân cea mai slabă verigă în majoritatea lanțurilor de securitate. Atacurile de tip credential stuffing, în care atacatorii testează combinații de nume de utilizator și parole scurse din alte breșe, reprezintă peste 60% din atacurile legate de autentificare. Dacă parola de administrator WordPress este „company2024” sau parola root a bazei de date este „password123”, practic lăsați ușa de la intrare descuiată. Fiecare cont cu acces la infrastructura site-ului dumneavoastră ar trebui să folosească o parolă unică de cel puțin șaisprezece caractere, generată de un manager de parole.

Autentificarea multi-factor (MFA) este cea mai eficientă apărare împotriva accesului neautorizat. Chiar dacă un atacator obține o parolă validă prin phishing sau o breșă de date, nu se poate conecta fără al doilea factor. Impunem MFA pe fiecare cont de administrator din platforma noastră de găzduire și recomandăm insistent clienților noștri să facă același lucru pentru CMS-ul, registrarul de domenii, furnizorul DNS, emailul și orice instrument SaaS cu acces la datele de producție. Aplicațiile de autentificare precum Authy sau cheile hardware precum YubiKey sunt mult mai sigure decât codurile bazate pe SMS, care sunt vulnerabile la atacuri de tip SIM-swapping.

Limitați numărul de încercări de autentificare înainte de a declanșa o blocare sau o provocare CAPTCHA. Cinci încercări eșuate în zece minute ar trebui să blocheze contul timp de cincisprezece minute sau să solicite verificare umană. Această măsură simplă oprește atacurile brute-force pe loc. De asemenea, auditați trimestrial lista utilizatorilor administratori, eliminați conturile foștilor angajați, colaboratori și agenții cu care nu mai lucrați. Fiecare cont activ este o suprafață de atac.

Backup-urile sunt ultima linie de apărare atunci când totul eșuează. Ransomware vă criptează fișierele, un plugin problematic vă șterge baza de date, un dezvoltator șterge accidental folderul de încărcări din producție, fără un backup fiabil și testat, oricare dintre aceste scenarii poate însemna pierderea permanentă a datelor. Întrebarea nu este dacă aveți nevoie de backup-uri, ci dacă strategia actuală de backup v-ar salva cu adevărat într-o criză.

Urmați regula 3-2-1: păstrați cel puțin trei copii ale datelor dumneavoastră, pe două medii de stocare diferite, cu o copie stocată în afara locației. Pentru site-uri, aceasta înseamnă backupuri automate zilnice stocate pe același server (pentru restaurare rapidă), replicate pe un server separat sau un bucket de stocare în cloud (pentru redundanță) și arhivate într-o locație geografic îndepărtată (pentru recuperare în caz de dezastru). Infrastructura noastră de backup și recuperare păstrează instantanee zilnice timp de treizeci de zile, instantanee săptămânale timp de trei luni și instantanee lunare timp de un an.

Cel mai critic și cel mai des neglijat pas este testarea backupurilor. Un backup pe care nu l-ați restaurat niciodată este un backup în care nu puteți avea încredere. Programați un exercițiu de restaurare trimestrial în care porniți un mediu de staging din ultimul backup și verificați că site-ul se încarcă corect, baza de date este intactă, fișierele încărcate de utilizatori sunt prezente și toate funcționalitățile funcționează. Am întâlnit clienți ale căror sarcini de backup eșuau silențios de luni de zile pentru că spațiul pe disc se epuizase sau acreditările expiraseră. Descoperiți asta într-un exercițiu, nu în timpul unui incident.

Un web application firewall (WAF) se află între site-ul dumneavoastră și internet, filtrând traficul de intrare pentru a bloca tiparele de atac cunoscute înainte de a ajunge la aplicația dumneavoastră. Oprește tentativele de SQL injection, payload-urile de cross-site scripting, atacurile de directory traversal și zeci de alte tehnici de exploatare pe care scanerele automate le sondează continuu. Fără un WAF, codul aplicației dumneavoastră este singura linie de apărare, iar un singur câmp de intrare omis poate fi punctul de intrare pentru o breșă.

Asociați WAF-ul cu scanări regulate de malware. Scanerele pe server precum ClamAV, Maldet sau soluțiile comerciale de la Sucuri sau Wordfence inspectează sistemul de fișiere pentru semnături malițioase cunoscute, modificări suspecte ale fișierelor și scripturi de acces ascuns pe care atacatorii le plantează pentru acces persistent. Programați scanări zilnice și configurați alerte pentru orice detectare. Recomandăm, de asemenea, monitorizarea integrității fișierelor care urmărește sumele de control ale fișierelor critice. Fișierele de bază WordPress, fișierele de configurare, binarele serverului, și vă alertează imediat dacă vreun fișier se modifică neașteptat.

La nivel de rețea, configurați firewall-ul serverului pentru a permite doar porturile și protocoalele de care aplicația dumneavoastră are nevoie. Un server web tipic ar trebui să expună portul 443 (HTTPS), portul 80 (HTTP, doar pentru redirect) și portul SSH. Orice altceva, porturi de baze de date, panouri de administrare, instrumente de dezvoltare, ar trebui blocat de la accesul public și disponibil doar prin VPN sau tunel SSH. Acest pas simplu de securizare elimină categorii întregi de atacuri care se bazează pe servicii expuse.

Principiul privilegiului minim este una dintre cele mai vechi reguli din securitatea informațiilor, însă este încălcat în mod curent. Fiecare utilizator, cont de serviciu și cheie API ar trebui să aibă permisiunile minime necesare pentru a-și îndeplini funcția, nimic mai mult. Un editor de conținut nu are nevoie de posibilitatea de a instala pluginuri. Un mediu de testare nu are nevoie de credențiale pentru baza de date de producție. Un script de analiză de la terți nu are nevoie de acces de scriere la DOM-ul dumneavoastră.

Auditați rolurile de utilizator WordPress, accesul la panoul de găzduire și cheile SSH ale serverului cel puțin trimestrial. Eliminați sau reduceți privilegiile oricărui cont care are mai multe decât are nevoie. Pentru echipele de dezvoltare, folosiți controlul accesului bazat pe roluri cu conturi nominale, dar nu partajați niciodată o singură credențială de administrator între mai multe persoane. Conturile partajate fac imposibilă urmărirea cine a făcut o modificare, ceea ce este critic în timpul investigării incidentelor și cerut de majoritatea cadrelor de conformitate, inclusiv GDPR și PCI DSS.

Cheile API și credențialele de serviciu merită aceeași atenție. Rotați-le cel puțin anual și imediat după plecarea din organizație a oricărui membru al echipei care avea acces. Stocați-le în variabile de mediu sau într-un secrets manager, niciodată în codul sursă sau în fișiere de configurare trimise în version control. O singură cheie API scursă într-un repository GitHub public poate fi descoperită și exploatată în câteva minute, boții automatizați le scanează continuu.

Monitorizarea securității transformă apărarea dumneavoastră din bariere pasive într-un sistem activ de detectare. Configurați jurnalizarea centralizată care capturează încercările de autentificare, modificările de fișiere, modificările de permisiuni, ratele de eroare și conexiunile de rețea de ieșire. Alimentați aceste jurnale într-o platformă de monitorizare care aplică reguli de corelare și detectarea anomaliilor. O creștere bruscă a încercărilor de autentificare eșuate dintr-un singur interval de IP-uri, un fișier PHP nou neașteptat în directorul de încărcări sau o conexiune de ieșire neobișnuită către un server străin, acestea sunt semnele de avertizare timpurie care preced o breșă.

La fel de important este să aveți un plan de răspuns la incidente înainte de a avea nevoie de el. Documentați pașii pe care echipa dumneavoastră îi va urma când este detectat un atac: cine este notificat, cum este izolat sistemul afectat, unde sunt păstrate probele criminalistice, cum sunt informați clienții și când trebuie contactate autoritățile sau autoritățile de reglementare. Exersați acest plan cel puțin de două ori pe an. Din experiența noastră, organizațiile cu un plan de răspuns la incidente testat rezolvă atacurile cu 60% mai repede și suferă daune financiare și de reputație semnificativ mai mici decât cele care improvizează sub presiune.

Dacă gestionarea tuturor acestor aspecte vi se pare copleșitoare, ar trebui să întărească motivul pentru care contează să lucrați cu un furnizor care integrează securitatea în infrastructura sa. La GRADAX, fiecare plan de găzduire include aplicarea automată a patch-urilor, scanări zilnice de malware, protecție WAF și monitorizare 24/7 ca funcții standard. Securitatea nu este un serviciu suplimentar, este nivelul de bază. Dacă furnizorul dumneavoastră actual o tratează ca opțională, contactați-ne și vă vom arăta cum arată securitatea proactivă în practică.