Cum funcționează auditul

Ce este auditul

Crocky Audit este un audit automat, din exterior, al unui site public. Citește site-ul de pe internet așa cum îl văd browserul unui vizitator, un motor de căutare și un server de e-mail, și raportează fiecare observație împreună cu dovada ei. Acoperă performanța, căutarea, accesibilitatea, securitatea, găzduirea, DNS-ul și e-mailul, tehnologiile folosite și o estimare dacă site-ul a fost construit cu unelte AI.

Nu se autentifică (decât cu parola unei previzualizări protejate, dată de proprietarul site-ului), nu testează logica aplicației și nu încearcă să exploateze ce găsește. Un raport descrie site-ul în momentul auditului.

Un audit, pas cu pas

Un audit parcurge etapele de mai jos, în ordine:

1. Prima cerere la adresa introdusă, cu cel mult 10 redirecționări urmate și o limită de 20 de secunde. Dacă site-ul nu răspunde, auditul se oprește cu această observație.
2. Refuz și acces: se citește robots.txt pentru un refuz adresat lui CrockyAudit (secțiunea următoare), iar o verificare anti-bot sau o poartă cu parolă sunt recunoscute înainte să ruleze orice altceva.
3. Infrastructură: TLS, DNS, serverele de e-mail, antetele răspunsului și verificarea căilor sensibile, prin conexiuni HTTP, DNS și SMTP obișnuite.
4. Verificări de platformă: panoul de găzduire, WordPress și WHMCS, fiecare doar când site-ul îl folosește.
5. Măsurători în browser, în Chromium: Lighthouse (mobil, apoi desktop), linkurile, accesibilitatea, capturile de ecran și verificarea AI.
6. Rezultatele: estimarea de carbon, scorurile, raportul și PDF-ul lui în engleză și în română.

Un audit standard citește pagina introdusă, de obicei prima pagină. Un audit aprofundat parcurge și site-ul: întâi sitemap-ul, apoi linkurile, până la 100 de pagini și trei niveluri în adâncime, în cel mult 60 de secunde, câte trei pagini deodată, fără ce interzice robots.txt. Lighthouse, capturile, TLS-ul și DNS-ul rămân pe prima pagină; linkurile se verifică pe fiecare pagină parcursă, iar accesibilitatea pe primele 10.

Un audit are 12 minute, sau 25 pentru unul aprofundat. Fiecare etapă are și limita ei: 20 de secunde pentru prima cerere, 180 de secunde pentru o rulare Lighthouse, 25 de secunde de verificări de accesibilitate pe pagină. O etapă care rămâne fără timp e raportată ca nerulată, iar restul auditului continuă.

Când coada e lungă, un audit gratuit poate rula într-o formă scurtată: Lighthouse doar pe mobil și capturi la două lățimi. Lista de verificări din raport arată ce a rămas pe dinafară.

Cum se identifică scanerul

Fiecare cerere are un User-Agent cu numele CrockyAudit și adresa https://audit.crocky.host/bot, unde scrie ce face scanerul. Cererile făcute din browser adaugă același nume la un User-Agent obișnuit de Chrome.

Un site refuză auditul cu un grup în robots.txt care numește CrockyAudit și interzice /: auditul se oprește atunci după prima cerere. Un grup pentru toți roboții (User-agent: *) nu oprește un audit cerut de cineva, dar parcurgerea aprofundată îi respectă regulile Disallow.

Securitate

Verificările de securitate se uită la ce primește de la site browserul oricărui vizitator și la o listă fixă de adrese care n-ar trebui să fie publice. Nu testează logica aplicației și nu încearcă să exploateze ce găsesc.

Ce cereri face scanerul și ce nu face niciodată

Aproape toate cererile sunt GET sau HEAD, aceleași pe care le trimite un browser sau un verificator de linkuri. Există două cereri POST, amândouă doar de citire: pe un site WordPress, un apel XML-RPC la system.listMethods, care listează metodele oferite și nu rulează niciuna; și, numai când proprietarul a scris în formularul auditului parola unui magazin Shopify, acea parolă trimisă paginii de parolă a magazinului.

Scanerul nu face niciodată următoarele:

• nu încearcă autentificări și nu ghicește parole: nicio forță brută, nicio listă de credențiale;
• nu trimite cod de atac: nicio injecție SQL, niciun cross-site scripting, nicio traversare de căi, nicio variere a parametrilor (fuzzing);
• nu trimite formulare, nu încarcă fișiere și nu creează, nu modifică și nu șterge nimic pe site;
• nu rezolvă CAPTCHA și nu ocolește verificările anti-bot. Când răspunde o verificare anti-bot în locul site-ului, scanerul așteaptă cel mult 15 secunde să treacă; dacă nu trece, verificările din spatele ei sunt raportate ca nerulate.

Răspunsurile se citesc doar cât îi trebuie unei verificări: primii 64 KB pentru confirmarea unui fișier sensibil, cel mult 512 KB dintr-o pagină phpinfo() publică. Fișierele nu se descarcă niciodată întregi. Un secret găsit de scaner nu e copiat în raport: dintr-o pagină phpinfo() publică, raportul numește variabilele care par să conțină credențiale, niciodată valorile lor. Numele de utilizator WordPress, valorile cookie-urilor și adresa, numele și căile serverului dintr-o pagină phpinfo() apar întregi doar contului care a rulat auditul; oricine altcineva are linkul, și orice PDF, le vede mascate.

Încărcarea serverului auditat

Verificarea căilor sensibile trimite cel mult 10 cereri deodată; 6 când primul octet al site-ului vine în 0,5 până la 1,2 secunde și 4 când vine mai târziu. Fiecare cerere așteaptă de trei ori timpul site-ului până la primul octet, dar nu mai puțin de 1,5 secunde și nu mai mult de 5. Verificarea se oprește după 45 de secunde, iar căile la care n-a ajuns sunt raportate ca neverificate. Dacă site-ul răspunde 429 Too Many Requests, scanerul face o pauză de 3 secunde și mai întreabă o dată acele căi, câte două deodată; ce e refuzat și atunci apare ca neverificat, niciodată ca absent. Celelalte verificări paralele (linkurile, adresele panourilor de găzduire) rulează câte cel mult 6 deodată.

HTTPS, redirecționări și antetele răspunsului

Auditul pornește de la adresa introdusă (cu https:// adăugat când lipsește schema) și urmează cel mult 10 redirecționări. Dacă pagina la care ajunge nu e servită prin HTTPS, observația e critică. Un lanț de peste două redirecționări e raportat ca un cost de performanță (mediu). Antetele de mai jos se citesc din răspunsul acelei pagini finale.

Nota Content-Security-Policy

Nota citește ce aplică browserul pentru scripturi: script-src, sau default-src când script-src lipsește. 'unsafe-inline' în style-src nu o scade.

• A: nonce-uri, hash-uri sau 'strict-dynamic', nicio sursă nesigură, object-src 'none' și un base-uri restrâns. Nicio observație.
• B: o politică rezonabilă, fără nonce-uri, hash-uri sau 'strict-dynamic'. Gravitate mică.
• C: modul report-only, sau nici script-src, nici default-src. Gravitate medie.
• D: una dintre: scripturi inline permise ('unsafe-inline' fără nonce, hash sau 'strict-dynamic', oricare dintre acestea făcând browserul să-l ignore), 'unsafe-eval', sau surse de scripturi deschise către aproape orice server (*, https:, http:, data:). Gravitate mică.
• F: sunt permise atât scripturile inline, cât și eval. Gravitate medie, la fel ca lipsa oricărei politici.

O politică slabă e raportată ca un strat de protecție care lipsește, nu ca o vulnerabilitate. Din politică mai vin două observații: lipsesc și frame-ancestors, și X-Frame-Options (medie), iar object-src nu e 'none' (mică).

Cookie-uri

Fiecare cookie din antetele Set-Cookie ale răspunsului paginii e verificat pentru Secure, HttpOnly și SameSite. O singură observație enumeră lipsurile: medie când unui cookie îi lipsește Secure, mică în rest. Cookie-urile puse mai târziu de scripturi, inclusiv cele terțe, sunt numărate în trecerea cu browserul (vezi Vizual).

Conținutul paginii

• Conținut mixt: un script, o foaie de stil, o imagine, un cadru sau un fișier media pe care o pagină HTTPS îl încarcă prin http://. Un link spre alt site nu contează. Gravitate mare.
• Subresource Integrity: pagina încarcă peste două scripturi și foi de stil de pe alte servere, iar sub 30% au atributul integrity. Gravitate medie.
• Listarea directoarelor: o pagină „Index of /” la rădăcina site-ului sau la /icons/. Gravitate mare.
• security.txt: niciun fișier la /.well-known/security.txt. Gravitate mică.

TLS

O conexiune TLS cu serverul site-ului, care cere OCSP stapling și oferă HTTP/2. Se raportează: protocolul și cifrul negociate, forward secrecy, expirarea certificatului (mare sub 14 zile, critică după expirare), lanțul, algoritmul de semnătură și mărimea cheii (slabă sub RSA de 2048 de biți sau EC de 224), plus răspunsul OCSP atașat, când certificatul indică un server OCSP. Încă două conexiuni, de câte 3 secunde, verifică dacă TLS 1.0 și TLS 1.1 mai sunt acceptate.

Căi sensibile

Scanerul cere 77 de căi fixe. Fiecare e un fișier sau o pagină care îi dă unui atacator ceva folosibil când serverul o servește (credențiale, cod sursă, o bază de date, un ecran de administrare, configurația serverului) și fiecare e o greșeală frecventă la publicare: un fișier care trebuia să rămână pe calculatorul unui programator sau în spatele configurației serverului. Lista e fixă, ca două audituri ale aceluiași site să pună aceleași întrebări. Fiecare cale are o gravitate fixă, după ce conține de obicei acel tip de fișier.

Ce înseamnă un rezultat pozitiv

O cale contează doar când serverul răspunde la ea cu un cod 2xx. Redirecționările nu se urmează, iar 401, 403 și 404 nu contează niciodată. Când site-ul răspunde la adrese inexistente cu altceva decât 404 (multe aplicații single-page răspund 200 la orice), sau când calea e un fișier de date (.env, .sql, .zip, .git/), scanerul citește și primii 64 KB și păstrează rezultatul doar dacă diferă de răspunsul site-ului la două adrese aleatoare care nu pot exista și, la un fișier de date, nu e o pagină HTML. Un rezultat pozitiv înseamnă deci că serverul a servit conținut la acea adresă. În afară de o pagină phpinfo() publică, conținutul nu e analizat și nu e păstrat. O cale pe care verificarea n-a apucat s-o ceară, sau la care a răspuns un scut anti-bot, apare ca neverificată, nu ca fiind în regulă.

Cereri făcute doar pe unele platforme

• WordPress, când site-ul îl folosește: /xmlrpc.php (un GET, apoi singurul apel system.listMethods), /wp-json/wp/v2/users (primii 4 KB), /?author=1 până la /?author=6 (se citește antetul Location al redirecționării, fără s-o urmeze), readme.html când pagina nu spune versiunea, 8 nume de copii ale lui wp-config.php și readme.txt pentru 38 de pluginuri des folosite (HEAD).
• WHMCS, când site-ul îl folosește: 20 dintre paginile lui publice și resturi cunoscute (instalatorul, configuration.php, copii SQL, /attachments/, /downloads/).
• Panoul de găzduire: 16 adrese la care răspund panourile de control (/cpanel/, /plesk-stat/, /webuzo/ și altele). Un panou e numit doar când răspunsul îl numește: o redirecționare spre portul sau subdomeniul panoului, ori o pagină de autentificare care poartă numele lui. Un cod de stare singur nu e o dovadă.

Programe cu vulnerabilități cunoscute

Versiunile vin din ce publică site-ul însuși (etichete generator, căile fișierelor, fișiere readme). WordPress, Drupal și Joomla mai vechi de 6.5, 10 și 5 sunt raportate ca depășite (mare). Nucleul WordPress e verificat cu API-ul de versiuni WordPress.org; pluginurile și temele WordPress cu baza de vulnerabilități Wordfence, a cărei notă CVSS dă gravitatea; bibliotecile JavaScript cu baza Retire.js. O versiune pe care site-ul n-o arată nu poate fi verificată, iar raportul spune asta.

Site-uri protejate cu parolă

Înaintea celorlalte verificări, scanerul se uită la ce a răspuns: autentificare HTTP basic, o publicare Vercel sau Netlify protejată, Cloudflare Access, parola unui magazin Shopify, o pagină de mentenanță WordPress sau altă pagină de autentificare. Primele cinci pot fi trecute cu parola pe care proprietarul o scrie la Opțiuni avansate; parola e păstrată criptat și ștearsă imediat ce pornește auditul. O pagină de mentenanță sau o autentificare necunoscută nu pot fi trecute din afară, așa că auditul se oprește acolo și spune de ce, în loc să raporteze pagina de autentificare drept site.

Performanță

Lighthouse 12 rulează de două ori pe prima pagină, una după alta: mobil (ecran de 412 x 823, procesor încetinit de 4 ori, 150 ms dus-întors, 1,6 Mbit/s) și desktop (1350 x 940, fără încetinirea procesorului, 40 ms, 10 Mbit/s). Acestea sunt profilurile standard Lighthouse. Scorul de performanță e cel de pe mobil; cel de pe desktop îi ia locul doar când rularea pe mobil eșuează. O rulare măsurată cât procesorul scanerului era ocupat se repetă o dată.

Fiecare audit Lighthouse cu scor sub 0,9 devine o observație, cu explicația dată de Lighthouse. Gravitatea urmează scorul auditului: Largest Contentful Paint, de exemplu, e mare sub 0,5 și medie în rest.

Pragurile bun și slab de lângă fiecare metrică sunt cele publicate de Google: Largest Contentful Paint 2,5 și 4 s, Cumulative Layout Shift 0,1 și 0,25, First Contentful Paint 1,8 și 3 s, Total Blocking Time 200 și 600 ms (pragurile Lighthouse), iar pentru datele de teren Interaction to Next Paint 200 și 500 ms și Time to First Byte 0,8 și 1,8 s.

Când raportul Chrome UX al Google are date de teren pentru originea site-ului (28 de zile de vizite reale din Chrome, pe telefon și desktop), raportul le arată lângă cifrele de laborator. Nu intră în scor.

Încă o cerere și o navigare în browser măsoară cât îi ia serverului să livreze pagina și dacă pagina ține browserul ocupat. Peste 1,2 secunde e o observație de găzduire (medie), peste 2,5 secunde mare. Se raportează și o pagină mai grea de 5 MB (mare), text trimis fără compresie (medie) și gzip acolo unde Brotli ar comprima mai bine (informativă).

Căutare (SEO)

Se citesc din HTML-ul paginii și, când pagina își construiește conținutul cu JavaScript, și din pagina randată:

• titlul (lipsă: mare; sub 10 sau peste 70 de caractere: mică) și meta descrierea (lipsă: medie; sub 50 sau peste 200 de caractere: informativă);
• linkul canonic, Open Graph (titlul și imaginea) și twitter:card;
• titlurile (niciun H1, sau mai multe) și imaginile fără text alternativ (când lipsește la peste 20% dintre ele; raportat la accesibilitate);
• datele structurate: dacă există JSON-LD, apoi câmpurile obligatorii și cele folosite de Google pentru rezultatele îmbogățite, verificate pe aproximativ 40 de tipuri schema.org;
• robots.txt și sitemap-ul, inclusiv până la 5 sitemap-uri incluse;
• linkurile stricate: cele interne (peste 5 stricate: mare) și un eșantion de cel mult 50 de linkuri externe (mică). Un răspuns care înseamnă „nu acum” (429, 408, 503, o verificare anti-bot, un firewall care refuză orice cerere) apare ca neverificat, nu ca stricat;
• într-un audit aprofundat, perechile hreflang: fiecare pagină alternativă trebuie să existe și să trimită înapoi.

Scorul SEO e scorul SEO din Lighthouse; verificările de mai sus sunt observații și nu îl schimbă.

Accesibilitate

axe-core 4.11 rulează regulile marcate pentru WCAG 2.0, 2.1 și 2.2, nivelurile A și AA, plus regula target-size, pe fiecare pagină auditată: prima pagină într-un audit standard, până la primele 10 pagini parcurse într-unul aprofundat, câte 25 de secunde pe pagină. O regulă care cere judecata unui om (contrastul peste o imagine, de exemplu) apare ca necesitând verificare manuală, nu ca trecută sau picată.

Scorul de accesibilitate pornește de la scorul de accesibilitate din Lighthouse și scade jumătate din ponderea gravității pentru fiecare observație axe (vezi Gravitate). Regulile automate acoperă doar o parte din ce cere WCAG, deci un rezultat curat aici nu e o declarație de conformitate.

Găzduire

• timpul de răspuns al serverului (vezi Performanță) și dacă serverul vorbește HTTP/2; HTTP/3 e notat când serverul îl anunță (Alt-Svc), fără să fie testat;
• IPv6: dacă domeniul publică o înregistrare AAAA;
• panourile de găzduire și sistemele de facturare (12 panouri, ca cPanel, Plesk și DirectAdmin; WHMCS, Blesta, HostBill și ClientExec), din antete, cookie-uri, pagină și adresele de la Căi sensibile;
• unde e serverul: țara și rețeaua, dintr-o bază locală de adrese IP;
• înregistrarea și expirarea domeniului, din RDAP (pentru .ro, din WHOIS-ul registrului, unde expirarea e estimată după data înregistrării).

DNS și e-mail

Înregistrări citite: A, AAAA, NS, MX, TXT, CAA, SPF, DMARC, DKIM pentru 7 selectori uzuali (default, google, selector1, selector2, k1, mail, dkim), BIMI, TLS-RPT și MTA-STS (înregistrarea și fișierul de politică). DNSSEC e verificat printr-un resolver public DNS-over-HTTPS.

Se raportează: un SPF care permite oricărui server să trimită sau care cere peste 10 interogări DNS, un DMARC care doar monitorizează (p=none) sau folosește aliniere relaxată, chei DKIM de 1024 de biți sau mai puțin, DNSSEC oprit, lipsa unei înregistrări CAA și dacă domeniul e pe lista de preîncărcare HSTS (hstspreload.org). Cele mai multe contează la scorul de securitate.

Pentru cel mult 6 servere de e-mail, în ordinea priorității: o conexiune la portul 25 care citește salutul, trimite EHLO și verifică dacă e oferit STARTTLS, fără să deschidă o sesiune TLS și fără să trimită e-mail. Fiecare server e căutat și în 6 liste publice de blocare (Spamhaus ZEN, Barracuda, SpamCop, UCEPROTECT nivelurile 1 până la 3).

Tehnologii

Tehnologiile sunt recunoscute din pagină, din antetele ei și din căile fișierelor, cu o listă de semnături derivată din variantele open-source ale Wappalyzer și cu semnele de build ale Next.js, Nuxt, SvelteKit, Remix, Gatsby, Astro, Angular, Eleventy, Hugo și Jekyll. Versiunile ieșite din suport sunt semnalate cu date de la endoflife.date. Versiunile cu vulnerabilități cunoscute sunt la Securitate.

Vizual

În Chromium, prima pagină e capturată la 360, 768, 1280 și 1920 de pixeli lățime (zona vizibilă, nu pagina întreagă). Din trecerea la 1280 vin cele opt culori dominante, familiile de fonturi web declarate de foile de stil, erorile din consola browserului și excepțiile neprinse în timpul încărcării, cookie-urile puse la încărcare (proprii și terțe) și cererile către 22 de domenii de urmărire cunoscute.

Carbon

Grame de CO₂ pe vizită, din greutatea paginii măsurată de Lighthouse, cu versiunea 4 a modelului Sustainable Web Design din CO2.js (Green Web Foundation). Dacă serverul folosește energie verde aflăm din verificarea Green Web Foundation, ca da sau nu; un răspuns necunoscut contează ca nu. Estimarea e pentru o primă vizită. Nu există când Lighthouse n-a putut rula.

Verificarea AI

Dacă nu debifezi căsuța, auditul caută și semne că pagina a fost generată sau asamblată de un builder AI ori de un agent de programare: amprente de builder, 49 de elemente de pagină cu nume și dovezi citate, și felul în care a fost pus cap la cap CSS-ul. Verdictul e unul din cinci:

• Confirmat: un artefact de build numește unealta (o etichetă generator, un script de builder, un CLAUDE.md servit).
• Probabil: două semnale puternice în stivă, sau un grup de semne măsurate în componente, cu puține semne de lucru făcut de mână.
• Posibil: s-au găsit componente standard; le folosesc și profesioniștii, așa că nu afișăm niciun procent.
• Nicio dovadă găsită: nimic care să indice un build generat. Lipsa dovezilor nu e dovada lipsei: a apărut la 9% din site-urile făcute cu AI pe care le-am măsurat și la cam o treime din cele făcute cu un agent de programare.
• Nemăsurat: pagina n-a putut fi descărcată sau randată, ori are prea puțin conținut de măsurat (o aplicație pe canvas, o pagină goală).

Pe site-uri despre care știm cum au fost făcute, un verdict Confirmat sau Probabil a fost corect în 98% din cazuri și a prins 86% din site-urile construite cu AI, dar doar cam o treime din cele ale căror autori au folosit un agent de programare. Site-urile făcute de designeri pe același kit de componente ajung la Posibil, intenționat.

Estimare automată din semnale publice, nu o constatare despre un site sau despre autorii lui.

Gravitate

Fiecare verificare are în codul scanerului o gravitate fixă, aleasă după ce îi permite problema cuiva să facă sau cât îl costă pe un vizitator. Câteva depind de dovadă: o cale expusă ia gravitatea tipului ei de fișier, o lipsă la cookie-uri e medie doar când lipsește Secure, observația CSP urmează nota, iar o vulnerabilitate cunoscută ia nota dată de baza ei de date. Scara e a scanerului; nu e CVSS.

Cum se calculează scorurile

• Performanță și SEO: scorurile Lighthouse de pe mobil.
• Accesibilitate: scorul de accesibilitate din Lighthouse, minus jumătate din ponderea fiecărei observații axe.
• Securitate și găzduire: 100, minus o pondere pentru fiecare observație din categorie: informativă 1, mică 3, medie 8, mare 18, critică 35. O singură observație scade cel mult 25 de puncte, iar observațiile mici și informative împreună cel mult 15.
• Securitatea recuperează în plus până la 30 de puncte pentru bune practici măsurate (TLS 1.3 +6, forward secrecy +4, o cheie puternică +3, HTTP/2 +3, OCSP stapling +2, TLS 1.0 și 1.1 refuzate câte +1, MTA-STS +5 în modul enforce sau +2 în testare, DMARC +5 la quarantine sau reject ori +2 la none, DNSSEC +2, CAA +2, TLS-RPT +2) și nu scade sub 30 decât dacă site-ul nu are HTTPS, are certificatul expirat sau conexiunea TLS eșuează.
• Scorul general: media celor cinci scoruri care au putut fi măsurate.

Toate verificările sunt listate

Raportul listează toate verificările, inclusiv pe cele care n-au găsit nimic, fiecare într-una din cinci stări: a găsit ceva, a trecut, cere verificare manuală, nu se aplică (cu motivul, de pildă „niciun server de e-mail”) sau n-a putut rula (cu motivul, de pildă o limită de timp, o verificare anti-bot sau o limită de cereri). Scanerul are 107 verificări proprii cu nume, plus câte un rând pentru fiecare cale cerută, fiecare audit Lighthouse, fiecare regulă axe și fiecare element al verificării AI.

Un site lent sau care refuză nu e citit niciodată ca fiind în regulă. Așteptările se lungesc după timpul de răspuns al site-ului (vezi Încărcarea serverului auditat), un răspuns care înseamnă „nu acum” se mai încearcă o dată și apoi apare ca neverificat, iar dacă site-ul nu mai răspunde pe parcurs (se verifică înainte de Lighthouse, de verificarea linkurilor și de verificările din browser), etapele rămase sunt sărite, iar raportul spune că site-ul a încetat să răspundă.

Ce nu poate găsi un audit automat din exterior

• Nimic din spatele unei autentificări: conturi, panouri de administrare, finalizarea comenzii. Scanerul vede ce vede un vizitator anonim.
• Greșeli în logica aplicației, în controlul accesului sau în tratarea datelor primite (injecții, autorizare greșită, referințe directe nesigure la obiecte). Ca să le găsești trebuie un om care testează cu permisiune scrisă.
• Interiorul serverului: nivelul actualizărilor, permisiunile fișierelor, configurația care nu se vede într-un răspuns, alte site-uri de pe aceeași mașină.
• Programe vulnerabile care nu-și arată versiunea și vulnerabilități care nu sunt încă într-o bază publică.
• Paginile care n-au fost auditate: un audit standard citește o pagină, unul aprofundat cel mult 100.
• Ce se schimbă după audit: un raport descrie site-ul într-un singur moment.

Lipsa observațiilor înseamnă deci că niciuna dintre aceste verificări n-a găsit o problemă, nu că site-ul e sigur. O observație consemnează o situație și ce s-a văzut; singură, nu dovedește că situația poate fi exploatată.

Ce păstrăm și cât timp

• Rapoartele (adresa, scorurile, observațiile și dovezile) rămân la linkul lor cât timp funcționează serviciul. Linkul are 32 de caractere hexazecimale aleatoare, cam 3,4 x 10³⁸ posibilități. Rapoartele nu sunt listate și nu sunt publicate, iar motoarelor de căutare li se cere să nu le indexeze.
• PDF-urile, capturile și copia HTML a unui raport se șterg după 30 de zile; un PDF se tipărește din nou când îl cere cineva.
• Parola unui site protejat e păstrată criptat și ștearsă când pornește auditul, sau după 60 de minute dacă nu pornește.
• După 12 luni, datele personale găsite pe site-ul auditat ies din raport: adresele de contact și numerele de telefon devin numere totale, adresa poștală și punctul de pe hartă se șterg, iar numele WordPress și valorile cookie-urilor rămân mascate definitiv.
• Adresa IP și browserul celui care a cerut auditul se păstrează 30 de zile; adresa de e-mail pentru mesajul „raport gata” se șterge după ce mesajul pleacă, sau după o zi.
• Toate detaliile sunt în Politica de confidențialitate.

Întrebări despre scaner: audit@crocky.host