Como configurar cabeçalhos de segurança no Nginx

Última atualização em 25 de julho de 2024 15h28 por Joshua James
Tempo estimado de leitura: 16 minutos
Configurando cabeçalhos de segurança no Nginx

Configurar cabeçalhos de segurança no NGINX é essencial para aumentar a segurança de seus aplicativos web. Os cabeçalhos de segurança protegem contra vários ataques, como cross-site scripting (XSS), clickjacking e outros ataques de injeção de código. Eles instruem o navegador sobre como lidar com o conteúdo do seu site, fornecendo uma camada adicional de segurança.

Este guia orientará você nas etapas de configuração de cabeçalhos de segurança no NGINX, ajudando você a proteger seus aplicativos da Web e a melhorar a segurança geral.

Implementando HTTP Strict Transport Security (HSTS) no NGINX

Compreendendo o HSTS

HTTP Strict Transport Security (HSTS) é um protocolo de segurança de site crucial. Ele impõe que as conexões com um domínio sejam exclusivamente via HTTPS. Isto mitiga riscos como ataques man-in-the-middle e garante a integridade e a confidencialidade dos dados transmitidos online. Quando um usuário tenta acessar um site via HTTP, o HSTS atualiza automaticamente a conexão para HTTPS.

Configurando HSTS no NGINX

Para configurar o HSTS no NGINX, você deve atualizar o bloco do servidor no arquivo de configuração do NGINX. Este arquivo normalmente reside em /etc/nginx/nginx.conf ou em configurações específicas do site em /etc/nginx/sites-available/. A atualização envolve a adição de um cabeçalho instruindo o navegador a sempre usar HTTPS para o domínio especificado.

No bloco do servidor do seu domínio, adicione a seguinte linha:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Esta linha contém dois componentes:

  • max-age=31536000: instrua o navegador a lembrar de usar HTTPS em seu site pelos próximos 12 meses.
  • includeSubDomains: aplica a política HSTS a todos os subdomínios do seu site para segurança abrangente.

Exemplo de configuração NGINX com HSTS

Sua configuração NGINX com o cabeçalho HSTS pode ser assim:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        proxy_pass http://my_portal;
    }
}

Depois de adicionar este cabeçalho, recarregue o NGINX para aprovar as alterações com sudo systemctl reload nginx ou sudo nginx -s reload.

Exemplos adicionais de configuração NGINX

Para cenários diferentes, a configuração do NGINX com HSTS pode variar. Aqui estão exemplos adicionais:

Servidor Multi-Domínio

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Esta configuração aplica HSTS a vários domínios hospedados no mesmo servidor. Cada domínio listado imporá conexões HTTPS.

Servidor com terminação SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Esta configuração é para servidores que lidam com terminação SSL. Ele configura o HSTS em uma porta segura (443) com certificados SSL especificados, reforçando conexões seguras.

Configurando a Política de Segurança de Conteúdo (CSP) no NGINX

Implementando CSP no NGINX

A integração de uma Política de Segurança de Conteúdo (CSP) ao NGINX é um movimento estratégico para aprimorar a segurança de aplicativos da web. Envolve adicionar um cabeçalho específico ao bloco do servidor do arquivo de configuração NGINX. Normalmente encontrado em /etc/nginx/nginx.conf ou no diretório /etc/nginx/sites-available/, este arquivo requer edição cuidadosa para aplicar o CSP de maneira eficaz.

Para uma configuração CSP fundamental, adicione a seguinte linha no bloco do servidor:

add_header Content-Security-Policy "default-src 'self';" always;

Esta diretiva restringe o carregamento de conteúdo ao domínio do site ('self'), reduzindo significativamente o risco de execução de conteúdo externo malicioso.

Exemplo de configuração NGINX com CSP

Sua configuração NGINX com a diretiva CSP básica pode ser assim:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Content-Security-Policy "default-src 'self';" always;

    location / {
        proxy_pass http://my_portal;
    }
}

Recarregue o NGINX com sudo systemctl reload nginx ou sudo nginx -s reload após adicionar esta diretiva.

Personalizando CSP para necessidades específicas

O CSP pode ser adaptado para atender às necessidades específicas de segurança do seu site. Aqui estão as configurações expandidas para diferentes cenários:

Permitindo imagens de qualquer fonte

add_header Content-Security-Policy "default-src 'self'; img-src *;" always;

Esta configuração permite carregar imagens de qualquer fonte, mantendo um controle rígido sobre outros tipos de conteúdo.

Configuração específica de scripts e estilos

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscript.com; style-src 'self' 'unsafe-inline';";

Essa configuração permite scripts do seu domínio e de uma fonte externa confiável junto com estilos embutidos, equilibrando funcionalidade com segurança.

Explorando diretivas e opções de CSP

Diretivas em CSP

As diretivas CSP são regras que definem a política para tipos de conteúdo específicos. As diretivas comuns incluem:

  • default-src: a política padrão aplicada à maioria dos tipos de conteúdo.
  • script-src: controla as fontes dos recursos JavaScript.
  • style-src: especifica fontes permitidas para recursos CSS.
  • img-src: Controla as fontes dos recursos de imagem.
  • connect-src: define políticas para conexões de rede como XMLHttpRequest, WebSocket e EventSource.

Expressões de origem em CSP

As expressões de origem definem as fontes permitidas para cada diretiva:

  • 'none': Bloqueia todas as fontes.
  • 'self': Permite recursos da mesma origem.
  • 'unsafe-inline': permite recursos embutidos, como estilos ou URLs JavaScript.
  • 'unsafe-eval': Permite JavaScript eval() funções e métodos semelhantes.
  • https:: Habilita recursos de qualquer URL HTTPS.

Configurando a proteção X-XSS no NGINX

Introdução à proteção X-XSS

X-XSS-Protection, ou cabeçalho Cross-Site Scripting, é essencial para proteger aplicativos da web contra ataques XSS (Cross-Site Scripting). Suportado pelos principais navegadores da web, como Chrome, Internet Explorer e Safari, esse cabeçalho aumenta a segurança da web, evitando o carregamento de páginas quando ataques XSS refletidos são detectados.

Habilitando a proteção X-XSS no NGINX

A integração do cabeçalho X-XSS-Protection na configuração do servidor NGINX reforça a proteção XSS nativa do navegador. Para ativar esse recurso de segurança, acesse o arquivo de configuração do NGINX, normalmente localizado em /etc/nginx/nginx.conf ou no diretório /etc/nginx/sites-available/.

No bloco server do seu arquivo de configuração NGINX, insira esta diretiva:

add_header X-XSS-Protection "1; mode=block";

Esta directiva compreende duas partes:

  • 1: Ativa o Filtro XSS do navegador.
  • mode=block: instrui o navegador a bloquear a página se um ataque XSS for detectado, em vez de tentar higienizá-la.

Exemplo de configuração NGINX com proteção X-XSS

Um exemplo de configuração NGINX incluindo X-XSS-Protection pode ter a seguinte aparência:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass http://my_portal;
    }
}

Depois de adicionar este cabeçalho, recarregue o NGINX usando sudo systemctl reload nginx ou sudo nginx -s reload.

Cenários adicionais de configuração do NGINX

Para um servidor com SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Esta configuração é para servidores com SSL, garantindo que o X-XSS-Protection esteja ativo em conexões criptografadas.

Lidando com vários domínios

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Esta configuração aplica proteção X-XSS em vários domínios hospedados em um único servidor.

Configurando opções de X-Frame no NGINX

O papel das opções do X-Frame

X-Frame-Options é um cabeçalho de segurança essencial projetado para proteger sites contra ataques de clickjacking. Impede que páginas da web sejam exibidas em frames ou iframes, que são frequentemente usados ​​nesses ataques. Suportado por todos os principais navegadores da web, o X-Frame-Options oferece proteção ampla, aumentando a segurança da sua presença na web em diferentes plataformas.

Implementando opções de X-Frame no NGINX

Incorporar o cabeçalho X-Frame-Options na configuração do servidor NGINX é crucial para aumentar a segurança do seu site. Esta tarefa envolve a edição do arquivo de configuração NGINX, normalmente encontrado em /etc/nginx/nginx.conf ou no diretório /etc/nginx/sites-available/.

Para ativar esse recurso de segurança, adicione a seguinte diretiva ao bloco do servidor em seu arquivo de configuração NGINX:

add_header X-Frame-Options "DENY";

Esta diretiva, definida como “DENY”, instrui o navegador a bloquear qualquer tentativa de renderizar a página em um frame ou iframe, oferecendo uma defesa robusta contra clickjacking.

Exemplo de configuração NGINX com opções de X-Frame

Um exemplo de configuração do NGINX com o cabeçalho X-Frame-Options é o seguinte:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Frame-Options "DENY";

    location / {
        proxy_pass http://my_portal;
    }
}

Depois de adicionar este cabeçalho, é importante recarregar o NGINX para ativar as alterações. Isso pode ser feito usando sudo systemctl reload nginx ou sudo nginx -s reload.

Expandindo a configuração NGINX para opções de X-Frame

Para servidores habilitados para SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Esta configuração é para servidores com SSL, garantindo que o X-Frame-Options seja aplicado em conexões seguras.

Lidando com vários domínios

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Esta configuração aplica o cabeçalho X-Frame-Options em vários domínios no mesmo servidor, reforçando a segurança de cada domínio.

Implementando opções de tipo de conteúdo X no NGINX

Papel das opções X-Content-Type

X-Content-Type-Options é um cabeçalho de segurança vital na segurança da web que evita que os navegadores detectem o tipo MIME. Este cabeçalho reforça que os navegadores respeitam o tipo de conteúdo declarado nos cabeçalhos HTTP, abordando vulnerabilidades de segurança que podem surgir quando os navegadores interpretam mal os tipos de arquivo, como tratar arquivos de imagem como HTML executável, o que pode levar a ataques de cross-site scripting (XSS).

Configurando opções de tipo de conteúdo X no NGINX

Para aumentar a segurança do seu servidor web com o cabeçalho X-Content-Type-Options, você precisa modificar o arquivo de configuração NGINX diretamente. Este arquivo geralmente é encontrado em /etc/nginx/nginx.conf ou nas configurações específicas do site em /etc/nginx/sites-available/.

Incorpore este cabeçalho adicionando a seguinte linha ao server bloco da sua configuração NGINX:

add_header X-Content-Type-Options "nosniff";

A configuração “nosniff” orienta o navegador a seguir rigorosamente o tipo de conteúdo especificado pelo servidor, evitando interpretações alternativas do conteúdo.

Exemplo de configuração NGINX com X-Content-Type-Options

Uma configuração NGINX com X-Content-Type-Options pode ser estruturada da seguinte forma:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Content-Type-Options "nosniff";

    location / {
        proxy_pass http://my_portal;
    }
}

Depois de atualizar sua configuração, certifique-se de recarregar o NGINX para que as alterações tenham efeito, usando sudo systemctl reload nginx ou sudo nginx -s reload.

Exemplos de configuração expandida do NGINX

Configuração para SSL/TLS

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header X-Content-Type-Options "nosniff";

    # Additional SSL configurations and locations
}

Esta configuração é para servidores com SSL/TLS, aplicando X-Content-Type-Options em conexões seguras para aumentar a segurança.

Configuração de servidor multidomínio

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Content-Type-Options "nosniff";

    # Additional configurations for multiple domains
}

Esta configuração aplica o cabeçalho X-Content-Type-Options em vários domínios hospedados no mesmo servidor, garantindo configurações de segurança consistentes em todos os domínios.

Configurando a política de referência no NGINX

A função da política de referência

Referrer-Policy é um cabeçalho HTTP essencial para aumentar a privacidade e segurança do usuário na web. Ele controla a quantidade de informações de referência incluídas no cabeçalho Referer quando os usuários navegam do seu site para outros, protegendo informações confidenciais contra exposição em solicitações da web.

Configurando a política de referência no NGINX

Para implementar o cabeçalho Referrer-Policy em seu servidor NGINX, modifique o arquivo de configuração NGINX, normalmente encontrado em /etc/nginx/nginx.conf ou no diretório /etc/nginx/sites-available/. Adicione a seguinte diretiva ao bloco do servidor:

add_header Referrer-Policy "no-referrer";

Esta diretiva, definida como “no-referrer”, garante que nenhuma informação do referenciador seja enviada durante a navegação no site, maximizando a privacidade.

Exemplo de configuração NGINX com Referrer-Policy

Sua configuração NGINX com o cabeçalho Referrer-Policy poderia ser assim:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Referrer-Policy "no-referrer";

    location / {
        proxy_pass http://my_portal;
    }
}

Depois de adicionar este cabeçalho, recarregue o NGINX com comandos como sudo systemctl reload nginx ou sudo nginx -s reload.

Opções e definições de política de referência

  • no-referrer: Nenhuma informação de referência é enviada.
  • no-referrer-when-downgrade (padrão): envia informações de referência para destinos de mesma origem ou para URLs de destino seguros (HTTPS) de uma página segura.
  • origin: Envia apenas a origem (esquema, host e porta).
  • origin-when-cross-origin: Envia URL completo para solicitações de mesma origem, mas apenas a origem para outros casos.
  • mesma origem: envia um referenciador completo para solicitações de mesma origem, mas nenhum cabeçalho para solicitações de origem cruzada.
  • strict-origin: Envia a origem para solicitações HTTPS, mas nenhum cabeçalho para solicitações HTTP.
  • strict-origin-when-cross-origin: Envia referenciador completo para solicitações de mesma origem, origem para destinos HTTPS de páginas HTTPS e nenhum cabeçalho para destinos HTTP.
  • url inseguro: Envia URL completo independentemente da origem ou segurança (não recomendado).

Exemplos de configuração expandida do NGINX

Configuração SSL/TLS

server {
    listen 443 ssl;
    server_name secure.example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Referrer-Policy "no-referrer";

    # Additional SSL configurations
}

Esta configuração aplica o cabeçalho Referrer-Policy em um ambiente seguro habilitado para SSL/TLS, aumentando a privacidade em conexões criptografadas.

Configuração de servidor multidomínio

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Referrer-Policy "no-referrer";

    # Additional configurations for each domain
}

Essa configuração garante que o cabeçalho Referrer-Policy seja aplicado em vários domínios hospedados no mesmo servidor, mantendo configurações de privacidade consistentes.

Implementando política de permissões no NGINX

Noções básicas sobre política de permissões

O cabeçalho Permissions-Policy capacita os administradores da web com controle preciso sobre os recursos do navegador e APIs em seus sites. A configuração deste cabeçalho aumenta significativamente a segurança e a privacidade do site, permitindo restrições de recursos como geolocalização, câmera e microfone com base nas necessidades específicas do seu site.

Configurando a política de permissões no NGINX

Para incorporar o cabeçalho Permissions-Policy em seu servidor NGINX, modifique o arquivo de configuração NGINX, geralmente localizado em /etc/nginx/nginx.conf ou no diretório /etc/nginx/sites-available/.

Adicione a seguinte diretiva ao bloco do servidor:

add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

Esta diretiva lista vários recursos e APIs do navegador, configurando-os como (), o que efetivamente os desativa. Esta configuração fornece uma abordagem abrangente para limitar recursos que podem comprometer a privacidade ou a segurança do usuário.

Exemplo de configuração NGINX com política de permissões

Aqui está um exemplo de como sua configuração NGINX pode parecer com o cabeçalho Permissions-Policy:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Esta diretiva lista de forma abrangente vários recursos e APIs do navegador, configurando-os como () para desativá-los efetivamente.

Exemplo de configuração NGINX com política de permissões

Sua configuração NGINX, incluindo Permissions-Policy, pode ser assim:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Recarregue o NGINX com sudo systemctl reload nginx ou sudo nginx -s reload após fazer essas alterações.

Opções de política de permissões explicadas

O cabeçalho Permissions-Policy permite personalizar o uso de vários recursos:

  • geolocalização: controla o acesso aos dados de geolocalização.
  • midi: gerencia o acesso a dispositivos MIDI.
  • notificações: controla a exibição de notificações.
  • empurrar: afeta a funcionalidade de notificação push.
  • sincronização-xhr: está relacionado ao XMLHTTPRequest síncrono.
  • acelerômetro: Dita o acesso ao acelerômetro do dispositivo.
  • giroscópio: Controla o acesso ao giroscópio.
  • magnetômetro: gerencia o acesso ao magnetômetro do dispositivo.
  • pagamento: aplica-se a recursos de solicitação de pagamento.
  • USB: controla o acesso a dispositivos USB.
  • realidade virtual: Refere-se a recursos de realidade virtual.
  • Câmera: gerencia o acesso à câmera.
  • microfone: Dita o acesso ao microfone.
  • palestrante: controla o acesso aos dispositivos de alto-falante.
  • vibrar: afeta a API de vibração.
  • sensor de luz ambiente: Refere-se ao sensor de luz ambiente.
  • Reprodução automática: Controla a reprodução automática de mídia.
  • mídia criptografada: gerencia o acesso à mídia criptografada.
  • executar-área de transferência: controla o acesso de leitura/gravação à área de transferência.
  • domínio do documento: pertence ao recurso document.domain.
  • tela cheia: Dita o acesso em tela cheia.
  • captura de imagem: Controla a funcionalidade de captura de imagem.
  • carga preguiçosa: afeta o carregamento lento de imagens.
  • formatos de imagem legados: refere-se a formatos de imagem legados.
  • imagens grandes: controla o carregamento de imagens grandes.
  • imagens com perdas não otimizadas: gerencia imagens com perdas não otimizadas.
  • imagens sem perdas não otimizadas: refere-se a imagens sem perdas não otimizadas.
  • mídia não dimensionada: Controla a mídia sem tamanho explícito.
  • rolagem vertical: afeta a rolagem vertical.
  • compartilhamento na web: está relacionado aos recursos de compartilhamento na web.
  • xr-rastreamento espacial: controla o rastreamento espacial XR.

Configurações avançadas de política de permissões no NGINX

Configurando políticas de permissões com domínios específicos e curingas

Além da configuração básica de desabilitar recursos usando (), a política de permissões no NGINX pode ser adaptada para permitir determinados recursos de domínios específicos ou usando curingas. Essa configuração avançada permite um controle mais sutil sobre o que seu site pode acessar e de onde.

Exemplo: Permitindo Recursos de Domínios Específicos

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(https://trusteddomain.com), microphone=(https://alloweddomain.com)";

    location / {
        proxy_pass http://my_portal;
    }
}

Essa configuração permite acesso a dados de geolocalização somente de https://trusteddomain.com e acesso ao microfone somente de https://alloweddomain.com, aumentando a segurança ao restringir esses recursos confidenciais a fontes confiáveis.

Exemplo: Usando curingas para permissões amplas

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "camera=*; fullscreen=*";

    location / {
        proxy_pass http://my_portal;
    }
}

O curinga * nesta configuração permite acesso à câmera e modo de tela cheia de qualquer domínio. Essa abordagem oferece permissões mais amplas, adequadas para sites que exigem amplo acesso a recursos de diversas fontes.

Exemplo: Combinando Restrições e Permissões

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "accelerometer=(); gyroscope=(self https://example2.com); payment=*";

    location / {
        proxy_pass http://my_portal;
    }
}

Nesta configuração, o acesso ao acelerômetro está desabilitado, o acesso ao giroscópio é permitido no mesmo domínio e https://example2.com, e as solicitações de pagamento são permitidas em todos os domínios.

Verificando cabeçalhos de segurança com comando Curl no NGINX

Usando Curl para verificar cabeçalhos de segurança

O comando curl é uma ferramenta valiosa para verificar a configuração dos cabeçalhos de segurança em seu servidor NGINX. Ele permite que você inspecione os cabeçalhos do seu site e confirme se os cabeçalhos de segurança estão configurados corretamente. Esta etapa de verificação é crucial para garantir que as medidas de segurança do seu servidor web estejam ativas e funcionando conforme esperado.

Executando o comando Curl para verificação de cabeçalho

Para verificar os cabeçalhos do seu site, execute o seguinte comando no seu terminal:

curl -I http://example.com

Substitua example.com pelo seu nome de domínio. Este comando solicita os cabeçalhos do seu servidor, fornecendo informações sobre as configurações de segurança ativas.

Resultado Esperado e Interpretação

Ao executar o comando curl, você deverá receber uma saída semelhante a esta:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Mar 2023 00:00:00 GMT
Content-Type: text/html
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self';
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();"

Esta saída confirma a presença e configuração correta de vários cabeçalhos de segurança em seu servidor, como Strict-Transport-Security, Content-Security-Policy, X-XSS-Protection e outros. Cada cabeçalho listado na saída desempenha uma função específica na segurança e proteção do seu servidor web contra várias vulnerabilidades da web.

Conclusão

Ao configurar cabeçalhos de segurança no NGINX, você aumenta significativamente a segurança de seus aplicativos web. Revise e atualize regularmente seus cabeçalhos de segurança para se adaptar às ameaças de segurança em evolução. A implementação desses cabeçalhos ajuda a proteger contra uma ampla variedade de ataques e garante uma experiência de navegação mais segura para seus usuários. Mantenha a vigilância e a configuração do NGINX atualizada para proteger seus ativos da web de maneira robusta.

Joshua James
Me siga
Últimos posts por Joshua James (exibir todos)

Como instalar o Android Studio no Linux Mint 22, 21 ou 20

Como instalar o Rust no Debian 12, 11 ou 10 Linux

Deixe um comentário


Se você tiver alguma dúvida legítima, como sugestões de artigos, não hesite em entrar em contato com LinuxCapable. Certifique-se de que sua mensagem esteja escrita em inglês.

Contate-nos
Sobre nós Isenção de responsabilidade política de Privacidade Termos e Condições