Plik .env jest publicznie dostępny

Co to jest

Plik .env w katalogu głównym Twojej witryny (https://example.cz/.env) jest swobodnie dostępny. Gdy ktoś go pobierze, otrzyma wszystko, co jest w nim zapisane.

Dlaczego to problem

.env zwykle zawiera:

Gdy atakujący zdobędzie te wartości, zwykle jest po grze (game over). Pobierze sobie bazę danych, podpisze JWT z uprawnieniami administratora, wyśle phishing przez Twój SMTP. Nie musi w ogóle eksploitować niczego w aplikacji.

To najczęstszy „głupi błąd”, jaki zauważamy. Najczęściej zdarza się wtedy, gdy aplikacja jest wdrażana przez git pull bezpośrednio do public_html i nikt nie uświadomił sobie, że .env również trafia do webroot.

Jak to naprawić

Krok 1 — natychmiast zablokować dostęp

nginx:

location ~ /\.env {
    deny all;
    return 404;
}

Apache (.htaccess w katalogu root):

<Files ".env">
    Require all denied
</Files>

Po wdrożeniu sprawdź: curl -I https://example.cz/.env — powinno zwrócić 403 lub 404.

Krok 2 — ZROTOWAĆ wszystkie sekrety, które tam były

Jeśli .env był publicznie dostępny choćby przez chwilę, zakładaj, że ktoś już go ma. Wygeneruj nowe:

  1. Hasło do bazy danych.
  2. Wszystkie klucze API (Stripe, Mailgun itd. — w ich panelach administracyjnych jako „rotate” / „revoke”).
  3. Sekret JWT (po wymianie wszyscy zalogowani użytkownicy będą musieli zalogować się ponownie — to w porządku).
  4. Hasło SMTP.

Krok 3 — przenieść .env poza webroot

Docelowo .env powinien znajdować się powyżej poziomu public_html. Aplikacja czyta go ze ścieżki bezwzględnej, a serwer WWW nigdy się do niego nie dostanie.

/var/www/example.cz/
├── app/
│   └── .env          ← tutaj
└── public_html/      ← document root
    └── index.php

Krok 4 — sprawdź historię gita

Jeśli .env kiedykolwiek został scommitowany do gita, pozostaje w historii na zawsze. Użyj BFG Repo-Cleaner lub git filter-repo i force-push. Otwarte repozytorium bez force-pusha = sekrety wciąż dostępne.

Materiały źródłowe