Fișierul .env pe hosting: unde îl păstrezi și ce faci dacă a fost expus

Fișierul .env este folosit de multe aplicații pentru configurare: conexiunea la baza de date, servicii externe și alte valori ale mediului. Formatul este util, dar fișierul poate conține secrete. Dacă devine accesibil prin web, consecințele depind de acreditările stocate și de drepturile asociate lor.

Verifică rădăcina publică a aplicației

Într-o aplicație care separă codul de directorul public, serverul web trebuie configurat să servească acel director public, conform documentației proiectului. Nu muta întregul proiect în rădăcina publică doar pentru a face pagina principală să funcționeze.

Confirmă configurația domeniului și a subdomeniilor. O variantă de test sau o copie veche poate folosi alt director decât instalarea principală. Verifică și arhivele de publicare, fișierele cu extensii .bak și copiile de configurare lăsate de editor.

Testează fără să afișezi secretele

Pe propriul domeniu, poți verifica un răspuns fără să imprimi corpul în terminal:

curl --silent --show-error --output /dev/null --write-out '%{http_code}
' https://exemplu.ro/.env

Înlocuiește domeniul. Un 200 este un semnal pentru investigație, dar poate reprezenta și o pagină generică a aplicației. Un 403 sau 404 pentru această adresă nu demonstrează că toate copiile fișierului sunt protejate. Verificarea completă presupune inspecția configurației și, când este necesar, a răspunsului într-un mediu privat.

Restrânge accesul și drepturile locale

Ține fișierele cu secrete în afara zonelor publice atunci când arhitectura permite. Contul aplicației trebuie să poată citi ceea ce îi este necesar, fără acces inutil pentru alți utilizatori. Nu aplica aceeași comandă chmod pe toate fișierele fără să verifici proprietarul și modelul de execuție.

Separă acreditările de test de cele de producție. Nu pune valorile reale în exemple, tichete publice sau depozite de cod. Un fișier .env.example poate documenta numele variabilelor cu valori demonstrative, fără să reproducă secretele instalării.

Dacă expunerea s-a produs, rotește acreditările

Blochează accesul, păstrează datele necesare investigației și identifică intervalul posibil de expunere. Tratează secretele accesibile ca potențial compromise. Schimbă sau revocă acreditările afectate și verifică utilizarea lor în serviciile asociate.

Planifică ordinea schimbărilor pentru a nu întrerupe necontrolat aplicația. Actualizează configurația și repornește procesele care păstrează valorile în memorie. O cheie principală folosită la criptarea datelor cere procedura cadrului software: înlocuirea ei fără plan poate face datele existente inutilizabile.

Verifică urmele și previne reapariția

Inspectează logurile relevante, istoricul publicărilor și copiile distribuite echipei. Dacă un secret a ajuns în istoricul Git, ștergerea fișierului din ultima revizie nu îl revocă. Evită includerea secretelor în loguri și redactează informațiile înainte de a le trimite suportului.

Pentru o instalare pe XSERVERE, confirmă directorul public al domeniului și metoda de configurare permisă. Controlul găzduirii și gestionarea acreditărilor aplicației trebuie verificate împreună.

Surse

• OWASP — Secrets Management — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
• OWASP — Logging — https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html