Komponenter, der indlejres på kundernes hjemmesider

En bookingknap, en chatboks, en betalingsformular eller en kort visning af data fra jeres produkt: når kunderne lægger en komponent fra jer ind på deres egen hjemmeside, kører jeres kode et sted, I ikke ejer. Om testen skal dække komponenten, hviler på netop det forhold. Kundens besøgende møder komponenten som en del af kundens side, og en fejl i den rammer kunden, også selv om fejlen er jeres.

Derfor spørger kunderne. De vil vide, hvad komponenten kan se på deres side, hvad den sender tilbage til jer, og om den kan blive en vej ind til deres egne besøgende. En pentest af produktet besvarer kun de spørgsmål, hvis komponenten er med i omfanget og afprøves, som den bruges på en kundes side.

Hvorfor komponenten er sin egen sag

En almindelig test af et SaaS-produkt ser på produktet, som brugerne møder det: login, funktioner, roller og API. Den indlejrede komponent lever et andet liv. Den indlæses på en side, som en anden har bygget, sammen med kode fra mange andre leverandører, og den skal udveksle oplysninger med både kundens side og jeres servere.

Det giver nogle spørgsmål, som resten af produktet ikke rejser:

Samspillet med kundens side · kan komponenten påvirke siden, den sidder på, eller kan siden påvirke komponenten på en måde, der ikke var tiltænkt?
Oplysningerne, der går frem og tilbage · hvad modtager komponenten fra den besøgende, og hvad sender den videre til jer?
Visningen · kan komponenten indlæses et sted, kunden ikke har valgt, og misbruges dér?
Leveringen · hvordan når koden frem til kundens side, og hvad ville det betyde, hvis den blev ændret undervejs?

Det sidste punkt er værd at tænke over. Hvis den kode, I leverer til komponenten, bliver ændret uden jeres viden, kører den ændrede kode på alle kunders sider på én gang. Det er en risiko for kunderne, som ikke kommer fra deres egne systemer, og som de derfor heller ikke selv kan opdage eller forebygge.

Et tænkt eksempel: et softwarehus leverer en bookingkomponent, som tandlæger, frisører og fysioterapeuter lægger ind på deres egne hjemmesider. Den besøgende indtaster navn, telefonnummer og tidspunkt i komponenten. For klinikken er komponenten en del af deres side, og det er deres patienter og kunder, der bruger den. Klinikkens spørgsmål til softwarehuset er derfor enkelt: hvad sker der med de oplysninger, og kan komponenten bruges til noget, vi ikke har bedt om?

Hvad testen afprøver

OWASP’s vejledning i test af webapplikationer har et særskilt afsnit om de dele af en applikation, der kører i browseren. Det er det område, en test af komponenten bevæger sig i: hvordan koden opfører sig i den besøgendes browser, og hvordan den taler med andre sider og tjenester.

For jer som leverandør betyder det, at testen skal have en realistisk opstilling. Komponenten skal indlejres på en testside, som ligner det, kunderne gør, med de indstillinger, kunderne kan vælge. Testeren afprøver så komponenten i den sammenhæng og ikke kun jeres servere bag den. → Scope for et SaaS-produkt

Det, testen ikke skal, er at afprøve kundernes rigtige hjemmesider. De er kundernes, og en test af dem kræver kundernes egen tilladelse. Er der en særlig kunde, hvis opsætning skal med, er det en aftale med den kunde. → Kundens egen opsætning testet

Det, I aftaler før testen

Før testen skal I tage stilling til nogle valg:

Hvilke komponenter · alle, der kan indlejres, eller kun dem, kunderne bruger mest.
Hvilke indstillinger · de valg, kunden kan træffe, fx om komponenten må vise data, tage imod betaling eller kræve login.
Testsiden · hvem bygger den, og hvordan ligner den en kundes side?
Leveringen · om den måde, koden leveres på, skal med som et eget punkt.

Skriv i omfanget, at komponenten er afprøvet indlejret på en testside, og hvilke indstillinger der var med. Notér også versionen af komponenten, fordi den kan udgives i sin egen takt og ikke nødvendigvis følger resten af produktet. En kunde, der har indlejret en ældre version, skal kunne se, at rapporten handler om en nyere. Så kan en kunde, der læser rapporten, se, om deres egen brug svarer til det testede. → Omfangsafsnittet

Grænsen til kundens ansvar

Kunden bestemmer, hvor komponenten sidder, og hvordan deres egen side er bygget. Har kundens side sine egne svagheder, kan det påvirke komponenten, uden at det er jeres fejl. Kunden vælger også de indstillinger, der er åbne, og kan have tilføjet egen kode omkring komponenten.

Gør grænsen tydelig i dokumentationen til kunderne: hvad komponenten gør, hvilke oplysninger den håndterer, og hvilke indstillinger der anbefales. Det er en del af jeres ansvar at gøre den sikre brug til den lette. Det, kunden selv vælger og bygger, er kundens. → Kundernes eget ansvar

Den samme grænse kan med fordel stå i jeres kontrakter og i jeres svar på spørgeskemaer, så kunden ikke tror, at jeres rapport også dækker deres hjemmeside. → Integrationer til kundernes systemer

Når testen finder noget i komponenten

Et fund i en indlejret komponent har en særlig rækkevidde: det findes på alle kundesider, hvor komponenten bruges. Det taler for at rette hurtigt og for at vurdere, om kunderne skal have besked. Tænk også over, hvordan rettelsen når ud. Indlæses komponenten altid fra jer, får alle kunder rettelsen med det samme. Har kunderne en fast kopi på deres egne sider, skal de selv opdatere, og så skal de vide det. → Testen finder noget alvorligt: skal kunderne have besked?

Det skal I lade være med

Teste produktet og regne med, at komponenten følger med · den skal afprøves, som den bruges på en kundes side.
Teste på kundernes rigtige hjemmesider · uden kundens tilladelse er det ikke jeres at teste.
Glemme leveringen af koden · en ændring dér rammer alle kunder på én gang.
Lade indstillingerne stå uden anbefaling · kunden skal kunne se, hvilken brug der er den sikre.
Love, at komponenten ikke kan påvirke kundens side · en test viser, hvad der blev fundet med de valgte indstillinger.

Hvad kan og ikke kan konkluderes

En test af komponenten på en testside viser, hvad der blev fundet med de indstillinger og den version, der var med. Den siger ikke noget om kundernes egne sider, deres egen kode eller indstillinger, der ikke blev afprøvet.

Tjekliste til de indlejrede komponenter

☐ Er alle komponenter, kunderne kan indlejre, på en liste?
☐ Står komponenterne i omfanget med de indstillinger, der skal afprøves?
☐ Er der en testside, der ligner kundernes brug?
☐ Er leveringen af koden vurderet?
☐ Har kunderne en anbefaling om sikker brug og indstillinger?
☐ Ved I, hvordan en rettelse når ud til alle kundesider?

Kilder

OWASP Web Security Testing Guide: Client-side Testing: afsnittet om test af de dele af en webapplikation, der kører i browseren, herunder samspil med andre sider og tjenester.

Senest gennemgået: oktober 2026.