Sandkassen i HTML-sider i SharePoint

En HTML-side i SharePoint vises i en iframe med sandbox="allow-scripts" under en Content Security Policy, der fejler uden at sige det. En side, der bryder reglerne, bliver blank eller halv (Microsoft).

Reglerne står på _html#

Hver tenant har en vejledning på https://<tenant>.sharepoint.com/_html. Den er skrevet til AI-assistenter og opdateres med tenanten (Microsoft). Den kan læses uden login, og den linker til en llms.txt og en help.json på Microsofts offentlige CDN (Microsoft). De er genereret fra SharePoints egen kildekode og er ifølge Microsoft “the authoritative, current contract” (Microsoft). Mappenavnet på CDN’en skifter med hver version, så det er _html, man skal pege på.

Politikken#

default-src 'none'; script-src 'unsafe-inline' 'unsafe-eval'; style-src 'unsafe-inline';
img-src data: blob:; font-src data: blob:; media-src data: blob:; connect-src 'none';
worker-src 'none'; object-src 'none'; base-uri 'none'; form-action 'none';

Hertil kommer frame-src 'none' fra den ydre iframe (Microsoft). På Site Pages slipper billeder fra tenanten igennem, fordi SharePoint skriver deres adresser om (n8d.at).

Det, der ikke virker#

Fra Microsofts regler (Microsoft):

• Script, stylesheets og fonte udefra. Alt skal stå i filen, bortset fra Microsofts biblioteker.
• Netværkskald: fetch, XMLHttpRequest, WebSocket, sendBeacon, EventSource. Data kommer kun via live data.
• Lagring: localStorage, sessionStorage, indexedDB og cookies. Tilstand kan gemmes i location.hash, men history.pushState og replaceState kaster en fejl.
• Navigation af hele vinduet, popups, formularafsendelse, workers og plugins. alert, confirm og prompt gør ingenting.

Denis Molodtsov testede resten: navigator.clipboard, download af filer, window.print, fuld skærm, placering og notifikationer er blokeret (spdenis.com).

Det, der virker#

Animation, canvas og WebGL, eval og WebAssembly, filer som brugeren selv vælger, oplæsning med speechSynthesis, en kopiknap med document.execCommand('copy') og brugerens mørke tilstand, sprog og tidszone (spdenis.com). Inline onclick virker, fordi SharePoint skriver det om, men data bør sættes ind med addEventListener og textContent (Microsoft).

Siden ved ikke, hvem du er#

Iframen har ingen sammenhæng med siden omkring den. Den kender ikke brugeren, sitet eller biblioteket (spdenis.com). Den kan kun sende en kort, fast liste af beskeder til SharePoint, fx om at hente data igen eller om et klik på et link (spdenis.com, n8d.at).

Adressen og links mellem sider#

Siden kan ikke læse en almindelig parameter som ?id=123 i adressen. Sidens eget dokument har en blob:-adresse, som SharePoint har lavet, og ikke den adresse, man ser i browseren (Microsoft).

Delen efter # kommer derimod frem. Microsofts vejledning anbefaler location.hash til tilstand, der skal overleve en genindlæsning, fx location.hash = "#slide=3" (Microsoft), og SharePoint og siden udveksler faste beskeder om netop den del af adressen (spdenis.com).

I min egen test virker det også på tværs af sider: et link fra én HTML-side til …/SitePages/oversigt.html#id=43 åbner den anden side, og den kan læse id=43 og vise netop den ene liste. Det gør det muligt at linke direkte til en bestemt visning, også fra en mail eller fra Teams.

Tema#

Uploadet HTML får ikke sitets tema af sig selv (Microsoft), og sider fra Copilot har fået farverne skrevet ind ved oprettelsen, så de ikke fulgte et senere temaskift (spdenis.com). Vejledningen har nu et tilvalg: <meta name="ms-sp-host-theme" content="live"> i <head> og Fluent-variabler som var(--colorBrandBackground, #0078d4) i CSS’en. Så leverer SharePoint temaet, når siden vises (Microsoft).

Søgning#

SharePoint-søgningen finder tekst, der står i HTML-filen, men ikke tekst, som script tilføjer (spdenis.com, n8d.at). En side, der kun viser live data, er derfor næsten usynlig for søgning.

Faldgruber#

• Ingen fejlbesked. Et blokeret script giver højst en linje i browserens konsol (spdenis.com). Test i SharePoint, ikke kun lokalt.
• Tegnsættet. Microsoft beder om, at filen gemmes som UTF-8 med BOM (Microsoft). Hos mig viste SharePoint alligevel en uploadet side som Windows-1252, selvom filen var UTF-8 med BOM og <meta charset="utf-8">: “é” blev til “é”, “æ” til “æ” og “×” til “×”. Tekst fra live data var ikke ramt, kun tekst i selve filen. Det sikre er at holde filen fri for andre tegn end ASCII: skriv æ for æ i script og æ i HTML-teksten. Så ser siden ens ud, uanset hvordan den læses.
• Sandkassen beskytter SharePoint, ikke læseren. Et script kan ikke stjæle noget, men en side på en ægte tenantadresse kan stadig ligne en loginside (n8d.at).