Este documento é uma visão geral sobre as funcionalidades de segurança do Django. Ele inclui dicas de segurança para sites desenvolvidos em Django.
\n\nThe golden rule of web application security is to never trust user-controlled\ndata. Hence, all user input should be sanitized before being used in your\napplication. See the forms documentation for\ndetails on validating user inputs in Django.
\nIn a cross-site scripting attack, malicious code in the form of a client-side\nscript is injected into another user’s web browser, where it will be executed.
\nThis is typically done by:
\nstoring the malicious script in the database where it will be retrieved and\npresented to other users in their browsers, or
getting users to click a link which will cause the attacker’s JavaScript to\nbe executed by the user’s browser.
Cross-site scripting attacks can originate from any untrusted source of data,\nincluding cookies or web services, if the data are not adequately sanitized\nbefore being published in a page.
\nDjango templates provide protection against the majority of cross-site\nscripting attacks by automatically escaping characters that represent a\nrisk (that is, HTML characters that could be\ninterpreted by the browser to malicious effect are instead safely\ndisplayed).
\nHowever, the extent of this protection and its limitations should be\nunderstood.
\nAmbiguity between the developer’s intention and how the browser interprets\nHTML can expose the client to unintended code execution. Suppose that a\ndeveloper creates:
\n<style class={{ var }}>...</style>\nwhere var is expected to contain something like 'class1'. If var\nwere set to 'class1 onmouseover=javascript:func()' though, this could\nresult in unauthorized JavaScript execution due to differences in how browsers\nwill interpret this imperfect HTML.
Explicit template design, in which the quotes are not left to the variable to\nprovide:
\n<style class="{{ var }}">...</style>\nwould eliminate this possibility.
\nIt is also important to be particularly careful when using the is_safe\nattribute with custom template tags, the safe template tag,\nmark_safe, and when autoescape is turned off.
Django’s built-in escaping is intended to protect HTML output. If you are using\nthe template system to output something other than HTML, the characters and\nstrings that require escaping might be entirely different.
\nAdditionally, be very careful when storing HTML in the database, especially\nwhen that HTML is retrieved and displayed. Unless the HTML is guaranteed to\ncome from a trusted source - user input is not a trusted source - stored HTML\nshould be checked and sanitized, preferably on input as well as output.
\nAtaques de solicitações forjadas entre sites, na sigla em inglês, CSRF, permitem que um usuário malicioso execute ações usando as credenciais de outro usuário sem o seu consentimento ou conhecimento.
\nO Django já possui proteção embutida contra a maioria dos tipos de ataques CSRF, contanto que você a tenha habilitado e usado onde apropriado. Porém, assim como em qualquer outra técnica de mitigação, existem limitações. Por exemplo, é possível desabilitar o módulo CSRF globalmente ou para views em particular. Você só deve fazer isso se você souber o que você está fazendo. Existem outras limitações se o seu site tiver subdomínios que estão fora do seu controle.
\nCSRF protection works by checking for a secret in each\nPOST request. This ensures that a malicious user cannot “replay” a form POST to\nyour website and have another logged-in user unwittingly submit that form. The\nmalicious user would have to know the secret, which is user specific (using a\ncookie).
\nQuando implantado com HTTPS, CsrfViewMiddleware irá verificar se o referido cabeçalho HTTP está configurado para uma URL na mesma origem (incluindo subdomínio e porta). Como o HTTPS fornece segurança adicional, é imperativo garantir que as conexões utilizem HTTPS quando disponível redirecionando requisições de conexões inseguras e usando HSTS nos browsers suportados.
Tenha cuidado ao marcar views com o decorator csrf_exempt a não ser que isso seja absolutamente necessário.
SQL injection é um tipo de ataque onde o usuário malicioso consegue executar código SQL arbitrário em um banco de dados. Isso pode resultar em registros sendo deletados ou vazamento de dados.
\nDjango’s querysets are protected from SQL injection since their queries are\nconstructed using query parameterization. A query’s SQL code is defined\nseparately from the query’s parameters. Since parameters may be user-provided\nand therefore unsafe, they are escaped by the underlying database driver.
\nDjango also gives developers power to write raw queries or execute custom sql.\nThese capabilities should be used sparingly and you should always be careful to\nproperly escape any parameters that the user can control. In addition, you\nshould exercise caution when using\nextra() and\nRawSQL.
Clickjacking, ou roubo de click, é um tipo de ataque onde um site malicioso embrulha outro site dentro de um frame. Esse ataque pode resultar em um usuário desavisado sendo levado a fazer ações não intencionadas no site alvo.
\nO Django possui proteção contra clickjacking no form do middleware X-Frame-Options middleware que em um browser com suporte pode prevenir um site de ser renderizado dentro de um frame. É possível desabilitar a proteção por view ou configurar o valor exato a ser enviado no cabeçalho.
O middleware é fortemente recomendado para qualquer site que não precise ter suas páginas envolvidas em um frame por sites de terceiros, ou que só precise permitir isso para uma pequena seção do site.
\nÉ sempre melhor para segurança implantar o seu site usando HTTPS. Sem isso, é possível para redes de usuários mal intencionados farejar credenciais de autenticação ou qualquer outra informação transferida entre o cliente e o servidor, e em alguns casos – invasores ativos na rede – alterarem dados que foram enviados em qualquer direção.
\nSe você quiser a proteção que o HTTPS provê, e o habilitou no seu servidor, existem mais alguns passos adicionais que você pode precisar:
\nSe necessário, ativar SECURE_PROXY_SSL_HEADER, certificando-se que você entendeu completamente os avisos mencionados lá. Falhar ao fazer isso pode resultar em vulnerabilidades de CSRF, e falhar em fazer isso corretamente podem ainda ser perigoso!
Ativar SECURE_SSL_REDIRECT configurando para True, de modo que as requisições via HTTP sejam redirecionadas para HTTPS.
Please note the caveats under SECURE_PROXY_SSL_HEADER. For the\ncase of a reverse proxy, it may be easier or more secure to configure the\nmain web server to do the redirect to HTTPS.
Utilize cookies ‘seguros’.
\nSe um browser conecta inicialmente via HTTP, o que é o padrão na maioria dos browsers, é possível que cookies existentes sejam vazados. Por essa razão, você deve ativar os settings SESSION_COOKIE_SECURE e CSRF_COOKIE_SECURE para True. Isso instrui o browser a só enviar os cookies em conexões sobre HTTPS. Repare que isso significa que as sessões não irão funcionar sobre HTTP (o que não é um problema se você está redirecionando todo o seu tráfego HTTP para HTTPS).
Utilize HTTP Strict Transport Security (HSTS)
\nHSTS is an HTTP header that informs a browser that all future connections to\na particular site should always use HTTPS. Combined with redirecting requests\nover HTTP to HTTPS, this will ensure that connections always enjoy the added\nsecurity of SSL provided one successful connection has occurred. HSTS may\neither be configured with SECURE_HSTS_SECONDS,\nSECURE_HSTS_INCLUDE_SUBDOMAINS, and\nSECURE_HSTS_PRELOAD, or on the web server.
Django uses the Host header provided by the client to construct URLs in\ncertain cases. While these values are sanitized to prevent cross-site scripting\nattacks, a fake Host value can be used for cross-site request forgery,\ncache poisoning attacks, and poisoning links in emails.
Because even seemingly-secure web server configurations are susceptible to fake\nHost headers, Django validates Host headers against the\nALLOWED_HOSTS setting in the\ndjango.http.HttpRequest.get_host() method.
This validation only applies via get_host();\nif your code accesses the Host header directly from request.META you\nare bypassing this security protection.
Para mais detalhes veja a documentação completa do setting ALLOWED_HOSTS.
Adicionalmente, o Django requer que você ative explicitamente o suporte para o cabeçalho X-Forwarded-Host (através do setting USE_X_FORWARDED_HOST) se a sua configuração exigir ele.
Browsers use the Referer header as a way to send information to a site\nabout how users got there. By setting a Referrer Policy you can help to\nprotect the privacy of your users, restricting under which circumstances the\nReferer header is set. See the referrer policy section of the\nsecurity middleware reference for details.
The cross-origin opener policy (COOP) header allows browsers to isolate a\ntop-level window from other documents by putting them in a different context\ngroup so that they cannot directly interact with the top-level window. If a\ndocument protected by COOP opens a cross-origin popup window, the popup’s\nwindow.opener property will be null. COOP protects against cross-origin\nattacks. See the cross-origin opener policy section of the security\nmiddleware reference for details.
De forma similiar as :ref:` limitações CSRF <csrf-limitations>` requerendo que o deploy de um site seja feito de modo que usuários não tenham acesso a quaisquer subdomínios, o módulo django.contrib.sessions também tem limitações. Veja a seção de segurança do guia que fala sobre sessions para mais detalhes.
If your site accepts file uploads, it is strongly advised that you limit\nthese uploads in your web server configuration to a reasonable\nsize in order to prevent denial of service (DOS) attacks. In Apache, this\ncan be easily set using the LimitRequestBody directive. You should not rely\nsolely on DATA_UPLOAD_MAX_MEMORY_SIZE\nnor FILE_UPLOAD_MAX_MEMORY_SIZE.
Se você estiver fornecendo os seus próprios arquivos estáticos, certifique-se de que handlers como o mod_php, que são capazes de executar arquivos estáticos como código, estejam desabilitados. Você não quer que usuários sejam capazes de executar código arbitrário através do upload e solicitação de um arquivo especialmente criado.
A manipulação de envio de mídia no Django expõe algumas vulnerabilidades quando esta mídia é servida de maneiras que não seguem as melhores práticas de segurança. Especificamente, um arquivo HTML pode ser enviado como imagem se o arquivo contiver um cabeçalho PNG válido seguido por um HTML malicioso. Este arquivo irá passar a validação da biblioteca ImageField que o Django usa para processar imagem (Pillow). Quando este arquivo é subsequentemente mostrado para um usuário, ele pode ser mostrado como HTML dependendo do tipo de configuração do seu servidor web.
Não existe solução à prova de balas a nível de framework para validar com segurança todos os uploads de arquivos de usuários, entretanto, existem mais alguns passos que você pode dar para mitigar esses ataques:
\nUma classe de ataques pode ser prevenida servindo sempre conteúdo proveniente de uploads de um domínio de primeiro nível ou de um domínio de segundo nível. Isso previne qualquer vulnerabilidade bloqueada por proteções do tipo same-origin policy tais como CSS. Por exemplo, se o seu site está hospedado em example.com, você vai querer fornecer conteúdo proveniente de uploads (o setting MEDIA_URL) de algo como usercontent-example.com. Não basta apenas fornecer conteúdo de um subdomínio como usercontent.example.com.
Beyond this, applications may choose to define a list of allowable\nfile extensions for user uploaded files and configure the web server\nto only serve such files.
Form submissions containing files are not limited by\nDATA_UPLOAD_MAX_MEMORY_SIZE. Under ASGI, the entire request may be\nspooled to disk before any file size validation is performed. It is strongly\nadvised that you limit the maximum request body size in your web server\nconfiguration to prevent denial of service (DOS) attacks.
Content Security Policy (CSP) is a browser security mechanism that helps\nprotect web applications against attacks such as cross-site scripting (XSS) and\nother content injection attacks.
\nCSP allows web applications to define which sources of content are trusted,\ninstructing the browser to load, execute, or render resources only from those\nsources. This effectively creates an allowlist of content origins, reducing the\nrisk of malicious code execution.
\nKey benefits of enabling CSP include:
\nMitigating XSS attacks by blocking inline scripts and restricting external\nscript loading.
Controlling which external resources (e.g., images, fonts, stylesheets) can\nbe loaded.
Preventing unwanted framing of your site to protect against clickjacking.
Reporting violations to a specified endpoint, enabling monitoring and\ndebugging.
For configuration instructions, see the Using CSP\ndocumentation, and refer to the CSP overview for details\non directives and settings.
\nWhile CSP is a powerful security mechanism, it’s important to understand its\nlimitations and implications, particularly when used in Django:
\nPolicy exclusion risks: Avoid excluding specific paths or responses from\nCSP protection. Due to the browser’s same-origin policy, a vulnerability on\nan unprotected page (e.g., one allowing arbitrary script injection) may be\nleveraged to attack protected pages. Excluding any route can significantly\nweaken the site’s overall CSP protection.
Performance overhead: Although typically negligible, CSP adds some processing\noverhead. Nonce generation involves secure randomness for each applicable\nrequest. For high-traffic applications or resource-constrained environments,\nmeasure the performance impact accordingly.
Browser support: While CSP Levels 1 and 2 are widely supported, newer\ndirectives (CSP Level 3+) or complex policy behaviors may vary across\nbrowsers. Test your policy across the environments you intend to support.
Despite these limitations, CSP remains an important and recommended security\nlayer for web applications. Understanding its constraints will help you design\na more effective and reliable deployment.
\nWhile Django provides good security protection out of the box, it is still\nimportant to properly deploy your application and take advantage of the\nsecurity protection of the web server, operating system and other components.
\nMake sure that your Python code is outside of the web server’s root. This\nwill ensure that your Python code is not accidentally served as plain text\n(or accidentally executed).
Tome cuidado com qualquer arquivo originado de uploads de usuários.
Django does not throttle requests to authenticate users. To protect against\nbrute-force attacks against the authentication system, you may consider\ndeploying a Django plugin or web server module to throttle these requests.
Keep your SECRET_KEY, and SECRET_KEY_FALLBACKS if in\nuse, secret.
É uma boa idéia limitar a acessibilidade de seu sistema de cache e banco de dados, utilizando um firewall.
Dê uma olhada no `Top 10 `_ do “Projeto Aberto de Segurança de Aplicações Web”, em inglês Open Web Application Security Project (OWASP), que identifica algumas vulnerabilidades comuns em aplicações web. Embora o Django tenha ferramentas para solucionar alguns desses problemas, outros problemas devem ser resolvidos no design do seu projeto.
Mozilla discusses various topics regarding web security. Their\npages also include security principles that apply to any system.