Sikker filupload: beskyt både appen, filerne og brugerne

Kortlæg hele filens vej

Sikkerheden stopper ikke, når uploaden er gennemført. Tegn filens vej fra brugerens enhed til lager, behandling, visning, deling, backup og sletning. Notér ved hvert trin, hvilken identitet der handler, hvilke data der gemmes, og hvad en fejl kan påvirke.

1. 1. Modtag

   Kontrollér bruger, rolle, kunde, antal filer og requeststørrelse.

2. 2. Valider

   Kontrollér tilladt type, filsignatur, struktur og relevant indhold.

3. 3. Isolér

   Gem nye filer privat og eventuelt i karantæne, før de behandles.

4. 4. Behandl

   Scan, konvertér eller udtræk data med begrænset tid og hukommelse.

5. 5. Udlever

   Kontrollér adgang igen, og brug en afgrænset downloadvej.

6. 6. Slet

   Fjern fil, metadata, delingsadgange og forældreløse kopier efter planen.

Tillad kun de filer, funktionen faktisk behøver

Start med forretningsbehovet. Hvis en funktion kun skal modtage fakturaer som PDF, er “alle dokumenter” en unødvendig risiko. Brug en lille tilladt liste, og fastlæg grænser for filstørrelse, antal, samlet plads og hvor ofte en bruger eller kunde må uploade. Grænserne skal passe til den konkrete arbejdsgang og platform – ikke et tilfældigt tal kopieret fra et eksempel.

Browserens accept-attribut er hjælp til brugeren, ikke en sikkerhedsregel. Alle afgørende kontroller skal håndhæves ved backend, storage-regler eller begge dele.

Adgang skal følge filen – ikke kun siden

Login fortæller, hvem brugeren er. Appen skal stadig kontrollere, om brugeren må uploade til den konkrete sag eller kunde og senere må læse, erstatte eller slette den konkrete fil. Et svært gætteligt fil-id reducerer tilfældige fund, men erstatter ikke autorisation.

• Brug et internt fil-id: Generér lagerets objektnavn i appen. Gem det oprindelige filnavn som valideret metadata til visning.
• Bind filen til ejerskab: Gem bruger, virksomhed eller tenant, sag, status og oprettelsestid i en kontrolleret datamodel.
• Kontrollér hver handling: Upload, download, listevisning, erstatning og sletning kan kræve forskellige rettigheder.
• Lad ikke klienten vælge privilegerede felter: Backend skal udlede tenant, ejer og lagersti fra den godkendte session og den valgte sag.

Gem nye filer privat og adskil dem fra appkoden

Brugerfiler bør som udgangspunkt ligge i et privat objektlager eller uden for webserverens offentlige mappe. De må ikke kunne overskrive appkode, konfiguration eller eksisterende filer. Slå ikke anonym læseadgang til for at løse et CORS- eller downloadproblem.

I Firebase kan Cloud Storage Security Rules blandt andet kontrollere identitet, sti, filstørrelse og oplyst indholdstype. I Azure anbefaler Microsoft mindst mulige rettigheder, ingen anonym læseadgang som standard og user delegation SAS, når en klient skal have begrænset adgang. Den konkrete model afhænger af appens eksisterende stack.

Brug karantæne, når filen skal åbnes eller behandles

En fil, der skal parses, vises for andre eller sendes videre, har en større konsekvens end en fil, der blot opbevares. Gem derfor nye filer med status som eksempelvis “modtaget” eller “i kontrol”, og gør dem først tilgængelige, når de nødvendige kontroller er gennemført.

• Kør parser, konvertering og scanning i en afgrænset proces med loft over tid, hukommelse, output og samtidighed.
• Pak ikke ZIP-filer eller andre arkiver ukontrolleret ud; den udpakkede størrelse og antallet af filer kan være langt større end uploaden.
• Send ikke filen automatisk til mail, AI-tjeneste eller anden integration, før adgang, databehandling og filstatus er afklaret.
• Hvis kontrollen fejler eller stopper, skal filen blive utilgængelig – ikke automatisk godkendt.
• En ekstern scanningstjeneste kan selv blive databehandler. Kontrollér derfor aftale, placering og databehov, før persondata sendes videre.

Udlever filen gennem en kontrolleret downloadvej

Kontrollér brugerens aktuelle adgang, før en fil udleveres. Brug derefter enten en backend, der streamer filen, eller en kortlivet signeret URL med mindst mulig adgang til det konkrete objekt. En gammel URL i en mail, log eller browserhistorik må ikke fungere som permanent adgangsbillet.

• Sæt korrekt Content-Type: Brug den type, serveren har valideret – ikke ukritisk den værdi, klienten sendte.
• Vælg visning bevidst: Brug Content-Disposition: attachment, når filen skal downloades frem for at blive fortolket i browseren.
• Undgå typegæt: X-Content-Type-Options: nosniff beder browseren respektere den angivne type i stedet for at gætte.
• Begræns downloadmisbrug: Overvåg og sæt relevante grænser for store filer, gentagne hentninger og dyre konverteringer.

Planlæg sletning, backup og fejltilstande

En databasepost og selve filen kan komme ud af takt. Beslut derfor, hvad der sker ved afbrudt upload, mislykket behandling, slettet sag, udløbet opbevaringsfrist og gendannelse fra backup. Et planlagt oprydningsjob bør kun fjerne filer efter en kontrolleret regel og skrive et spor uden at logge selve indholdet.

• Registrér fil-id, ejer eller tenant, størrelse, valideret type, status, hændelse og request-id.
• Log ikke hele filer, midlertidige downloadlinks, adgangstokens eller følsomme udtræk.
• Overvåg fejlede uploads, filer fastlåst i karantæne, pladsvækst, usædvanlige downloads og oprydningsfejl.
• Afprøv at backup og gendannelse bevarer sammenhængen mellem fil, metadata og adgang – uden at gamle delingslinks genåbnes.

Typiske fejl

• Frontendens acceptliste bliver eneste kontrol: Et direkte API-kald kan stadig sende andre typer og størrelser.
• Filendelsen betragtes som sandhed: En fil omdøbes, men indholdet er stadig noget andet.
• Originalnavnet bliver lagersti: Specialtegn, stier eller dubletter kan overskrive eller placere filer forkert.
• Hele bucket'en gøres offentlig: Et downloadproblem løses ved at fjerne adgangskontrollen.
• Alle indloggede brugere kan læse alle filer: Login forveksles med adgang til den konkrete kunde og sag.
• Scanning giver falsk ro: En godkendt scanning bruges som garanti og erstatter typekontrol, isolation og rettigheder.
• Filen behandles med det samme: Parser, AI-kald eller mail starter, før kontrol og karantæne er afsluttet.
• Sletning fjerner kun databaseposten: Objekt, preview, backupkopi eller delingsadgang lever videre uden ejer.

Test upload og download uden om brugerfladen

Kald upload- og downloadvejen direkte i et isoleret miljø. Kontrollér både tilladte handlinger og dem, der skal afvises, og bevis at en afvist fil ikke bliver behandlet, vist eller liggende som en forældreløs kopi.

• Forkert rolle, anden kunde eller sag, ingen session og udløbet downloadlink.
• Dobbelt filendelse, misvisende Content-Type, tom fil og fil med uventet signatur.
• Fil lige under og over grænsen, mange samtidige uploads og afbrudt forbindelse.
• Dubletnavn, meget langt navn, stiseparatorer og tegn, som lager eller browser håndterer særligt.
• Fejlet scanning, parser-timeout, for stort udtrukket output og integration, der er nede.
• Direkte download, listevisning, erstatning og sletning med en anden brugers fil-id.

Tjekliste før rigtige filer lander i appen

• ☐ Filens vej fra upload til behandling, download, backup og sletning er kortlagt.
• ☐ Tilladte filtyper og grænser er valgt ud fra et konkret forretningsbehov.
• ☐ Backend eller storage-regler håndhæver bruger, rolle, tenant, sag, størrelse og handling.
• ☐ Lagerets objektnavn genereres af appen, og originalnavnet gemmes kun som valideret metadata.
• ☐ Filendelse, oplyst type, signatur og indhold kontrolleres i relevante lag.
• ☐ Nye filer opbevares privat og kan ikke overskrive appkode eller eksisterende objekter.
• ☐ Karantæne og fejlsikker status bruges, før risikable filer åbnes, parses eller deles.
• ☐ Scanning og behandling har grænser for tid, hukommelse, output og samtidighed.
• ☐ Download kræver aktuel adgang og bruger en afgrænset vej eller kortlivet signeret URL.
• ☐ Content-Type, Content-Disposition og nosniff er valgt bevidst ved udlevering.
• ☐ Logs viser status og sporbarhed uden filindhold, tokens eller aktive delingslinks.
• ☐ Oprydning, sletning, backup og gendannelse håndterer både objekt og metadata.
• ☐ Negative tests beviser, at en bruger ikke kan nå en anden kundes filer.

Relaterede guides

Officielle kilder

Lagerfunktioner, signaturer, scanning, headers og platformregler ændres. Kontrollér altid den aktuelle dokumentation for appens konkrete hosting, lager og filtyper, før I ændrer produktionsopsætningen.

• OWASP: File Upload Cheat Sheet
• Firebase: Security Rules til Cloud Storage
• Microsoft: Sikkerhedsanbefalinger til Azure Blob Storage
• MDN: Content-Disposition ved visning og download
• MDN: X-Content-Type-Options og nosniff