„Nu mai faceți site-uri pe WordPress, alea se sparg. Noi lucrăm în React și Next.js, e altă tehnologie, nu poate fi spart.”
Am auzit fraza asta, în diverse variante, de la tot mai mulți antreprenori care au primit oferte pentru un site nou. Unii au venit la mine cu întrebarea directă: „E adevărat? Dacă trec pe React, scap de grija securității?”
Răspunsul scurt: nu. Răspunsul lung e mai interesant, pentru că în fraza de mai sus există un sâmbure de adevăr, învelit într-o promisiune care poate costa scump. În articolul de față îți explic, fără jargon, de unde vine mitul, ce s-a întâmplat concret în ultimul an cu site-urile „moderne” și ce trebuie să întrebi înainte să alegi o tehnologie pe motiv de securitate.
Și ca să fie clar de la început: nu e un articol „WordPress contra React”. Ambele sunt tehnologii bune, fiecare cu locul ei. E un articol despre o promisiune falsă: că un site poate fi sigur doar prin alegerea tehnologiei, fără întreținere.
De unde vine mitul
Mitul are o bază reală. WordPress e cea mai folosită platformă de site-uri din lume: alimentează în jur de 40% din toate site-urile de pe internet. Asta îl face cea mai mare țintă. Atacatorii scriu programe automate care scanează milioane de site-uri WordPress căutând aceeași problemă, iar când o găsesc, o exploatează în masă.
În plus, WordPress trăiește din pluginuri: zeci de mii de extensii scrise de mii de dezvoltatori, de calitate foarte diferită. Un plugin abandonat sau prost scris e o ușă deschisă. Am scris despre asta în Pluginul uitat din 2019.
Deci da, site-urile WordPress sunt atacate des. Dar concluzia „atunci alt tip de site nu poate fi atacat” e greșită. E ca și cum ai spune: „Cele mai multe furturi de mașini sunt la Dacia, deci un Tesla nu poate fi furat.” Dacia e furată des pentru că sunt multe, nu pentru că celelalte sunt de neatins.
Ce înseamnă, de fapt, „site făcut în React”
Expresia acoperă lucruri foarte diferite, iar diferența contează enorm pentru securitate:
1. Site static. Paginile sunt generate o singură dată, la publicare, și servite ca fișiere simple. Nu există bază de date, nu există panou de administrare pe server, nu rulează cod la fiecare vizită. Unelte precum Astro sau exportul static din Next.js produc astfel de site-uri. Aici mitul are cel mai mult adevăr: suprafața de atac e cu adevărat mult mai mică.
2. Aplicație cu server. Next.js, cel mai popular framework construit pe React, rulează de obicei și cod pe server: generează pagini la cerere, procesează formulare, verifică autentificări, vorbește cu baze de date și alte servicii. Asta e o aplicație web completă, cu server, cu tot ce înseamnă asta.
3. Site „headless”. Partea vizibilă e în React, dar conținutul vine dintr-un sistem de administrare separat (uneori chiar WordPress, folosit doar ca panou de editare). Ai, practic, două sisteme de întreținut în loc de unul.
Când cineva îți spune „site în React”, prima întrebare utilă e: „Static sau cu server?” Răspunsul schimbă complet discuția despre securitate.
Ce s-a întâmplat concret în ultimul an
Ca să nu rămânem la teorie, iată trei incidente reale, din 2025, care au lovit exact tehnologiile prezentate ca „imune”.
Martie 2025: autentificarea care putea fi ocolită cu un singur rând
Pe 21 martie 2025, echipa Next.js a publicat un avertisment de securitate pentru o vulnerabilitate (CVE-2025-29927) care permitea ocolirea completă a unui mecanism de protecție numit middleware. Multe site-uri foloseau exact acest mecanism ca să verifice dacă un vizitator e autentificat înainte să-i arate o pagină protejată: un panou de administrare, un cont de client, o zonă de membri.
Problema: un atacator putea adăuga un singur rând special în cererea trimisă către site, iar verificarea era sărită cu totul. Erau afectate versiunile 11, 12, 13, 14 și 15 ale Next.js. Pentru versiunea 11 nu a mai fost publicată nicio reparație. Singura soluție era actualizarea la o versiune mai nouă.
Decembrie 2025: React2Shell, gravitate maximă
Pe 3 decembrie 2025 a fost anunțată o vulnerabilitate în React Server Components, botezată React2Shell (CVE-2025-55182). A primit scorul maxim de gravitate, 10 din 10. Permitea unui atacator, fără cont și fără parolă, să ruleze orice cod pe serverul site-ului, trimițând o simplă cerere web.
Erau afectate mai multe versiuni din React 19 și framework-urile care le foloseau, inclusiv Next.js. În două zile, agenția americană de securitate cibernetică (CISA) a adăugat vulnerabilitatea pe lista celor exploatate activ. Firmele de securitate au văzut scanări automate din sute de adrese IP și atacuri reale care instalau programe de control la distanță pe serverele compromise.
Cu alte cuvinte: exact scenariul de coșmar pentru care WordPress are reputație proastă, doar că pe un site „modern”.
Septembrie 2025: atacul care a venit prin „cărămizile” site-ului
Un site React nu e scris de la zero. E construit din sute de pachete de cod gata făcute, descărcate dintr-un depozit public numit npm. Un site obișnuit ajunge ușor la sute sau mii de astfel de pachete, majoritatea aduse automat, fără ca dezvoltatorul să le aleagă pe fiecare.
În septembrie 2025, mai mulți autori de pachete foarte populare au căzut victime unor emailuri de phishing, iar atacatorii au publicat versiuni infectate ale pachetelor lor. Câteva zile mai târziu a apărut Shai-Hulud, un „vierme” care s-a răspândit singur prin npm. A pornit de la un pachet descărcat de peste 2 milioane de ori pe săptămână și a ajuns la cel puțin 187 de pachete în primele zile. Odată instalat, căuta parole, chei de acces și date de autentificare pe calculatoarele dezvoltatorilor și pe serverele de construire a site-urilor, apoi se republica singur în alte pachete.
Sună cunoscut? E exact riscul pluginurilor WordPress, doar mutat într-un alt ecosistem. Problema nu e WordPress sau React. Problema e codul scris de alții, pe care îl folosești fără să-l verifici și fără să-l actualizezi.
Riscurile care rămân la fel, indiferent de tehnologie
Dincolo de vulnerabilitățile specifice, există o listă întreagă de riscuri care nu țin deloc de tehnologia în care e făcut site-ul:
Formularele. Orice formular, de contact, de comandă sau de programare, trimite date undeva. Dacă nu e protejat, primește spam, e folosit pentru atacuri sau scurge datele clienților.
Cheile de acces lăsate la vedere. O greșeală frecventă în site-urile React: chei pentru servicii externe (hărți, plăți, emailuri, inteligență artificială) puse în codul care ajunge în browserul vizitatorului. Oricine deschide sursa paginii le poate copia și folosi pe banii tăi.
Serverul și găzduirea. Dacă site-ul rulează pe un server, serverul are nevoie de actualizări, protecție, monitorizare și backup. Exact ca la WordPress.
Domeniul, DNS-ul și emailul. Cine controlează domeniul controlează site-ul, indiferent de tehnologie. Emailul firmei poate fi folosit pentru facturi false dacă nu e protejat cu SPF, DKIM și DMARC.
Conturile. Contul de găzduire, contul de pe GitHub unde stă codul, contul de la serviciul de publicare. Dacă unul dintre ele e compromis, site-ul poate fi modificat fără să atingă nimeni codul.
Antetele de securitate. Setările invizibile care protejează vizitatorii de anumite atacuri lipsesc la fel de des pe site-urile moderne ca pe cele WordPress. Vezi ghidul despre security headers.
Diferența reală: cine apasă butonul de actualizare
Aici e, de fapt, miezul problemei. La WordPress există un buton de „Actualizează”. Poate fi apăsat de proprietar, de o firmă de mentenanță sau chiar automat. Poți vedea în panoul de administrare că există actualizări în așteptare. Nu e perfect, dar e vizibil.
La un site React sau Next.js, actualizarea înseamnă: un dezvoltator descarcă codul, actualizează pachetele, verifică dacă nu s-a stricat nimic, reconstruiește site-ul și îl publică din nou. Nu există niciun buton pe care proprietarul să-l vadă sau să-l apese.
Ce înseamnă asta în practică? Când a apărut React2Shell, proprietarii de site-uri Next.js n-au primit nicio notificare în vreun panou de administrare. Dacă dezvoltatorul lor era atent, a actualizat în aceeași săptămână. Dacă proiectul se încheiase de luni de zile și nimeni nu mai avea contract de întreținere, site-ul a rămas vulnerabil. Iar proprietarul, de cele mai multe ori, nici nu a aflat.
De aceea întrebarea corectă nu e „pe ce tehnologie e făcut site-ul?”, ci: „Cine îl actualizează, cât de des și de unde afli că a făcut-o?”
Unde mitul are dreptate (să fim corecți)
Nu vreau să las impresia că toate tehnologiile sunt la fel de riscante. Nu sunt.
Un site static bine făcut, fără server, fără bază de date și fără panou de administrare public, are o suprafață de atac mult mai mică decât un site WordPress cu 30 de pluginuri. Pentru un site de prezentare care se schimbă rar, poate fi o alegere excelentă din punct de vedere al securității și al vitezei.
Dar și aici apar costuri ascunse:
- Nu-l poți modifica singur. Fiecare schimbare de text, preț sau imagine trece, de obicei, prin dezvoltator.
- Formularele și funcțiile dinamice tot au nevoie de servicii externe, fiecare cu riscurile și conturile lui.
- Pachetele de construire trebuie tot actualizate, chiar dacă riscul imediat e mai mic.
- Dependența de un singur om sau de o singură agenție e mai mare, pentru că tehnologia e mai puțin standardizată decât WordPress.
Pe scurt: un site static poate fi mai sigur. Un site „în React” cu server, formulare, autentificare și integrări nu e automat mai sigur decât un WordPress bine întreținut. Iar un site de orice fel, lăsat neîntreținut, devine nesigur în timp.
Regula simplă: nu tehnologia contează, ci întreținerea
Dacă ar fi să rezum totul într-o singură idee, ar fi aceasta:
- WordPress întreținut e mai sigur decât React neîntreținut.
- React întreținut e mai sigur decât WordPress neîntreținut.
- Orice site neîntreținut devine, în timp, o problemă.
Securitatea nu e o proprietate a tehnologiei. E rezultatul unui proces: actualizări la timp, backup testat, monitorizare, conturi protejate și cineva care răspunde când ceva nu e în regulă.
Ce să întrebi înainte să alegi un site „care nu poate fi spart”
Dacă primești o ofertă care pune accentul pe securitatea tehnologiei, pune aceste întrebări. Un furnizor serios îți va răspunde fără ezitare:
- Site-ul e static sau are server? Dacă are server, cine îl administrează și îl actualizează?
- Cine actualizează pachetele și framework-ul după lansare? E inclus în preț? Pentru cât timp?
- Cum aflu eu că s-a aplicat o reparație de securitate? Primesc un raport? O notificare?
- Ce s-a întâmplat cu site-urile voastre când a apărut React2Shell? O întrebare foarte bună. Răspunsul îți spune imediat dacă furnizorul urmărește securitatea sau doar construiește și pleacă.
- Unde stă codul și ale cui sunt conturile? Codul, contul de găzduire și domeniul trebuie să fie pe numele firmei tale.
- Pot modifica singur conținutul? Dacă nu, cât costă și cât durează o modificare simplă?
- Ce se întâmplă dacă nu mai lucrăm împreună? Poate prelua alt dezvoltator site-ul fără să-l refacă de la zero?
- Cum se face backup și unde? A fost testată vreodată o restaurare?
Ce înseamnă asta pentru tine, dacă ai deja un site WordPress
Dacă ai un site WordPress și te gândeai să-l refaci „ca să fie sigur”, răspunsul onest e că, în cele mai multe cazuri, nu ai nevoie de alt site, ci de alt mod de a-l întreține. Actualizări regulate, pluginuri puține și de încredere, backup extern, firewall, autentificare în doi pași și monitorizare rezolvă marea majoritate a problemelor. Ghidul complet e în Securizarea unui site WordPress de la zero.
Iar dacă există motive reale să schimbi platforma (viteză, design, funcții noi), schimbă-o pentru acele motive, nu pentru o promisiune de securitate „din fabrică”. Am scris și despre ce presupune o migrare între platforme.
Întrebări frecvente
Deci WordPress e mai sigur decât React?
Nu. Niciuna nu e „mai sigură” în sine. WordPress e atacat mai des pentru că e mai răspândit. React și Next.js au avut, în 2025, vulnerabilități la fel de grave. Diferența o face întreținerea.
Un site static chiar nu poate fi spart?
E mult mai greu de atacat direct, pentru că nu are server, bază de date sau panou de administrare. Dar contul de găzduire, domeniul, codul sursă și serviciile externe folosite de formulare rămân puncte vulnerabile.
Cum aflu în ce tehnologie e făcut site-ul meu?
Întreabă direct furnizorul. Poți folosi și unelte gratuite de identificare a tehnologiilor, precum extensiile de browser care arată ce platformă folosește o pagină.
Site-ul meu e făcut în Next.js. Ce verific acum?
Întreabă dezvoltatorul ce versiune de Next.js și React folosește site-ul și dacă au fost aplicate reparațiile pentru vulnerabilitățile din martie și decembrie 2025. Dacă nu primești un răspuns clar, merită o verificare independentă.
Firma de mentenanță WordPress poate întreține și un site React?
Depinde de firmă. Partea de server, domeniu, email, backup și monitorizare e comună. Actualizarea codului în sine cere un dezvoltator care cunoaște tehnologia și proiectul.
Concluzia, pe scurt
Nicio tehnologie nu e imună la hackeri. WordPress e atacat des pentru că e peste tot. React și Next.js au avut în 2025 vulnerabilități de gravitate maximă, exploatate activ, iar ecosistemul npm a fost lovit de atacuri care s-au răspândit singure prin pachete.
Un site static are, cu adevărat, mai puține puncte slabe. Dar promisiunea „noi facem în React, deci nu se sparge” omite partea cea mai importantă: orice site are nevoie de cineva care îl actualizează, îl monitorizează și răspunde când apare o problemă. Fără asta, tehnologia contează foarte puțin.
Dacă vrei să știi cum stă site-ul tău, indiferent pe ce e făcut, la capitolul securitate, pornește de la un audit gratuit WebFixer.
Descoperă mai multe la WebFixer
Abonează-te ca să primești ultimele articole prin email.