.env-bestand beheren: geheimen veilig houden

Een env-bestand is de meest gangbare manier om de geheimen op te slaan die je project nodig heeft om te draaien, maar die nooit in de codrepository terecht mogen komen: API-sleutels, databasewachtwoorden, tokens. Het idee is simpel: je scheidt configuratie van code. Dezelfde codebase draait met verschillende waarden op je ontwikkelmachine, in een testomgeving en op de live server; het enige dat verandert is het .env-bestand in die omgeving. In dit artikel behandel ik de praktische regels om .env-bestanden veilig te beheren, de fouten die mensen het vaakst maken, en wat je doet als een geheim lekt.

Waarom een .env-bestand gebruiken?

Geheimen rechtstreeks in je broncode schrijven (hardcoden) is een van de meest voorkomende beveiligingsfouten. Zodra je een API-sleutel in config.php zet en naar Git pusht, is die sleutel ingebakken in de volledige geschiedenis van de repository; zelfs nadat je hem verwijdert, blijft hij in de commitlog staan. Een .env-bestand lost dit op door geheime gegevens volledig buiten versiebeheer te houden.

• Scheiding: de code mag openbaar zijn, de geheimen niet.
• Waarden per omgeving: local, staging en productie verbinden met verschillende databases en sleutels.
• Eenvoudige rotatie: een sleutel wijzigen betekent één regel aanpassen, zonder code-uitrol.

De structuur van een .env-bestand

Het formaat is een eenvoudige SLEUTEL=waarde-lijst; elke regel is één variabele. De meeste bibliotheken ondersteunen commentaarregels die met # beginnen.

# Applicatie
APP_ENV=production
APP_DEBUG=false

# Database
DB_HOST=127.0.0.1
DB_DATABASE=portfolio
DB_USERNAME=app_user
DB_PASSWORD=een-heel-geheim-wachtwoord

# Externe diensten
STRIPE_SECRET=sk_live_xxx
MAIL_PASSWORD="een waarde met spaties heeft aanhalingstekens nodig"

Een paar praktische punten: als een waarde spaties of speciale tekens bevat, zet hem tussen dubbele aanhalingstekens; plaats geen overbodige spaties rond het isgelijkteken; en waarden worden altijd als een string gelezen. Dat betekent dat APP_DEBUG=false eigenlijk de tekst "false" is, niet de boolean false van je taal. Het omzetten naar het juiste type is jouw taak; de env()-helper van Laravel zet waarden als true/false/null bijvoorbeeld automatisch om, terwijl een kale getenv() dat niet doet.

De belangrijkste regel: .env komt nooit in Git

Een .env-bestand per ongeluk committen is de nummer één oorzaak van geheimlekken. Je voorkomt het door een regel toe te voegen aan een .gitignore in de projectwortel:

# .gitignore
.env
.env.*
!.env.example

De regel !.env.example stelt het voorbeeldbestand (dat ik zo uitleg) vrij van de zwarte lijst. Heb je het bestand al per ongeluk gecommit, dan is het toevoegen aan .gitignore niet genoeg — Git volgt het al. Om het volgen te stoppen:

git rm --cached .env
git commit -m "stop tracking .env"

Onthoud: dit commando wist het bestand niet uit de geschiedenis, het stopt alleen met volgen in toekomstige commits. Als het geheim echt in een openbare geschiedenis terecht is gekomen, zie dan de leksectie hieronder.

Het team synchroon houden met .env.example

Omdat de echte .env niet in de repo zit, hoe weet een nieuwe ontwikkelaar die het project klont welke variabelen nodig zijn? Het antwoord is het bestand .env.example (soms .env.sample): het bevat dezelfde sleutels, maar de waarden zijn leeg of nep. Dit bestand gaat wél de repo in en fungeert als een vorm van documentatie.

# .env.example
APP_ENV=local
APP_DEBUG=true
DB_HOST=127.0.0.1
DB_DATABASE=
DB_USERNAME=
DB_PASSWORD=
STRIPE_SECRET=

De installatiestap is meestal simpel: kopieer het bestand met cp .env.example .env en vul daarna de echte waarden in. Maak er een gewoonte van het voorbeeldbestand bij te werken telkens als je een nieuwe variabele toevoegt; anders breekt de installatie van een teamgenoot op een ontbrekende sleutel waar hij urenlang naar zoekt, terwijl hij zich afvraagt "waarom werkt dit niet?".

Veilig gebruik op servers en in CI/CD

Beperk op live servers de bestandsrechten van .env zodat alleen de gebruiker die de applicatie draait het kan lezen:

chmod 600 .env

Zorg op gedeelde hosting of een VPS dat het bestand buiten de webroot staat (bijvoorbeeld public/); anders kan een verkeerd geconfigureerde server het als platte tekst serveren. Gebruik in CI/CD-pipelines (GitHub Actions, GitLab CI) in plaats van een .env-bestand in de repo de secrets / omgevingsvariabelen-functie van het platform. Die geheimen worden versleuteld opgeslagen, gemaskeerd in logs en alleen tijdens het draaien van de pipeline als omgevingsvariabele geïnjecteerd. Bij grotere opstellingen komen speciale secret-managers als HashiCorp Vault, AWS Secrets Manager of Doppler in beeld.

• Echo geheimen nooit naar pipelinelogs.
• Verspreid productiegeheimen niet naar de lokale machines van ontwikkelaars; gebruik aparte, minder bevoorrechte sleutels.
• Roteer sleutels met regelmatige tussenpozen.

Wat te doen als een geheim lekt?

Stel dat een API-sleutel per ongeluk in een openbare commit belandt. De eerste en belangrijkste stap is niet het bestand uit de geschiedenis schoonmaken — het is de sleutel onmiddellijk intrekken en een nieuwe genereren. Een gelekt geheim kan voortleven in clones en caches die anderen hebben gekopieerd, zelfs nadat je het uit de geschiedenis hebt verwijderd; de enige veilige aanname is dat het nu als ongeldig moet worden beschouwd.

Zodra je de sleutel hebt geroteerd, kun je de geschiedenis opschonen met git filter-repo (de moderne tool die Git aanraadt) of de BFG Repo-Cleaner. Daarna is een force-push nodig en moet het hele team de repository opnieuw klonen. Om zulke ongelukken in de toekomst te voorkomen, kun je tools als git-secrets of gitleaks als pre-commit hook toevoegen; die vangen geheimpatronen op het moment van committen en waarschuwen je.

Veelgestelde vragen

Moet ik mijn .env-bestand versleutelen?

Voor lokale ontwikkeling is dat meestal niet nodig; bestandsrechten en .gitignore volstaan. Maar als je geheimen in de repo moet delen, kun je met Laravels ingebouwde commando php artisan env:encrypt, of met tools als git-crypt en sops, een versleutelde .env opslaan. De ontsleutelsleutel moet nog steeds ergens veilig staan.

Wat is het verschil tussen .env en echte omgevingsvariabelen?

Het .env-bestand is een gemak: het bootst de omgevingsvariabelen van het besturingssysteem na vanuit een bestand. In productie definiëren veel platforms de variabelen liever direct op systeemniveau (serverpaneel, containeromgeving, secrets-dienst); in dat geval heb je helemaal geen .env-bestand nodig, wat het lekrisico nog verder verlaagt.

Kan ik aparte bestanden bijhouden voor meerdere omgevingen?

Ja, het is een gangbaar patroon: .env.local, .env.staging, .env.production, enzovoort. Het framework of een tool (zoals Vite, Next.js of Laravel) kiest op basis van de omgeving welke geladen wordt. Vergeet alleen niet alle varianten met echte waarden aan je .gitignore toe te voegen.

Zijn je geheimen veilig? Heb je hulp nodig bij configuratiebeheer, deployment of de veilige opzet van een project, neem dan contact met me op — samen leggen we een stevig fundament.