---
title: Slik finner dere filer som ikke skulle ligget ute
description: Hvordan .git, .env og glemte sikkerhetskopier havner på nett, hvordan dere sjekker om deres ligger der, og hva som må gjøres når svaret er ja.
updated: 2026-08-16
minutes: 20
canonical: https://glippen.no/veiledninger/eksponerte-filer
author: Erik Nilsen
---

# Slik finner dere filer som ikke skulle ligget ute

En .git-mappe på en webserver lar hvem som helst hente ned hele kildekoden, inkludert alt som noen gang har ligget i historikken. Det er ikke et teoretisk problem: det er et av de mest lønnsomme funnene som finnes, fordi historikken nesten alltid inneholder en nøkkel noen fjernet senere.

Det samme gjelder .env med databasepassord, sikkerhetskopier som ble lagt i webroten «bare midlertidig», og eksportfiler ingen husket å slette.

Alle sjekkene under er lesing av det som allerede ligger åpent. Ingen av dem gjør noe med systemet.

> Alle kommandoene under leser. Ingen av dem endrer noe.

## 1. Sjekk om .git ligger ute

Den avgjørende filen er .git/HEAD. Ligger den der, ligger som regel resten også.

```sh
curl -sI https://example.no/.git/HEAD
```

**Riktig svar.** 404 eller 403 er riktig svar. Kommer det 200, må dere gå videre til siste steg med en gang: kildekoden er offentlig, og det har den vært en stund.

## 2. Sjekk de vanlige filnavnene

De samme navnene går igjen overalt. Sjekk dem én for én og se etter 200-svar.

```sh
for f in .env .env.local config.json backup.sql dump.sql .DS_Store; do
  printf '%s: ' "$f"
  curl -s -o /dev/null -w '%{http_code}\n' "https://example.no/$f"
done
```

**Riktig svar.** 404 på alle. Alt annet enn 404 eller 403 er verdt å se nærmere på, også en 200 med en tom side.

## 3. Se hva som allerede er indeksert

Er filen funnet av en søkemotor, er den ikke lenger deres problem alene. Søk på site:example.no sammen med filtypen i en vanlig søkemotor.

Sjekk også om domenet ligger i offentlige arkiver av gamle sider. En fil som er fjernet i dag kan fortsatt være lesbar der.

## 4. Steng det igjen på riktig sted

Blokker skjulte mapper i webserveren, ikke i applikasjonen. En regel i applikasjonen omgås av alt som kommer utenom applikasjonen.

Best av alt er at filene ikke er der. En utrulling som kopierer arbeidsmappen med .git og alt er årsaken i de fleste tilfeller, og den løses i utrullingen, ikke med en regel.

## 5. Hvis noe var eksponert: bytt nøklene, ikke bare fjern filen

En fil som har ligget ute må regnes som lest. Å fjerne den stopper neste person, ikke den forrige.

Alt som lå i den byttes: databasepassord, API-nøkler, tokens, signeringsnøkler. Lå det i git-historikken, hjelper det ikke å slette filen i siste commit, for historikken er hele poenget.

Sjekk deretter loggene for bruk av de gamle nøklene, og se om noe ble brukt av noen andre enn dere.

**Pass på.** Var det personopplysninger i filen, kan dere ha en meldeplikt til Datatilsynet innen 72 timer. Fristen løper fra dere ble klar over det, ikke fra dere er ferdige med å undersøke.

## Det som faktisk går galt

- Filen fjernet, nøklene beholdt. Den vanligste feilen, og den som koster mest.
- Blokkering lagt i applikasjonen i stedet for i webserveren.
- Bare forsiden sjekket. Underdomener, testmiljøer og gamle kampanjesider er der funnene som regel ligger.
- En regel for .git, men ikke for .env, .svn eller sikkerhetskopier med tilfeldige navn.
- Ingen som sjekker på nytt etter neste utrulling. Dette kommer tilbake med mindre utrullingen endres.