---
title: "Segurança no Django"
version: 4.1
locale: pt-br
source: https://docs.djangoproject.com/pt-br/4.1/topics/security/
canonical: https://djangodocs.dev/pt-br/4.1/topics/security/
---
# Segurança no Django

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.

## Proteção contra Cross Site Scripting (XSS)

XSS attacks allow a user to inject client side scripts into the browsers of
other users. This is usually achieved by storing the malicious scripts in the
database where it will be retrieved and displayed to other users, or by getting
users to click a link which will cause the attacker’s JavaScript to be executed
by the user’s browser. However, XSS attacks can originate from any untrusted
source of data, such as cookies or web services, whenever the data is not
sufficiently sanitized before including in a page.

Usar templates Django protege contra a maioria dos ataques XSS. Porém, é importante entender quais proteções ele fornece e quais são suas limitações.

Os templates Django possuem [escape de caracteres específicos](/pt-br/4.1/ref/templates/language/#automatic-html-escaping) que são particularmente perigosos para o HTML. Embora isso proteja os usuários da maioria das entradas de dados maliciosas, não é inteiramente a prova de tolos. Por exemplo, ele não protegerá do seguinte:

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

Se `var` é definida como `'class1 onmouseover=javascript:func()'`, isso pode resultar em uma execução não autorizada de JavaScript, dependendo de como o browser renderiza HTML imperfeito. (Adicionar aspas no valor do atributo evitaria isso.)

Também é importante ser especialmente cuidadoso ao usar `is_safe` com tags de template customizadas, com a tag de template [`safe`](/pt-br/4.1/ref/templates/builtins/#std-templatefilter-safe), [`mark_safe`](/pt-br/4.1/ref/utils/#module-django.utils.safestring), e quando o autoescape está desativado.

Além disso, se você está usando o sistema de template para gerar saídas para algo diferente de HTML, podem existir caracteres inteiramente separados e palavras que necessitaram de escaping.

Você também deve ser muito cuidadoso ao armazenar HTML em um banco de dados, especialmente quando esse HTML é recuperado e exibido.

## Proteção contra Cross site request forgery (CSRF)

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

O Django já possui proteção embutida contra a maioria dos tipos de ataques CSRF, contanto que você a tenha [habilitado e usado](/pt-br/4.1/howto/csrf/#using-csrf) 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](/pt-br/4.1/ref/csrf/#csrf-limitations) se o seu site tiver subdomínios que estão fora do seu controle.

[CSRF protection works](/pt-br/4.1/ref/csrf/#how-csrf-works) by checking for a secret in each
POST request. This ensures that a malicious user cannot “replay” a form POST to
your website and have another logged in user unwittingly submit that form. The
malicious user would have to know the secret, which is user specific (using a
cookie).

Quando implantado com [HTTPS](#security-recommendation-ssl), `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.

## Proteção contra SQL injection

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.

Django’s querysets are protected from SQL injection since their queries are
constructed using query parameterization. A query’s SQL code is defined
separately from the query’s parameters. Since parameters may be user-provided
and therefore unsafe, they are escaped by the underlying database driver.

Django also gives developers power to write [raw queries](/pt-br/4.1/topics/db/sql/#executing-raw-queries) or execute [custom sql](/pt-br/4.1/topics/db/sql/#executing-custom-sql).
These capabilities should be used sparingly and you should always be careful to
properly escape any parameters that the user can control. In addition, you
should exercise caution when using [`extra()`](/pt-br/4.1/ref/models/querysets/#django.db.models.query.QuerySet.extra)
and [`RawSQL`](/pt-br/4.1/ref/models/expressions/#django.db.models.expressions.RawSQL).

## Proteção contra Clickjacking

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.

O Django possui [proteção contra clickjacking](/pt-br/4.1/ref/clickjacking/#clickjacking-prevention) no form do middleware [`X-Frame-Options middleware`](/pt-br/4.1/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware) 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.

## SSL/HTTPS

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

Se você quiser a proteção que o HTTPS provê, e o habilitou no seu servidor, existem mais alguns passos adicionais que você pode precisar:

- Se necessário, ativar [`SECURE_PROXY_SSL_HEADER`](/pt-br/4.1/ref/settings/#std-setting-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`](/pt-br/4.1/ref/settings/#std-setting-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`](/pt-br/4.1/ref/settings/#std-setting-SECURE_PROXY_SSL_HEADER). For the
  case of a reverse proxy, it may be easier or more secure to configure the
  main web server to do the redirect to HTTPS.
- Utilize cookies ‘seguros’.

  Se 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`](/pt-br/4.1/ref/settings/#std-setting-SESSION_COOKIE_SECURE) e [`CSRF_COOKIE_SECURE`](/pt-br/4.1/ref/settings/#std-setting-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](/pt-br/4.1/ref/middleware/#http-strict-transport-security) (HSTS)

  HSTS is an HTTP header that informs a browser that all future connections
  to a particular site should always use HTTPS. Combined with redirecting
  requests over HTTP to HTTPS, this will ensure that connections always enjoy
  the added security of SSL provided one successful connection has occurred.
  HSTS may either be configured with [`SECURE_HSTS_SECONDS`](/pt-br/4.1/ref/settings/#std-setting-SECURE_HSTS_SECONDS),
  [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](/pt-br/4.1/ref/settings/#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS), and [`SECURE_HSTS_PRELOAD`](/pt-br/4.1/ref/settings/#std-setting-SECURE_HSTS_PRELOAD),
  or on the web server.

## Validação do cabeçalho Host

O Django usa o cabeçalho `Host` fornecido pelo cliente para construir URLs em alguns casos. Embora esses valores sejam tratados para prevenir ataques de Cross Site Scripting, um valor `Host` falso pode ser usado para ataques como Cross-Site Request Forgery, envenenamento de cache, e envenenamento de links em emails.

Como até mesmo configurações de web server aparentemente seguras estão sujeitas a cabeçalhos `Host` falsos, O Django valida o cabeçalho `Host` comparando com o setting [`ALLOWED_HOSTS`](/pt-br/4.1/ref/settings/#std-setting-ALLOWED_HOSTS) dentro do método [`django.http.HttpRequest.get_host()`](/pt-br/4.1/ref/request-response/#django.http.HttpRequest.get_host).

Essa validação só é aplicada através do método [`get_host()`](/pt-br/4.1/ref/request-response/#django.http.HttpRequest.get_host); se o seu código acessa o cabeçalho `Host` diretamente do `request.META` você está contornando essa proteção de segurança.

Para mais detalhes veja a documentação completa do setting [`ALLOWED_HOSTS`](/pt-br/4.1/ref/settings/#std-setting-ALLOWED_HOSTS).

> **Warning**
>
> Versões prévias deste documento recomendavam configurar o seu web server para garantir que ele valide cabeçalhos HTTP `Host` recebidos. Embora isso ainda seja recomendado, em vários web servers comuns uma configuração que parece validar o cabeçalho `Host` pode na verdade não fazer isso. Por exemplo, mesmo se o Apache estiver configurado de modo que o seu site Django seja fornecido de um host virtual não padrão com o ```ServerName` configurado, ainda é possível para uma requisição HTTP corresponder a esse host virtual e fornecer um cabeçalho ``Host``` falso. Assim, O Django agora exige que você ative explicitamente o setting [`ALLOWED_HOSTS`](/pt-br/4.1/ref/settings/#std-setting-ALLOWED_HOSTS) ao invés de confiar na configuração do web server.

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`](/pt-br/4.1/ref/settings/#std-setting-USE_X_FORWARDED_HOST)) se a sua configuração exigir ele.

## Referrer policy

Browsers use the `Referer` header as a way to send information to a site
about how users got there. By setting a *Referrer Policy* you can help to
protect the privacy of your users, restricting under which circumstances the
`Referer` header is set. See [the referrer policy section of the
security middleware reference](/pt-br/4.1/ref/middleware/#referrer-policy) for details.

## Cross-origin opener policy

> **New in Django 4.0**

The cross-origin opener policy (COOP) header allows browsers to isolate a
top-level window from other documents by putting them in a different context
group so that they cannot directly interact with the top-level window. If a
document protected by COOP opens a cross-origin popup window, the popup’s
`window.opener` property will be `null`. COOP protects against cross-origin
attacks. See [the cross-origin opener policy section of the security
middleware reference](/pt-br/4.1/ref/middleware/#cross-origin-opener-policy) for details.

## Session security

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`](/pt-br/4.1/topics/http/sessions/#module-django.contrib.sessions) também tem limitações. Veja [a seção de segurança do guia que fala sobre sessions](/pt-br/4.1/topics/http/sessions/#topics-session-security) para mais detalhes.

## Conteúdo carregado por upload de usuários

> **Note**
>
> Considere  [servir arquivos estáticos de um serviço na nuvem ou através de uma CDN](/pt-br/4.1/howto/static-files/deployment/#staticfiles-from-cdn) para evitar alguns desses problemas.

- 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](https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody) directive.
- 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`](/pt-br/4.1/ref/models/fields/#django.db.models.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:

  1. Uma 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](https://en.wikipedia.org/wiki/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`](/pt-br/4.1/ref/settings/#std-setting-MEDIA_URL)) de algo como `usercontent-example.com`. *Não* basta apenas fornecer conteúdo de um subdomínio como `usercontent.example.com`.
  2. Beyond this, applications may choose to define a list of allowable
     file extensions for user uploaded files and configure the web server
     to only serve such files.

## Tópicos adicionais de segurança

While Django provides good security protection out of the box, it is still
important to properly deploy your application and take advantage of the
security protection of the web server, operating system and other components.

- Make sure that your Python code is outside of the web server’s root. This
  will ensure that your Python code is not accidentally served as plain text
  (or accidentally executed).
- Tome cuidado com qualquer [arquivo originado de uploads de usuários](/pt-br/4.1/ref/models/fields/#file-upload-security).
- Django does not throttle requests to authenticate users. To protect against
  brute-force attacks against the authentication system, you may consider
  deploying a Django plugin or web server module to throttle these requests.
- Keep your [`SECRET_KEY`](/pt-br/4.1/ref/settings/#std-setting-SECRET_KEY), and [`SECRET_KEY_FALLBACKS`](/pt-br/4.1/ref/settings/#std-setting-SECRET_KEY_FALLBACKS) if in
  use, 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](https://infosec.mozilla.org/guidelines/web_security.html). Their
  pages also include security principles that apply to any system.