# Django 5.2.8 documentation

# Säkerhet i Django

Detta dokument är en översikt över Djangos säkerhetsfunktioner. Det innehåller råd om hur du säkrar en Djangodriven webbplats.

## Rengör alltid användarens inmatning

Den gyllene regeln för säkerhet i webbapplikationer är att aldrig lita på användarkontrollerade data. Därför bör alla användarinmatningar rensas innan de används i din applikation. Se formulardokumentation för detaljer om validering av användarinmatningar i Django.

## Skydd mot XSS (Cross Site Scripting)

XSS-attacker gör det möjligt för en användare att injicera skript på klientsidan i andra användares webbläsare. Detta görs vanligtvis genom att lagra de skadliga skripten i en databas där de kan hämtas och visas för andra användare, eller genom att få användarna att klicka på en länk som gör att angriparens JavaScript körs av användarens webbläsare. XSS-attacker kan dock komma från vilken otillförlitlig datakälla som helst, t.ex. cookies eller webbtjänster, om datan inte rensas tillräckligt innan den inkluderas i en sida.

Genom att använda Django-mallar skyddar du dig mot de flesta XSS-attacker. Det är dock viktigt att förstå vilka skydd det ger och dess begränsningar.

Django templates escape specifika tecken som är särskilt farliga för HTML. Även om detta skyddar användare från de flesta skadliga inmatningar, är det inte helt idiotsäkert. Till exempel kommer det inte att skydda följande:

    <style class={{ var }}>...</style>

Om `var` är satt till `'class1 onmouseover=javascript:func()'`, kan detta resultera i obehörig JavaScript-körning, beroende på hur webbläsaren renderar imperfekt HTML. (Att citera attributvärdet skulle lösa detta fall.)

Det är också viktigt att vara särskilt försiktig när man använder `is_safe` med anpassade malltaggar, malltaggen `safe`, `mark_safe` och när autoescape är avstängt.

Om du använder mallsystemet för att skriva ut något annat än HTML kan det dessutom finnas helt separata tecken och ord som kräver escaping.

Du bör också vara mycket försiktig när du lagrar HTML i databasen, särskilt när denna HTML hämtas och visas.

## Skydd mot CSRF (Cross Site Request Forgery)

CSRF-attacker gör det möjligt för en illasinnad användare att utföra åtgärder med hjälp av en annan användares inloggningsuppgifter utan den användarens vetskap eller samtycke.

Django har ett inbyggt skydd mot de flesta typer av CSRF-attacker, förutsatt att du har aktiverat och använt det där det är lämpligt. Men som med alla begränsningstekniker finns det begränsningar. Det är till exempel möjligt att inaktivera CSRF-modulen globalt eller för vissa vyer. Du bör bara göra detta om du vet vad du gör. Det finns andra begränsningar om din webbplats har underdomäner som ligger utanför din kontroll.

CSRF-skyddet fungerar genom att kontrollera om det finns en hemlig kod i varje POST-begäran. Detta säkerställer att en illvillig användare inte kan ”spela upp” en POST-begäran till din webbplats och få en annan inloggad användare att omedvetet skicka in formuläret. Den illvilliga användaren måste känna till den hemliga koden, som är användarspecifik (med hjälp av en cookie).

Vid distribution med HTTPS kommer `CsrfViewMiddleware` att kontrollera att HTTP-referer-headern är inställd på en URL med samma ursprung (inklusive underdomän och port). Eftersom HTTPS ger ytterligare säkerhet är det absolut nödvändigt att se till att anslutningar använder HTTPS där det är tillgängligt genom att vidarebefordra osäkra anslutningsförfrågningar och använda HSTS för webbläsare som stöds.

Var mycket försiktig med att markera vyer med dekoratorn `csrf_exempt` om det inte är absolut nödvändigt.

## Skydd mot SQL-injektion

SQL-injektion är en typ av attack där en illasinnad användare kan köra godtycklig SQL-kod i en databas. Detta kan resultera i att poster raderas eller att data läcker ut.

Djangos querysets är skyddade från SQL-injektion eftersom deras frågor är konstruerade med hjälp av query parameterization. En frågas SQL-kod definieras separat från frågans parametrar. Eftersom parametrar kan vara användartillhandahållna och därför osäkra, escapas de av den underliggande databasdrivrutinen.

Django ger också utvecklare möjlighet att skriva raw queries eller exekvera custom sql. Dessa funktioner bör användas sparsamt och du bör alltid vara noga med att korrekt escape alla parametrar som användaren kan kontrollera. Dessutom bör du vara försiktig när du använder `extra()` och `RawSQL`.

## Skydd mot klickjacking

Clickjacking är en typ av attack där en skadlig webbplats kapslar in en annan webbplats i en ram. Denna attack kan leda till att en intet ont anande användare luras att utföra oavsiktliga åtgärder på målwebbplatsen.

Django innehåller clickjacking protection i form av `X-Frame-Options middleware` som i en webbläsare med stöd kan förhindra att en webbplats återges inuti en ram. Det är möjligt att inaktivera skyddet per vy eller att konfigurera det exakta rubrikvärdet som skickas.

Middleware rekommenderas starkt för alla webbplatser som inte behöver ha sina sidor inbakade i en ram av webbplatser från tredje part, eller som bara behöver tillåta det för en liten del av webbplatsen.

## SSL/HTTPS

Det är alltid bättre ur säkerhetssynpunkt att distribuera din webbplats bakom HTTPS. Utan detta är det möjligt för illvilliga nätverksanvändare att sniffa autentiseringsuppgifter eller annan information som överförs mellan klient och server, och i vissa fall - aktiva nätverksangripare - att ändra data som skickas i båda riktningarna.

Om du vill ha det skydd som HTTPS ger och har aktiverat det på din server, finns det några ytterligare steg som du kan behöva:

- Om det behövs, ställ in `SECURE_PROXY_SSL_HEADER`, och se till att du har förstått varningarna där noggrant. Om du inte gör detta kan det leda till CSRF-sårbarheter, och om du inte gör det på rätt sätt kan det också vara farligt!

- Sätt `SECURE_SSL_REDIRECT` till `True`, så att förfrågningar via HTTP omdirigeras till HTTPS.

  Observera förbehållen under `SECURE_PROXY_SSL_HEADER`. När det gäller en omvänd proxy kan det vara enklare eller säkrare att konfigurera huvudwebbservern för att göra omdirigeringen till HTTPS.

- Använd ”säkra” cookies.

  Om en webbläsare initialt ansluter via HTTP, vilket är standard för de flesta webbläsare, är det möjligt att befintliga cookies läcker ut. Av denna anledning bör du ställa in inställningarna `SESSION_COOKIE_SECURE` och `CSRF_COOKIE_SECURE` till `True`. Detta instruerar webbläsaren att endast skicka dessa cookies via HTTPS-anslutningar. Observera att detta innebär att sessioner inte fungerar via HTTP och att CSRF-skyddet förhindrar att POST-data accepteras via HTTP (vilket är bra om du omdirigerar all HTTP-trafik till HTTPS).

- Använd HTTP Strict Transport Security (HSTS)

  HSTS är en HTTP-header som informerar en webbläsare om att alla framtida anslutningar till en viss webbplats alltid ska använda HTTPS. I kombination med omdirigering av förfrågningar via HTTP till HTTPS säkerställer detta att anslutningar alltid har den extra säkerheten hos SSL förutsatt att en lyckad anslutning har skett. HSTS kan antingen konfigureras med `SECURE_HSTS_SECONDS`, `SECURE_HSTS_INCLUDE_SUBDOMAINS`, och `SECURE_HSTS_PRELOAD`, eller på webbservern.

## Validering av värdhuvud

Django använder `Host`-rubriken som tillhandahålls av klienten för att konstruera webbadresser i vissa fall. Även om dessa värden rensas för att förhindra Cross Site Scripting-attacker, kan ett falskt `Host`-värde användas för Cross-Site Request Forgery, cacheförgiftningsattacker och förgiftning av länkar i e-postmeddelanden.

Because even seemingly-secure web server configurations are susceptible to fake `Host` headers, Django validates `Host` headers against the `ALLOWED_HOSTS` setting in the `django.http.HttpRequest.get_host()` method.

This validation only applies via `get_host()`; if your code accesses the `Host` header directly from `request.META` you are bypassing this security protection.

För mer information se den fullständiga `ALLOWED_HOSTS`-dokumentationen.

Varning

I tidigare versioner av detta dokument rekommenderades att konfigurera webbservern så att den validerar inkommande HTTP `Host`-rubriker. Detta rekommenderas fortfarande, men i många vanliga webbservrar kanske en konfiguration som verkar validera `Host`-rubriken inte gör det i själva verket. Till exempel, även om Apache är konfigurerad så att din Django-webbplats serveras från en virtuell värd som inte är standard med inställningen `ServerName`, är det fortfarande möjligt för en HTTP-begäran att matcha denna virtuella värd och leverera en falsk `Host`-rubrik. Därför kräver Django nu att du ställer in `ALLOWED_HOSTS` uttryckligen snarare än att förlita dig på webbserverns konfiguration.

Dessutom kräver Django att du uttryckligen aktiverar stöd för rubriken `X-Forwarded-Host` (via inställningen `USE_X_FORWARDED_HOST`) om din konfiguration kräver det.

## Policy för hänvisare

Webbläsare använder rubriken `Referer` som ett sätt att skicka information till en webbplats om hur användarna kom dit. Genom att ställa in en Referrer Policy kan du hjälpa till att skydda dina användares integritet genom att begränsa under vilka omständigheter rubriken `Referer` ställs in. Se the referrer policy section of the security middleware reference för mer information.

## Policy för öppning av Cross-origin

Med rubriken COOP (Cross-origin Opener Policy) kan webbläsare isolera ett toppfönster från andra dokument genom att placera dem i en annan kontextgrupp så att de inte kan interagera direkt med toppfönstret. Om ett dokument som skyddas av COOP öppnar ett popup-fönster med ursprung i andra länder, kommer popup-fönstrets egenskap `window.opener` att vara `null`. COOP skyddar mot cross-origin-attacker. Se the cross-origin opener policy section of the security middleware reference för detaljer.

## Säkerhet för sessioner

I likhet med CSRF limitations som kräver att en webbplats distribueras så att icke betrodda användare inte har tillgång till några underdomäner, har `django.contrib.sessions` också begränsningar. Se avsnittet om säkerhet i sessionens ämnesguide för mer information.

## Innehåll som laddats upp av användare

Observera

Överväg att servera statiska filer från en molntjänst eller CDN för att undvika några av dessa problem.

- Om din webbplats accepterar filuppladdningar rekommenderas det starkt att du begränsar dessa uppladdningar i din webbserverkonfiguration till en rimlig storlek för att förhindra DOS-attacker (denial of service). I Apache kan detta enkelt ställas in med hjälp av direktivet LimitRequestBody.

- Om du serverar dina egna statiska filer måste du se till att hanterare som Apaches `mod_php`, som skulle exekvera statiska filer som kod, är inaktiverade. Du vill inte att användare ska kunna exekvera godtycklig kod genom att ladda upp och begära en speciellt utformad fil.

- Djangos hantering av uppladdning av media utgör vissa sårbarheter när media serveras på sätt som inte följer bästa praxis för säkerhet. Specifikt kan en HTML-fil laddas upp som en bild om filen innehåller en giltig PNG-header följt av skadlig HTML. Den här filen kommer att klara verifiering av det bibliotek som Django använder för `ImageField` bildbehandling (Pillow). När den här filen sedan visas för en användare kan den visas som HTML beroende på typ och konfiguration av din webbserver.

  Det finns ingen skottsäker teknisk lösning på ramverksnivå för att på ett säkert sätt validera allt filinnehåll som laddas upp av användaren, men det finns några andra åtgärder du kan vidta för att mildra dessa attacker:

  1. En klass av attacker kan förhindras genom att alltid servera innehåll som laddats upp av användaren från en separat toppdomän eller andra nivådomän. Detta förhindrar alla typer av attacker som blockeras av ”samma-ursprungs-policy”-skydd, t.ex. cross site scripting. Om din webbplats till exempel körs på `example.com`, skulle du vilja servera uppladdat innehåll (inställningen `MEDIA_URL`) från något i stil med `usercontent-example.com`. Det är inte tillräckligt att servera innehåll från en underdomän som `usercontent.example.com`.

  2. Utöver detta kan applikationer välja att definiera en lista över tillåtna filändelser för filer som laddas upp av användaren och konfigurera webbservern så att den endast hanterar sådana filer.

## Content Security Policy

New in Django 6.0.

Content Security Policy (CSP) is a browser security mechanism that helps protect web applications against attacks such as cross-site scripting (XSS) and other content injection attacks.

CSP allows web applications to define which sources of content are trusted, instructing the browser to load, execute, or render resources only from those sources. This effectively creates an allowlist of content origins, reducing the risk of malicious code execution.

Key benefits of enabling CSP include:

1. Mitigating XSS attacks by blocking inline scripts and restricting external script loading.

2. Controlling which external resources (e.g., images, fonts, stylesheets) can be loaded.

3. Preventing unwanted framing of your site to protect against clickjacking.

4. Reporting violations to a specified endpoint, enabling monitoring and debugging.

For configuration instructions, see the Using CSP documentation, and refer to the CSP overview for details on directives and settings.

### Limitations and considerations

While CSP is a powerful security mechanism, it’s important to understand its limitations and implications, particularly when used in Django:

- Policy exclusion risks: Avoid excluding specific paths or responses from CSP protection. Due to the browser’s same-origin policy, a vulnerability on an unprotected page (e.g., one allowing arbitrary script injection) may be leveraged to attack protected pages. Excluding any route can significantly weaken the site’s overall CSP protection.

- Performance overhead: Although typically negligible, CSP adds some processing overhead. Nonce generation involves secure randomness for each applicable request. For high-traffic applications or resource-constrained environments, measure the performance impact accordingly.

- Browser support: While CSP Levels 1 and 2 are widely supported, newer directives (CSP Level 3+) or complex policy behaviors may vary across browsers. Test your policy across the environments you intend to support.

Despite these limitations, CSP remains an important and recommended security layer for web applications. Understanding its constraints will help you design a more effective and reliable deployment.

## Ytterligare säkerhetsämnen

Även om Django ger ett bra säkerhetsskydd direkt från start är det fortfarande viktigt att distribuera din applikation på rätt sätt och dra nytta av säkerhetsskyddet för webbservern, operativsystemet och andra komponenter.

- Se till att din Python-kod ligger utanför webbserverns rot. Detta säkerställer att din Python-kod inte av misstag visas som ren text (eller av misstag exekveras).

- Var försiktig med alla användaruppladdade filer.

- Django stryper inte förfrågningar om autentisering av användare. För att skydda mot brute-force-attacker mot autentiseringssystemet kan du överväga att distribuera ett Django-plugin eller en webbservermodul för att strypa dessa begäranden.

- Håll din `SECRET_KEY`, och `SECRET_KEY_FALLBACKS` om den används, hemlig.

- Det är en god idé att begränsa tillgängligheten till ditt cachningssystem och din databas med hjälp av en brandvägg.

- Ta en titt på Open Web Application Security Project (OWASP) Top 10-lista som identifierar några vanliga sårbarheter i webbapplikationer. Django har verktyg för att hantera vissa av dessa problem, men andra problem måste beaktas i utformningen av ditt projekt.

- Mozilla diskuterar olika ämnen som rör webbsäkerhet. Deras sidor innehåller också säkerhetsprinciper som gäller för alla system.