Sikker kodning

Browserudvidelser har betydelige privilegier og arbejder tæt sammen med brugerdata og browsersessioner. Derfor er sikker kodning helt afgørende.

Dårlig sikkerhed kan føre til alvorlige sårbarheder som cross-site scripting (XSS) og datalækage, der kompromitterer brugernes privatliv og systemets integritet.

Cross-site scripting (XSS) opstår, når en angriber indsætter ondsindede scripts i en betroet webapplikation eller, i vores tilfælde, i brugerfladen til din udvidelse eller dine indholdsscripts.

Disse scripts kan stjæle følsomme data, kapre brugersessioner eller endda ændre websteders udseende – alt sammen inden for rammerne af din udvidelses tilladelser.

En af de mest almindelige årsager til XSS i webudvikling og dermed også i udvidelser er at bruge innerHTML med input, man ikke har tillid til.

Hvis du tager tekst direkte fra en bruger, f.eks. fra et formularfelt, en URL-parameter eller endda indholdet på en webside, og indsætter den i DOM'en ved hjælp af innerHTML, bliver alle indlejrede scripts kørt.

For at forhindre XSS, når du viser almindelig tekst, du ikke har tillid til, skal du altid bruge egenskaben textContent i stedet for innerHTML.

textContent behandler alt input som rå tekst, så browseren ikke fortolker eller kører HTML-tags eller scripts. Det er din første forsvarslinje.

Prøv at køre dette enkle JavaScript-eksempel. Bemærk, hvordan textContent viser scriptet sikkert som almindelig tekst, mens innerHTML på farlig vis ville forsøge at køre det.

Hvad nu, hvis du faktisk har brug for at tillade noget HTML, f.eks. fed eller kursiv tekst, fra brugerinput? I disse tilfælde er textContent ikke nok.

Du skal bruge et robust og velvedligeholdt bibliotek til HTML-rensning, f.eks. DOMPurify. Disse biblioteker fortolker HTML, fjerner ondsindede tags og attributter og returnerer sikker HTML. Byg aldrig din egen HTML-rensning.

Funktioner som eval(), new Function(), setTimeout(string) og setInterval(string) kører JavaScript-kode fra en streng.

Det udgør en betydelig sikkerhedsrisiko. Hvis en angriber kan styre strengargumentet, kan vedkommende køre vilkårlig kode i konteksten for din udvidelse og potentielt omgå andre sikkerhedsforanstaltninger.

Datalækage opstår, når følsomme brugerdata utilsigtet eller ondsindet bliver eksponeret for uautoriserede tredjeparter. Det er en kritisk bekymring for udvidelser.

Vær yderst forsigtig, når du sender data fra din udvidelse til eksterne servere. Kontrollér altid destinationen, brug sikre protokoller (HTTPS), og krypter om nødvendigt følsomme oplysninger.

Når du erklærer tilladelser i din udvidelses manifest.json, skal du altid følge princippet om mindst mulige privilegier.

Anmod kun om de absolut mindst mulige tilladelser, som udvidelsen kræver for at fungere. For bredt definerede tilladelser øger angrebsfladen og risikoen for datalækage, hvis din udvidelse kompromitteres.

Du har lært vigtige sikre kodningsmetoder til at bygge robuste browserudvidelser:

• Rens alt input: Brug textContent til almindelig tekst, og brug robuste biblioteker som DOMPurify til HTML.
• Undgå dynamisk kode: Kør aldrig kode fra strenge, du ikke har tillid til, ved hjælp af funktioner som eval().
• Mindst mulige privilegier: Anmod kun om de nødvendige tilladelser, som din udvidelse har brug for.
• Forebyg datalækage: Vær forsigtig, når du sender brugerdata, og sørg for sikre destinationer og protokoller.

Ved at integrere disse metoder bygger du mere pålidelige udvidelser, der beskytter brugernes privatliv og sikkerhed.