Cross-Site Script Inclusion

Cross-Site Script Inclusion (XSSI)

Cross-Site Script Inclusion (XSSI) er en sikkerhedssårbarhed, hvor et website utilsigtet tillader, at følsomme data eksponeres, når et JavaScript-ressource indlæses fra et andet domæne. Angrebet udnytter browserens tillid til <script>-tags, som ikke håndhæver same-origin policy på indholdsniveau.

Hvad er Cross-Site Script Inclusion?

XSSI opstår, når en applikation serverer data (JSON, brugerinfo, tokens) via endpoints, der kan indlæses som JavaScript, og hvor disse endpoints ikke er beskyttet korrekt. En angriber kan inkludere endpointet som et <script> fra et ondsindet domæne og udnytte browserens eksekvering af svaret.

Det er ikke klassisk XSS. Koden injiceres ikke – den inkluderes.

Hvordan opstår problemet?

XSSI er muligt, når:

• Et endpoint returnerer følsomme data i JSON

• Endpointet er tilgængeligt via GET

• Autentifikation sker via cookies

• Ingen beskyttelse mod cross-origin script loading er implementeret

Typisk flow:

1. Brugeren er logget ind på example.com

2. Brugeren besøger angriberens site

3. Angriberens side loader: <script src="https://example.com/user/data"></script>

4. Browseren sender cookies med requesten

5. JavaScript-responsen eksekveres i angriberens kontekst

Hvorfor er XSSI alvorligt?

Sikkerhed

• Eksponering af brugerdata

• Læk af tokens, konfigurationsdata eller feature flags

• Sessionrelateret information kan aflæses indirekte

Arkitektur

• Brud på forventet same-origin isolation

• Data-API’er brugt som script-ressourcer

• Manglende skelnen mellem “data” og “kode”

Typiske angrebsscenarier

• JSON endpoints uden CSRF-beskyttelse

• Legacy API’er der returnerer rå data

• Feature flag- eller config-endpoints

• Interne endpoints antaget som “ikke offentlige”

Best Practice – forebyggelse

Korrekt Content-Type

• Returnér data med: Content-Type: application/json

• Undgå text/javascript for data-endpoints

Anti-XSSI teknikker

• Prefix JSON-respons med: )]}'

som gør det ueksekverbart som JavaScript

HTTP headers

• X-Content-Type-Options: nosniff

• Stram CSP: Content-Security-Policy: script-src 'self'

Auth og API-design

• Brug tokens i headers frem for cookies til API’er

• Begræns data via POST hvor relevant

• Kræv eksplicit CORS for cross-origin adgang

Hvad beskytter ikke mod XSSI?

• Same-Origin Policy alene

• CORS-fejlkonfiguration

• At “endpointet kun er til intern brug”

• Skjulte URL’er

Forretnings- og udviklingsmæssig betydning

Databeskyttelse

XSSI kan føre til stille datalæk uden synlige fejl eller logs.

Tech Debt

Problemet findes oftest i ældre arkitektur, hvor API og frontend ikke er klart adskilt.

Skalerbarhed

Jo flere klienter og integrationer, desto større risiko uden klare data-kontrakter.

Udfordringer og løsninger

Udfordring: Ældre JSON-endpoints

Løsning: Opdater content-type og tilføj anti-XSSI prefix

Udfordring: Cookies til API-auth

Løsning: Migrér til token-baseret auth

Udfordring: Uklare CSP-regler

Løsning: Indfør strict CSP med eksplicitte script-kilder

Opsummering

Cross-Site Script Inclusion er et arkitekturproblem, ikke et input-problem.

Hvis data kan indlæses som JavaScript, vil det blive misbrugt.

Tydelig adskillelse mellem:

• kode vs. data

• browser vs. API

• cookies vs. tokens

er den langsigtede løsning.