# Django 6.0.7 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.

Real-world security

Django’s web security implementations have been designed with security for real-world applications in mind. Django is a general-purpose web application framework, and its defaults reflect this - they will not be the best solution for every particular case. Special cases deserve special attention to their needs.

Web security requires a multi-layered approach. Securing only a single vector does not make a site secure overall, nor does a single apparent weakness necessarily compromise the entire site. This should be borne in mind particularly when assessing individual points in security audits.

## 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.

## Cross-site scripting (XSS) protection

In a cross-site scripting attack, malicious code in the form of a client-side script is injected into another user’s web browser, where it will be executed.

This is typically done by:

- storing the malicious script in the database where it will be retrieved and presented to other users in their browsers, or

- getting users to click a link which will cause the attacker’s JavaScript to be executed by the user’s browser.

Cross-site scripting attacks can originate from any untrusted source of data, including cookies or web services, if the data are not adequately sanitized before being published in a page.

Django templates provide protection against the majority of cross-site scripting attacks by automatically escaping characters that represent a risk (that is, HTML characters that could be interpreted by the browser to malicious effect are instead safely displayed).

However, the extent of this protection and its limitations should be understood.

Ambiguity between the developer’s intention and how the browser interprets HTML can expose the client to unintended code execution. Suppose that a developer creates:

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

where `var` is expected to contain something like `'class1'`. If `var` were set to `'class1 onmouseover=javascript:func()'` though, this could result in unauthorized JavaScript execution due to differences in how browsers will interpret this imperfect HTML.

Explicit template design, in which the quotes are not left to the variable to provide:

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

would eliminate this possibility.

It is also important to be particularly careful when using the `is_safe` attribute with custom template tags, the `safe` template tag, `mark_safe`, and when autoescape is turned off.

Django’s built-in escaping is intended to protect HTML output. If you are using the template system to output something other than HTML, the characters and strings that require escaping might be entirely different.

Additionally, be very careful when storing HTML in the database, especially when that HTML is retrieved and displayed. Unless the HTML is guaranteed to come from a trusted source - user input is not a trusted source - stored HTML should be checked and sanitized, preferably on input as well as output.

## Cross-site request forgery (CSRF) protection

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 uses the `Host` header provided by the client to construct URLs in certain cases. While these values are sanitized to prevent cross-site scripting attacks, a fake `Host` value can be used for cross-site request forgery, cache poisoning attacks, and poisoning links in emails.

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.

- If your site accepts file uploads, it is strongly advised that you limit these uploads in your web server configuration to a reasonable size in order to prevent denial of service (DOS) attacks. In Apache, this can be easily set using the LimitRequestBody directive. You should not rely solely on `DATA_UPLOAD_MAX_MEMORY_SIZE` nor `FILE_UPLOAD_MAX_MEMORY_SIZE`.

- 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.

## Form Submissions

- Form submissions containing files are not limited by `DATA_UPLOAD_MAX_MEMORY_SIZE`. Under ASGI, the entire request may be spooled to disk before any file size validation is performed. It is strongly advised that you limit the maximum request body size in your web server configuration to prevent denial of service (DOS) attacks.

## 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.