Det har nog inte undgått någon att APIer är viktiga. Det går inte ha ett system idag som inte har vettiga APIer för att underlätta integrationer, färdigbygga connectorer eller bara helt enkelt möjliggöra riktigt snabb och bra frontend - en grym sajt helt enkelt. Baksidan med att ha API:er som skickar ut datan till frontend är att man ibland inte riktigt säkerställer att man bara skickar ut det som behövs för stunden. Ibland kommer det med en hel del annat som man kanske inte vill ska publiceras för hela världen. Framför allt när man har ett generellt API som för en SaaS-produkt som ska täcka så många behov som möjligt.

När vi på Commerce Mind tittar oss omkring i branschen inser vi att många inte har insett att med möjligheter kommer också ansvaret att fundera på hur man hanterar sin datamodell. Det är snarare säga att det är närmast branschstandard att läcka känslig data som t.ex. exakta lagersaldon eller inköpspriser.

Genom att undersöka ett större antal e-handlares siter har vi hittat företag som ovetandes och publikt skickar ut exakt lagersaldo för varje produkt i varje kanal (centrallager som butik), inköpspriset för vad de köper in varorna för och när nya varor levereras. Något de flesta absolut inte vill ska finnas fritt tillgängligt för alla i hela världen.

Det som händer är alltså att koden i e-handelssitens backend bygger ihop data som kan behövas av frontend, alltså den del som visar det du ser på sajten. T.ex. så behöver frontend veta om man ska visa att varan finns i lager eller inte för att visa en grön flagga och om köp knappen ska gå klicka på och då skicka ut kod som säger "Finns i lager" men även "8118 st". Eftersom det är jobbigt att ha en rad olika datamodeller för olika scenarion så gör man en modell som man sen återanvänder överallt. Och plötsligt så skickar man ut mer data man hade tänkt.

Vilken data läcker du?

I praktiken kan alltså vem som helst med en vanlig browser öppna din hemsida och fånga datamodellen som skickas ut. Och om du i stället för "Finns i lager = true" skickar ut "Finns i lager = 8118" så kan man se det. När allt du egentligen vill är att frontend ska rita ut en grön plupp med att varan finns i lager, så har du nu dessutom berättat ditt exakta antal. Med lite enkel kodning kan man sen ladda ner ditt kompletta lagersaldo för alla produkter för att ha koll på sina konkurrenter. Det är klart att om du vill förmedla exakt lagersaldo är det här inget problem, men det här är ett enkelt exempel.

Värre exempel är dem som råkar publicera ut sina inköpspriser eller marginaler per produkt. Vi på Commerce Mind har inför den här artikeln undersökt en rad siter och kontaktat de e-handlare där vi hittat inköpspriser så det har kunnat rättas och tas bort. Men det finns med 100% säkerhet en mängd siter kvar som vi inte tittat på där det fortfarande finns. Har du exakt lagersaldo och inköpspris på dina konkurrenter kan du ju anpassa din prissättning och kampanjstrategi därefter, något vi vet redan görs.

Men det finns ännu farligare exempel, vi har hittat sajter där man till exempel har publicerat ID och lösenord till sina betalningsleverantörer. Vilket skulle kunna användas till att göra köp och returer utan att det märks om man inte är riktigt uppmärksam. Vi har givetvis redan kontaktat alla e-handlare där även detta hittats och säkerställt att det är bortplockat. Men återigen, det finns väldigt många sajter därute så det finns säkert de som fortfarande har det problemet.

Vår rekommendation är att du som e-handlare eller teknikpartner till e-handlare omgående tar en titt på vilken data du skickar till frontend och fundera på om det verkligen behövs eller om det behöver säkras upp på något sätt. Det går fort och lätt att göra fel tyvärr.

Vill du ha stöd eller veta mer om hur man kan hitta dataläckor så är du välkommen att kontakta oss på Commerce Mind så hjälper vi er givetvis.