Webshopplatforme: ordre-, admin- og ændringslogs

Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen

Kort svar: En webshop har spor i tre lag: ordrens egen historik, platformens log over handlinger i administrationen og den underliggende database med webserverens logs. Hvor meget hvert lag rummer, afhænger af platformen. Hostede platforme som Shopify har en indbygget, men begrænset aktivitetslog. Selvhostede løsninger som WooCommerce og Magento Open Source logger ofte kun det, ordrenoter og ekstra moduler registrerer, og resten må rekonstrueres fra databasen og serverens logs.

Sagerne handler typisk om refusioner til egne kort, rabatkoder, der deles uden for aftalen, prisændringer, slettede ordrer, ændrede leveringsadresser og medarbejdere, der beholder adgangen efter fratræden. Virksomhedens første skridt er beskrevet på Webshoppens administration: rabatkoder, refusioner og medarbejderadgange. Her gennemgås de tekniske spor platform for platform.

Ordrens historik

De fleste platforme fører en historik pr. ordre. I Shopify hedder den ordrens tidslinje og viser betalinger, refusioner, ændringer, kommentarer og hvilken bruger eller app der handlede. Tilsvarende tidslinjer findes for kunder, kladdeordrer og lageroverførsler.

I WooCommerce består historikken af ordrenoter. Systemet tilføjer selv noter ved statusskift, betalinger og lagerreduktioner, mens medarbejdere kan skrive private noter eller noter, der sendes til kunden. Noterne gemmes som kommentarer i WordPress-databasen og kan derfor også findes og eksporteres direkte derfra. En note fortæller ikke altid, hvilken bruger der udløste statusskiftet, og en betalingsudbyders automatiske opdatering ligner en manuel ændring, hvis man kun læser teksten.

Ordrehistorikken er det første sted at kigge, men den er ikke en revisionslog. Den kan vise, hvad der skete med en ordre, men ikke hvem der så eller eksporterede den.

Administratorlogs

Shopify har en aktivitetslog for butikken, der viser nylige handlinger fra ejeren, medarbejdere, apps og salgskanaler, fx sletning af produkter, ændrede indstillinger og apps, der har fået adgang. Ifølge Shopifys hjælpecenter viser den højst 250 hændelser, kan ikke eksporteres og kan ikke foldes ud. Der findes desuden en separat log over brugeradministration og en aktivitetslog for kasseapparatet i Shopify POS med annulleringer, refusioner og manuelle rabatter. Sikring sker i praksis med dokumenterede skærmbilleder, gentaget løbende, fordi ældre hændelser forsvinder, når nye kommer til.

Magento og Adobe Commerce: Adobe Commerce har en handlingslog for administratorer, hvor de handlinger, der skal logges, vælges i konfigurationen. Funktionen findes ikke i Magento Open Source, hvor kun login og sessioner registreres som standard, medmindre et udvidelsesmodul er installeret.

WooCommerce: WordPress har ingen indbygget administratorlog. Hvis butikken har et logningsplugin, findes sporet dér, og plugin’ets egne tabeller skal med i sikringen. Ellers må handlingerne rekonstrueres fra ordrenoter, databasens ændringstidspunkter og webserverens adgangslog.

Uanset platform bør konfigurationen af loggen dokumenteres: hvad der logges, siden hvornår, og hvem der kan ændre eller slette loggen.

Database og webserver

Ved selvhostede platforme er databasen den mest komplette kilde. Ordrer, refusioner, rabatkoder og brugere har tidsstempler for oprettelse og ændring, og en kopi af databasen kan sammenlignes med backups for at finde slettede eller ændrede rækker. Se Databaser som bevis om transaktionslogs og binlogs, der kan vise ændringer, som ikke står i tabellerne længere.

Webserverens adgangslog viser forespørgsler til administrationens adresser, fx kald, der gemmer en ordre eller opretter en refusion, med IP-adresse, tidspunkt og browser. Den viser ikke, hvilken bruger der var logget ind, men kan kobles til login via session og tidspunkt. Se Webserverlogs om felter, tidszoner og proxyer.

Ved hostede platforme har butikken ikke adgang til servernes logs. Platformens API kan levere ordrer, refusioner og rabatkoder med tidsstempler, og en eksport via API er normalt mere fuldstændig og bedre dokumenteret end en CSV fra administrationen.

Betalingsudbyderen

Refusioner og betalinger har et uafhængigt spor hos betalingsudbyderen: hvilken transaktion der blev refunderet, til hvilket kort eller konto, hvornår og ofte via hvilken bruger eller API-nøgle. Udbyderens rapporter er et vigtigt modstykke til webshoppens egne data, fordi de ikke kan ændres fra butikkens administration. Sammenhold refusionerne i webshoppen med udbyderens udbetalinger, og led efter refusioner, der ikke har en tilsvarende ordre, eller som går til en anden betalingskilde end købet.

Konkrete analyser af refusioner og rabatter

Når data er sikret, er de mest givende analyser ofte enkle sammenstillinger:

Refusioner pr. bruger og tidspunkt: fordel refusioner på den bruger eller app, der udførte dem, og på tidspunkt på døgnet. Refusioner uden for butikkens åbningstid eller vagtplan er værd at se nærmere på.
Refusion mod betalingskilde: led efter refusioner, hvor betalingsudbyderens data viser et andet kort eller en anden konto end den, der betalte.
Rabatkoder: hvem oprettede koden, hvor stor er rabatten, hvor mange gange er den brugt, og af hvilke kunder. En kode, der bruges af mange forskellige kunder kort efter oprettelsen, kan være delt offentligt.
Ordrer, der ændres efter betaling: ændret leveringsadresse, ændrede varelinjer eller annullering kort før afsendelse.
Prisændringer: produktpriser, der sættes ned og op igen inden for kort tid, samtidig med ordrer fra bestemte kunder.

Ingen af mønstrene er bevis i sig selv. De peger på de ordrer og hændelser, der skal undersøges enkeltvis og forklares.

Sikring trin for trin

Lås adgange, men slet dem ikke. Fjern rettigheder fra den mistænkte bruger, men bevar kontoen og dens historik. Notér tidspunktet.
Dokumentér hostede logs straks: aktivitetslog, brugeradministrationens log og POS-log, med skærmbilleder der viser adresse, tidspunkt og hele listen.
Eksportér via API ordrer, refusioner, rabatkoder, produkter og priser for perioden. Gem selve svarene, notér endepunkt, filtre og tidspunkt, og hash filerne.
Tag en kopi af databasen og filerne ved selvhostede løsninger, og sikr webserverens logs, før de roterer. Hostingleverandøren kan have ældre logs; se Hostingleverandørens logs.
Hent rapporter fra betalingsudbyderen for samme periode.
Sikr loginhistorik og tofaktorindstillinger for de relevante brugere.

Se også Kompromitteret WordPress, hvis der er mistanke om, at en udefrakommende har haft adgang.

Typiske fejlkilder

Delte konti: en fælles administratorkonto gør det umuligt at skelne mellem medarbejdere ud fra platformens log alene.
Apps og integrationer: ændringer fra lagerstyring, regnskab eller fragtapps står under appens navn eller en teknisk bruger.
Tidszoner: platformen viser butikkens tidszone, API’et ofte UTC, og betalingsudbyderen kan bruge en tredje.
Begrænset historik: 250 hændelser kan dække få dage i en travl butik. Fravær af en hændelse viser ikke, at den ikke fandt sted.
Testordrer og annullerede betalinger kan ligne refusioner i en rå eksport.

Hvad sporene kan og ikke kan bevise

Sporene kan vise, at en bestemt brugerkonto eller app udførte en bestemt handling på et tidspunkt, og hvor pengene gik hen. De kan ikke alene vise, hvem der brugte kontoen. Det kræver kobling til login, IP-adresser, enheder og arbejdsplaner. Rapporten bør skelne tydeligt mellem det, platformen registrerede, og det, der er rekonstrueret fra databasen og serverlogs.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: HR- og lønsystemer: adgangslogs og ændringshistorik · Kassesystemer og POS: journal, ændringer og eksport

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik