Cum verificați securitatea site-ului fără să atacați nimic

Puteți verifica din exterior o mare parte din configurarea de securitate a unui magazin online, citind ceea ce site-ul trimite deja fiecărui vizitator: certificatul TLS, redirecționările, antetele răspunsurilor HTTP, cookie-urile, scripturile pe care le încarcă și înregistrările DNS publice. Aceste verificări pasive nu trimit trafic de atac și nu necesită autentificare, așa că nu încarcă magazinul mai mult decât o vizită obișnuită. Ele depistează probleme de configurare, precum un certificat aproape de expirare, lipsa HSTS, cookie-uri nesigure, conținut mixt sau o versiune de jQuery cu vulnerabilități cunoscute. Nu sunt un test de penetrare și nu pot dovedi că un magazin este sigur.

Puncte cheie

• Certificatele TLS de încredere publică emise începând cu 15 martie 2026 pot fi valabile cel mult 200 de zile, limită care scade la 100 de zile în martie 2027 și la 47 de zile în martie 2029 (CA/Browser Forum (se deschide într-o filă nouă)).
• Browserele ignoră antetul HSTS atunci când este trimis prin HTTP simplu (MDN (se deschide într-o filă nouă)).
• Directiva CSP frame-ancestors nu funcționează într-o etichetă <meta>; trebuie trimisă ca antet de răspuns (MDN (se deschide într-o filă nouă)).
• Versiunile jQuery anterioare 3.5.0 sunt afectate de două vulnerabilități XSS, iar CISA a adăugat una dintre ele, CVE-2020-11023, în catalogul său Known Exploited Vulnerabilities pe 23 ianuarie 2025 (NVD (se deschide într-o filă nouă)).
• Un fișier security.txt trebuie să conțină câmpurile Contact și Expires și să se afle la /.well-known/security.txt (RFC 9116 (se deschide într-o filă nouă)).

Ce înseamnă o verificare de securitate pasivă?

O verificare pasivă citește doar ceea ce site-ul sau DNS-ul său returnează la o cerere obișnuită.

Asta înseamnă încărcarea paginilor publice, citirea certificatului și a antetelor de răspuns, listarea cookie-urilor și a scripturilor setate de o pagină și interogarea înregistrărilor DNS publice. O verificare pasivă nu ghicește parole, nu trimite payloaduri de injecție, nu sondează URL-urile de administrare și nu scanează porturi. Tot ce urmează se poate face cu un browser, cu curl, openssl și dig.

Cum verificați certificatul TLS și data lui de expirare?

Citiți direct datele și numele din certificat și asigurați-vă că reînnoirea este automatizată.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Verificați ca notAfter să fie suficient de departe în viitor, ca certificatul să acopere atât example.com, cât și www.example.com, dacă le folosiți pe amândouă (vizualizatorul de certificate al browserului afișează numele), și ca browserul să nu afișeze avertismente. Durata de valabilitate a certificatelor se reduce conform Baseline Requirements ale CA/Browser Forum (secțiunea 6.3.2, versiunea 2.3.1 în octombrie 2026), în urma Ballot SC-081v3 (se deschide într-o filă nouă), adoptat pe 11 aprilie 2025:

Duratele scurte de valabilitate fac reînnoirea manuală riscantă, așa că verificați dacă furnizorul de găzduire sau instrumentul de certificate face reînnoirea automat. Verificați, de asemenea, că HTTP-ul simplu redirecționează către HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Rezultatul dorit este un răspuns 301 (sau 308) cu un antet location care începe cu https://.

Ce antete de securitate ar trebui să trimită un magazin online?

Un set restrâns de antete de răspuns blochează atacurile frecvente din browser, aproape fără niciun cost.

Verificați ce trimite magazinul dumneavoastră:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Două precauții. includeSubDomains blochează orice subdomeniu care funcționează doar prin HTTP, așa că verificați mai întâi subdomeniile. Preîncărcarea HSTS (preload) necesită un max-age de cel puțin 31536000 și includeSubDomains, așa că adăugați preload doar când toate subdomeniile sunt pregătite pentru HTTPS. Un CSP complet, care restricționează scripturile, merită implementat, dar OWASP subliniază că este complex de configurat și de întreținut, iar magazinele cu multe aplicații trebuie să îl testeze cu atenție.

Sunt cookie-urile dumneavoastră setate cu Secure, HttpOnly și SameSite?

Cookie-urile de sesiune și de coș ar trebui să aibă toate cele trei atribute, iar acestea se văd în antetele de răspuns Set-Cookie.

Dacă atributul SameSite nu este setat, browserele tratează cookie-ul ca Lax. Cookie-urile pe care propriile scripturi trebuie să le citească nu pot fi HttpOnly, așa că concentrați-vă pe cele care identifică un client autentificat sau un administrator.

curl -sI https://example.com/ | grep -i "^set-cookie"

Instrumentele pentru dezvoltatori din browser afișează aceleași informații, inclusiv cookie-urile setate de scripturi după încărcarea paginii.

Cum găsiți conținutul mixt?

Conținutul mixt înseamnă orice resursă încărcată prin HTTP pe o pagină livrată prin HTTPS, iar consola browserului îl listează.

MDN (se deschide într-o filă nouă) îl împarte în două grupe. Imaginile, fișierele audio și video sunt „actualizabile” (upgradable): browserele le solicită automat prin HTTPS. Scripturile, foile de stil, iframe-urile, fonturile și cererile fetch() sunt „blocabile” (blockable): browserele le blochează, ceea ce strică tot ce depindea de ele. Cererile actualizate către o simplă adresă IP sunt și ele blocate.

Pentru a-l găsi, deschideți consola pe șabloanele principale (pagina principală, colecție, produs, coș) și căutați http:// în codul temei, în conținutul paginilor și în setările aplicațiilor. Centrul de ajutor Shopify precizează că orice pagină a magazinului care conține o resursă care nu este livrată prin HTTPS este considerată nesigură (se deschide într-o filă nouă) și recomandă găzduirea resurselor pe Shopify sau livrarea lor prin HTTPS. Pe WooCommerce, verificați conținutul articolelor vechi și opțiunile temei, dacă site-ul a funcționat vreodată pe http://.

Cum identificați bibliotecile JavaScript învechite, cu CVE-uri cunoscute?

Listați bibliotecile pe care le încarcă fiecare pagină, citiți-le versiunile și comparați-le cu National Vulnerability Database.

Începeți cu jQuery. În consola browserului, $.fn.jquery returnează versiunea încărcată (jQuery API (se deschide într-o filă nouă)). Versiuni care trebuie semnalate:

Ambele probleme din 2020 sunt remediate în jQuery 3.5.0. O versiune vulnerabilă înseamnă că codul cu defect este prezent; dacă poate fi exploatat depinde de modul în care site-ul îi transmite date. WordPress include jQuery 3.5.1 începând cu versiunea 5.6 (se deschide într-o filă nouă), așa că un jQuery vechi pe un magazin WooCommerce indică un WordPress neactualizat sau o temă ori un plugin care își încarcă propria copie. Pe Shopify, verificați fișierele temei și aplicațiile care injectează scripturi.

Ce este security.txt și are nevoie magazinul dumneavoastră de unul?

Este un fișier text simplu care le spune cercetătorilor în securitate cum vă pot raporta o vulnerabilitate.

RFC 9116 (se deschide într-o filă nouă) (aprilie 2022, un RFC informativ, deci respectarea lui este voluntară) prevede că fișierul trebuie livrat prin HTTPS la /.well-known/security.txt, ca text/plain. Câmpurile Contact și Expires sunt obligatorii, iar RFC-ul recomandă o dată Expires la mai puțin de un an în viitor.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

Pe WooCommerce, puteți plasa fișierul pe server. Pe o platformă găzduită, verificați dacă puteți publica un fișier la acea cale; dacă nu, o adresă de contact pentru securitate, clar marcată pe pagina de contact, este totuși utilă.

Cum vă protejează DMARC magazinul de falsificarea e-mailurilor?

DMARC vă permite să le cereți furnizorilor de e-mail să pună în carantină sau să respingă mesajele care folosesc domeniul dumneavoastră în adresa From fără să treacă SPF sau DKIM aliniat.

O înregistrare cu p=none doar colectează rapoarte; nu oprește e-mailurile falsificate. Clienții se așteaptă să primească de pe domeniul dumneavoastră confirmări de comandă și e-mailuri de resetare a parolei, așa că merită blocat un mesaj de phishing care afișează exact domeniul dumneavoastră. Verificați-vă politica cu dig +short TXT _dmarc.example.com și consultați RFC 9989 (se deschide într-o filă nouă) pentru specificație. DMARC nu acoperă domeniile asemănătoare (lookalike), ci doar domeniul care publică înregistrarea.

Ce gestionează Shopify și ce controlați dumneavoastră pe WooCommerce?

Shopify administrează serverele din spatele magazinelor sale, în timp ce, la un magazin WooCommerce găzduit pe cont propriu, setările serverului rămân în grija dumneavoastră și a furnizorului de găzduire.

Când am verificat mai multe magazine găzduite de Shopify în octombrie 2026, răspunsurile lor includeau HSTS cu un max-age de aproximativ 91 de zile, X-Content-Type-Options: nosniff și un CSP cu upgrade-insecure-requests, în timp ce frame-ancestors diferea de la un magazin la altul. Shopify afirmă că este certificat ca fiind conform PCI DSS de nivel 1 (se deschide într-o filă nouă). Tema și aplicațiile instalate rămân responsabilitatea dumneavoastră.

Pe WooCommerce, ghidul de securizare (se deschide într-o filă nouă) WordPress recomandă să păstrați WordPress și pluginurile actualizate, să ștergeți pluginurile pe care nu le folosiți și să îl întrebați pe furnizorul de găzduire ce măsuri de securitate aplică.

De ce nu este acesta un test de penetrare?

Un test de penetrare încearcă în mod activ atacuri; verificările pasive doar observă.

NIST SP 800-115 definește testul de penetrare ca testare de securitate în care evaluatorii imită atacuri reale pentru a găsi modalități de a ocoli funcțiile de securitate ale unui sistem (glosarul NIST (se deschide într-o filă nouă)). Verificările pasive nu pot vedea defectele de pe server din pluginuri, parolele de administrator slabe sau refolosite, lipsa autentificării în doi pași, controlul defectuos al accesului sau codul vulnerabil care nu apare niciodată în sursa paginii. Folosiți-le ca bază de referință pe care o puteți repeta oricând. Pentru o asigurare mai profundă, comandați un test de penetrare cu un domeniu de aplicare stabilit în scris, pe sisteme pe care le dețineți sau pe care sunteți autorizat să le testați.

O scanare gratuită face o primă trecere prin magazinul dumneavoastră. Raportul de securitate a site-ului acoperă verificările pasive din acest articol, de la TLS și redirecționări până la antete, cookie-uri, conținut mixt, biblioteci învechite, security.txt și DMARC, cu remedieri pentru fiecare constatare. Ca orice analiză pasivă, nu poate garanta că un magazin este sigur.

Întrebări frecvente

Pun verificările de securitate pasive magazinul meu în pericol?

Nu mai mult decât o vizită obișnuită. Ele solicită aceleași pagini publice și înregistrări DNS pe care le-ar solicita orice browser sau server de e-mail și nu încearcă să se autentifice sau să trimită payloaduri de atac.

Pot adăuga antete de securitate pe Shopify?

Antetele de răspuns ale magazinului provin de la serverele Shopify, așa că, dacă lipsește unul de care aveți nevoie, contactați Shopify Support. O etichetă CSP <meta> în temă poate adăuga unele directive, dar MDN precizează că frame-ancestors nu este acceptată în <meta>.

O versiune veche de jQuery înseamnă că magazinul meu a fost spart?

Nu. Înseamnă că este încărcat cod cu vulnerabilități cunoscute, ceea ce crește riscul dacă site-ul transmite HTML nesigur către metodele afectate. Actualizați-l sau eliminați tema ori pluginul care îl încarcă.

Cât timp poate fi valabil acum un certificat TLS?

Certificatele de încredere publică emise începând cu 15 martie 2026 pot fi valabile cel mult 200 de zile. Limita scade la 100 de zile începând cu 15 martie 2027 și la 47 de zile începând cu 15 martie 2029.

Este obligatoriu un fișier security.txt?

RFC 9116 este un RFC informativ, așa că, potrivit standardului, publicarea fișierului este voluntară. Publicarea lui costă puțin și le oferă cercetătorilor o modalitate clară de a vă contacta.

O scanare pasivă fără probleme înseamnă că magazinul meu este sigur?

Nu. Arată că configurația publică pare corectă. Vulnerabilitățile de pe server, securitatea conturilor și defectele de logică de business necesită alte tipuri de testare.

Surse

• Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 (se deschide într-o filă nouă), CA/Browser Forum, 4 octombrie 2026
• Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (se deschide într-o filă nouă), CA/Browser Forum, 11 aprilie 2025
• Strict-Transport-Security (se deschide într-o filă nouă), MDN Web Docs, modificat ultima dată la 11 septembrie 2026
• CSP: frame-ancestors (se deschide într-o filă nouă), MDN Web Docs, modificat ultima dată la 27 august 2026
• X-Content-Type-Options (se deschide într-o filă nouă), MDN Web Docs, modificat ultima dată la 17 martie 2026
• Using HTTP cookies (se deschide într-o filă nouă), MDN Web Docs, modificat ultima dată la 17 septembrie 2026
• Mixed content (se deschide într-o filă nouă), MDN Web Docs, modificat ultima dată la 15 august 2026
• HTTP Security Response Headers Cheat Sheet (se deschide într-o filă nouă), OWASP Cheat Sheet Series, accesat la 22 octombrie 2026
• CVE-2020-11022 (se deschide într-o filă nouă), NIST National Vulnerability Database, publicat la 29 aprilie 2020
• CVE-2020-11023 (se deschide într-o filă nouă), NIST National Vulnerability Database, publicat la 29 aprilie 2020
• CVE-2019-11358 (se deschide într-o filă nouă), NIST National Vulnerability Database, publicat la 20 aprilie 2019
• .jquery (se deschide într-o filă nouă), jQuery API Documentation, accesat la 22 octombrie 2026
• Updating core jQuery to version 3, part 2 (se deschide într-o filă nouă), Make WordPress Core, 5 noiembrie 2020
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (se deschide într-o filă nouă), IETF, aprilie 2022
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (se deschide într-o filă nouă), IETF, mai 2026
• Enabling secure connections to your Shopify store (se deschide într-o filă nouă), Shopify Help Center, accesat la 22 octombrie 2026
• Security (se deschide într-o filă nouă), Shopify, accesat la 22 octombrie 2026
• Hardening WordPress (se deschide într-o filă nouă), WordPress Developer Resources, accesat la 22 octombrie 2026
• Penetration testing (glossary) (se deschide într-o filă nouă), NIST Computer Security Resource Center, cu trimitere la NIST SP 800-115 (septembrie 2008), accesat la 22 octombrie 2026