Locked mode contra Test mode

Când creezi o bază Firestore sau un bucket de Storage, Firebase îți pune o singură întrebare de securitate: pornești în „Locked mode” sau în „Test mode”. Alegerea durează zece secunde și decide dacă datele tale sunt închise tuturor sau deschise oricui. Cei mai mulți aleg varianta care „merge” imediat, iar aceea e fix cea care scapă datele afară.

De ce contează atât de mult regulile

Firebase e un backend fără server între client și date. Aplicația ta din browser sau din telefon vorbește direct cu baza de date și cu stocarea, prin API-ul Firebase. Nu există, implicit, un cod al tău pe server care să verifice fiecare cerere. Singurul lucru care decide cine are voie să citească și să scrie sunt regulile de securitate, numite Security Rules.

Consecința e directă: dacă regulile sunt greșite, nu mai există nimic în spate care să te salveze. Nu e ca la o aplicație clasică, unde un controller pe server mai poate refuza o cerere. Aici regula e prima și ultima linie de apărare. De aceea o alegere aparent banală de la creare cântărește cât toată arhitectura de acces a aplicației.

Cele două moduri, cuvânt cu cuvânt

Când pornești, Firebase îți oferă două seturi de reguli gata scrise. „Locked mode” refuză accesul tuturor. „Test mode” îl deschide oricui, cu o dată de expirare pusă de obicei la 30 de zile. Iată exact ce scrie în fiecare.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;   // Locked mode: nimeni, din start
    }
  }
}

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      // Test mode: oricine, până la data asta
      allow read, write: if request.time < timestamp.date(2026, 10, 26);
    }
  }
}

Documentația oficială Firebase, la capitolul de pornire, recomandă „Test mode” pentru început și spune limpede ce înseamnă: regula „permite oricui să citească și să suprascrie datele tale”. Nu e o ascunzătoare, e scris pe față. Test mode e proiectat pentru dezvoltare locală rapidă, când vrei să vezi aplicația mergând fără să te oprești să scrii reguli. Problema apare când acel default ajunge, neatins, în producție.

Regula practică: pornește din Locked

Recomandarea de securitate e simplă și o repetă și OWASP, prin categoria „Security Misconfiguration”, urcată pe locul 2 în Top 10 din 2025: pornește din starea închisă și deschide exact cât ai nevoie. Începi din Locked mode, apoi scrii reguli care leagă fiecare acces de un utilizator autentificat și de proprietarul datelor. Restul cursului arată cum se scriu acele reguli, pas cu pas.

Diferența dintre cele două moduri nu e despre cât de priceput ești. E despre direcția în care greșești când uiți. Dacă pornești din Locked și uiți să deschizi o cale, aplicația nu merge, deci observi imediat și repari. Dacă pornești din Test și uiți să închizi, aplicația merge perfect, iar tu nu afli că oricine îți poate citi baza până când nu o face cineva. Un default sigur eșuează zgomotos; unul nesigur eșuează în tăcere.

Alegerea asta apare, de fapt, de mai multe ori. Firestore, Realtime Database și Storage îți cer fiecare, separat, să decizi între cele două moduri. E ușor să o faci corect o dată, la baza de date, și să o uiți la Storage, unde stau fișierele, sau invers. De aceea nu există o singură bifă „am securizat Firebase”: fiecare serviciu e o decizie proprie, iar checklistul din final le tratează pe rând, nu ca pe una moștenită de la prima.

De reținut

• Firebase nu are server între client și date; regulile de securitate sunt prima și ultima linie de apărare.
• La creare alegi între Locked mode („allow ... if false”, refuză tot) și Test mode („if request.time < ...”, deschis oricui, expiră în circa 30 de zile).
• Documentația oficială recomandă Test mode la pornire și spune că „permite oricui să citească și să suprascrie datele tale”.
• Pornește din Locked și deschide controlat: un default sigur eșuează zgomotos, unul nesigur eșuează în tăcere.