Hopp til innhold
StackPatrol
Metodikk4 min lesetid

Hvorfor StackPatrol ikke viser Stripe, Resend eller andre backend-tjenester

Hvis du skanner ditt eget nettsted og ser at åpenbare verktøy som Stripe, Resend, SendGrid eller Postmark mangler i rapporten, er det forventet oppførsel. Her er hvorfor, og hva du kan gjøre med det.

Vi får dette spørsmålet ofte. Noen skanner sitt eget nettsted, ser en rapport med Google Fonts, Cloudflare og noen analyseverktøy, og oppdager så at verktøyene de faktisk betaler for og bruker hver dag mangler. Hvor er Stripe? Hvor er Resend? Hvor er SendGrid-kontoen som sender hver eneste transaksjonelle e-post?

Kort svar: disse tjenestene kjører server-til-server, ikke i nettleseren til den besøkende. En klientside-skanner kan aldri se dem. Det er et bevisst designvalg, og det riktige valget for det StackPatrol er bygget for å måle.

Hvordan StackPatrol faktisk skanner

Når du sender inn en URL, åpner StackPatrol siden i en ekte Chromium-nettleser. Verktøyet venter til siden er fullastet og registrerer deretter hver eneste HTTP-forespørsel nettleseren gjør: script, fonter, stilark, fetch-kall, bilder, iframes, webfonter, beacon-kall, alt. Hver forespørsel går til et domene. Disse domenene matches mot leverandørdatabasen vår på rundt 570 tjenester, klassifisert etter eierregion.

Dette er samme teknikk som nettlesere, annonseblokkere og de fleste personvernskannere bruker. Den er presis og etterprøvbar: Hvis en tredjepart ser IP-adressen til den besøkende under et vanlig sidebesøk, oppdager StackPatrol det.

Hvorfor server-side-tjenester er usynlige

Verktøy som Resend, Postmark, SendGrid, Mailgun, OpenAI eller en intern database kalles fra serveren din, ikke fra nettleseren. Flyten ser slik ut:

  1. En besøkende sender inn et kontaktskjema på nettstedet ditt.
  2. Nettleseren sender skjemadata til backend-en din (for eksempel POST /api/contact).
  3. Serveren din, som kjører i ditt datasenter, gjør et HTTP-kall til Resend sitt API for å sende e-posten.
  4. Resend sender e-posten og returnerer et svar til serveren din.
  5. Serveren din returnerer en suksessmelding til den besøkende.

Fra nettleseren til den besøkende ble bare én forespørsel gjort: til ditt eget domene. Det finnes ingen nettverkstilkobling mellom den besøkende og Resend. Ingen script fra Resend kjøres i nettleseren. Det er teknisk umulig for en klientside-skanner, StackPatrol, Wappalyzer, BuiltWith, EU sitt eget Webbkoll, å oppdage Resend i dette scenariet.

Det samme gjelder de fleste moderne backender: databasen din, køsystemet ditt, leverandøren av transaksjonell e-post, AI-leverandøren din, søkeindeksen din. Ingen av disse vises i en nettverksrevisjon fordi de aldri var på nettverket den besøkende brukte.

Hvorfor Stripe vanligvis heller ikke vises

Stripe er eksemplet som overrasker flest, fordi det er en betalingsbehandler og betalingsbehandlere føles som de burde være synlige. Årsaken til at Stripe forblir skjult avhenger av hvordan du har integrert tjenesten.

Stripe Checkout (hostet, redirect-basert). Brukeren klikker «Kjøp» på nettstedet ditt, backend-en din kaller Stripe for å opprette en sesjon, og brukeren videresendes til checkout.stripe.com. Hele betalingsgrensesnittet ligger på Stripe sitt domene. Ingenting Stripe-relatert lastes på nettstedet ditt. Dette er den vanligste oppsettvarianten for små SaaS-produkter og den StackPatrol selv bruker.

Stripe Elements eller Payment Element. Hvis du bygger inn kortskjemaet direkte på nettstedet ditt, må du inkludere js.stripe.com/v3 på siden. I det tilfellet fanger StackPatrol opp Stripe, fordi scriptet kjører i nettleseren. Scriptet lastes også proaktivt på sider der checkout i det hele tatt er mulig, for svindeldeteksjon.

Stripe Pricing Tables eller Buy Buttons. Webkomponenten <stripe-pricing-table> laster Stripe-script og Stripe-iframes direkte inn i siden. StackPatrol ser disse.

Hvis du bruker redirect-basert Checkout og Stripe mangler i rapporten din, er det korrekt. Det er ikke en feil.

Hvorfor dette er en funksjon, ikke en begrensning

StackPatrol er bygget for å svare på ett konkret spørsmål: hva kommuniserer nettleserne til de besøkende med når de laster sidene mine? Dette spørsmålet betyr noe fordi svaret avgjør om GDPR-dataoverføringer skjer automatisk, uten samtykke, ved hvert besøk. En besøkende kan ikke gi meningsfullt samtykke til en overføring de ikke kan se.

Server-side-tjenester er en annen samtale. Når backend-en din kaller Resend, valgte du som behandlingsansvarlig hvilke felter som sendes. Du signerte en DPA med Resend. Du dokumenterte databehandleren i ROPA-en din. Den besøkende tar ikke den beslutningen i sanntid, noe som betyr at den juridiske og tekniske analysen er annerledes.

Å blande disse to i én rapport ville gjort bildet uklart. En leverandøroversikt som viser «Stripe (backend, dekket av DPA)» ved siden av «Google Fonts (lastet i nettleser, uten samtykke)» gir feil inntrykk av at begge representerer samme type risiko. Det gjør de ikke.

Hva du bør gjøre med backend-databehandlere

Server-side-databehandlere må fortsatt dokumenteres. De trenger bare en annen type dokument. Standard sjekkliste ser slik ut.

1. Vedlikehold en fortegnelse over behandlingsaktiviteter (ROPA). GDPR artikkel 30 krever dette for de fleste organisasjoner. List opp hver backend-tjeneste som håndterer personopplysninger, hvilke datakategorier den ser, hva som er behandlingsgrunnlaget og hvor databehandleren er lokalisert.

2. Ha en databehandleravtale med hver av dem. Stripe, Resend, SendGrid, Vercel, Supabase: alle tilbyr standard DPA-er. Signer dem og oppbevar kopier.

3. List databehandlerne dine offentlig. De fleste personvernerklæringer inkluderer en underdatabehandlerliste. Dette er god praksis, og blir stadig oftere en forventning i B2B-salg: enterprise-kjøpere ber om listen før signering. Hvis du ikke allerede har en slik liste, er vår egen DPA-side et fungerende eksempel på formatet.

4. Revider nettlesersiden separat. Det er dette StackPatrol er for. De to oversiktene sammen (backend-databehandlere pluss leverandører som lastes i nettleser) gir deg et helhetlig bilde.

Merknad om juridisk rådgivning

StackPatrol er en teknisk skanner. Den identifiserer leverandører og klassifiserer dem etter eierregion. Tjenesten er ikke juridisk rådgivning og sertifiserer ikke GDPR-etterlevelse. For formelle etterlevelsesvurderinger bør du kontakte et kvalifisert personvernombud eller en personvernadvokat.

Hurtigoversikt: hva som vises, og hva som ikke vises

Vises i StackPatrol: Google Fonts, Google Analytics, Google Tag Manager, Meta Pixel, LinkedIn Insight Tag, HubSpot widgets, Intercom, Zendesk chat, Typeform embeds, YouTube embeds, reCAPTCHA, Stripe.js (when embedded), Cloudflare CDN assets, Hotjar, Mixpanel, Segment, marketing pixels of any kind.

Vises ikke: Resend, SendGrid, Postmark, Mailgun, AWS SES, Stripe (when using redirect Checkout), Twilio, OpenAI, Anthropic, your database, your background job queue, your CRM API integrations, your own server-side analytics.

Hvis du trenger et verktøy som også fanger backend-siden, ser du etter noe annet: APM-verktøy som Datadog, Sentry eller New Relic viser server-til-server-kall. De er langt mer inngripende å installere (en agent i applikasjonen din) og er laget for ingeniører, ikke for personvernrevisjoner.

Kjør en skanning av nettstedet ditt

Gratis, ingen konto nødvendig. Se nøyaktig hvilke tredjepartstjenester nettleserne til de besøkende kobler seg til, klassifisert etter eierregion.

Skann nettstedet ditt gratis
Publisert 2. juni 2026 av StackPatrol. Uavhengig · Ingen tredjepartssporing · Ingen affiliatelenker.