Pular para o conteúdo

Page Shield

O Page Shield trabalha nas respostas que o seu app envia. O conector acrescenta os cabeçalhos de segurança que o app deixa de fora e dá a cada host uma nota de A+ a F. Ele leva a sua Content Security Policy e lista o que os navegadores relatam contra ela. Pode pôr nas suas páginas um banner de consentimento que segura os rastreadores até o visitante aceitar. No proxy do Qlyne e no hospedado, também guarda páginas inteiras e respostas de API na memória pelo tempo que você escolher, com invalidação (purge) pelo painel ou pelo seu deploy.

ConectorO que funciona
Proxy do QlyneTudo desta página
Hospedado pelo QlyneTudo desta página
Worker da CloudflareCabeçalhos, nota, CSP com relatório de violações e o banner de consentimento. Sem cache de página e sem invalidação.
  1. Conecte o site (Escolha a integração).
  2. Abra o site e vá em Page Shield › Configuração. Escolha um nível de proteção e ajuste em Avançado.
  3. Para o banner, vá em Page Shield › Consentimento de cookies. Para o cache, Page Shield › Cache de página.

As mudanças chegam ao conector em até um minuto. O Page Shield não espera o “Aplicar” de Conector › Configuração: cabeçalhos, CSP, banner e cache valem também no modo observar.

O nível no topo de Page Shield › Configuração preenche os cabeçalhos e o modo da CSP e salva. Mude qualquer um deles à mão e o nível aparece como “Personalizado”.

CampoBásicoEquilibradoAgressivo
HSTSDesligadoLigado, um anoLigado, inclusive subdomínios
X-Content-Type-Options: nosniffligadoligadoligado
Referrer-PolicyDesligadostrict-origin-when-cross-originsame-origin
MolduraDesligadoSó o meu próprio siteNinguém
Modo da CSPDesligadoSó relatarAplicar

Um nível nunca mexe na sua política, no Permissions-Policy, no banner nem no cache de página. Equilibrado e Agressivo ligam a CSP, então precisam de uma política no campo “Política” antes; sem ela, o painel pede que você escreva ao salvar.

No Free, o modo da CSP que um nível preenche fica salvo e passa a valer assim que a conta estiver no Pro.

Em Page Shield › Configuração, Avançado, o cartão “Cabeçalhos de segurança”:

  • “HSTS”: “Desligado”, “Ligado, um ano” ou “Ligado, inclusive subdomínios”. Só vai em HTTPS.
  • “Moldura”: “Só o meu próprio site” (X-Frame-Options: SAMEORIGIN) ou “Ninguém” (DENY). Deixe desligado se outros sites mostram as suas páginas num iframe.
  • “Referrer-Policy”: uma de quatro políticas, ou desligado.
  • “Permissions-Policy”: uma linha, como camera=(), microphone=().
  • “X-Content-Type-Options: nosniff”.

Um cabeçalho entra na resposta só quando o app ainda não manda. Quando o app manda o dele, vale o valor do app.

O mesmo cartão mostra a nota de até três hosts, com o que falta em cada um. Ela conta seis proteções nas páginas HTML que passaram pelo conector, incluindo os cabeçalhos do próprio app:

  • HSTS com max-age de pelo menos 180 dias;
  • uma Content Security Policy;
  • X-Content-Type-Options: nosniff;
  • uma Referrer-Policy que não seja unsafe-url nem no-referrer-when-downgrade;
  • proteção contra iframe, por X-Frame-Options ou frame-ancestors na CSP;
  • uma Permissions-Policy.

As seis dão A+, cinco A, quatro B, três C, duas D, menos que isso F. A nota aparece menos de um minuto depois de uma página do seu site passar pelo conector e mostra sempre a última página vista em cada host.

Uma Content Security Policy diz ao navegador quais scripts, imagens e conexões uma página pode usar. O cartão “Content Security Policy” recebe:

  • “Modo”: “Desligado”, “Só relatar” ou “Aplicar”;
  • “Política”: uma linha de até 4.000 caracteres, diretivas separadas por ponto e vírgula, como default-src 'self'; script-src 'self' https://www.googletagmanager.com.

Em “Só relatar”, o conector manda a política como Content-Security-Policy-Report-Only: o navegador carrega tudo e relata o que a política teria barrado. Em “Aplicar”, ela vai como Content-Security-Policy e o navegador barra.

O conector tira da sua política qualquer report-uri ou report-to e põe o dele. Os navegadores então postam cada violação na própria página, em ?__qlyne=csp, e o conector responde com um 204 vazio. No proxy do Qlyne e no hospedado ele manda também Reporting-Endpoints; o Worker usa só report-uri.

Embaixo da política, “Barrado nos últimos 7 dias” lista as dez violações mais frequentes: o que foi barrado, a diretiva e quantas vezes.

O conector não gera nonce. Para liberar um script inline, ponha o hash dele ('sha256-…') na sua política, ou passe o script para um arquivo no seu domínio.

Em Page Shield › Consentimento de cookies.

“Injetar na borda” (Pro): com “Ligar a injeção na borda” ligado (salva assim que você vira a chave), o conector põe o banner no <head> de cada página HTML. Ele também segura os rastreadores conhecidos até o visitante aceitar a categoria deles:

  • Análises: Google Analytics, Google Tag Manager, Hotjar, Segment, Microsoft Clarity, FullStory, Mixpanel, Mouseflow, Crazy Egg.
  • Marketing: o pixel da Meta (Facebook), DoubleClick, Google Ads, TikTok, LinkedIn.

No proxy do Qlyne e no hospedado, ficam presos os scripts, os pixels de imagem e os iframes desses endereços. No Worker, só as tags <script src>, e a lista deixa de fora o pixel de imagem da Meta e a conversão do Google Ads.

“Banner” define o que o visitante vê. “Simples” tem a cor de destaque e as categorias; “Completo” acrescenta o resto:

  • “Cor de destaque”;
  • “Categorias que o visitante pode escolher”: “Análises”, “Marketing”, “Funcionais”;
  • “Posição na tela”: “Barra embaixo”, “Barra no topo”, “Canto inferior esquerdo”, “Canto inferior direito” ou “Modal no centro”;
  • “Língua”: “Idioma do visitante”, English ou Português;
  • “URL da política de privacidade”: um caminho como /privacy ou um endereço https:// completo;
  • “Mensagem própria”: até 300 caracteres, ou vazio para o texto padrão.

Aperte Salvar depois de mudar o banner.

“Ou cole você mesmo” (qualquer plano): copie a tag <script> para o <head> do seu site. Nada fica preso sozinho, então marque cada rastreador trocando a tag dele para type="text/plain" com data-qlyne-consent e a categoria. A tela mostra o exemplo com o Google Analytics. Use a mesma marcação nos seus próprios scripts com a injeção ligada.

Em Page Shield › Cache de página, no proxy do Qlyne e no hospedado.

  • “Rotas cacheadas”: um padrão de caminho (* casa com qualquer coisa, como /blog/*) e quanto tempo a cópia fica, de 1 a 86.400 segundos (24 horas). Até 50 rotas.
  • “Cookies de login”: os nomes dos cookies que indicam visitante logado, um por linha, até 20. Um cookie cujo nome contém um deles tira o pedido do cache; os outros, como os de análise, não. Vazio quer dizer que qualquer cookie tira o pedido do cache.

Uma resposta entra no cache só quando tudo isto vale:

  • o pedido é um GET, sem cabeçalho Authorization e sem cookie de login;
  • a resposta é um 200 em HTML ou JSON, de até 2 MB;
  • ela não tem Set-Cookie, nem Cache-Control: private, nem Vary além de Accept-Encoding.

O tempo que você põe na rota vale mais que o no-cache ou o no-store da sua origem. Se a origem manda stale-while-revalidate, a página vencida é servida enquanto o conector busca uma nova em segundo plano. Se a origem falha, a cópia vencida continua sendo servida por até uma hora. Quando muitos visitantes pedem a mesma página ao mesmo tempo, a origem recebe um pedido só.

O banner de consentimento e o script da nota de robô entram a cada pedido, então uma página que veio do cache continua com eles.

No proxy do Qlyne, a memória do cache é QLYNE_CACHE_MB (64 MB por padrão; veja Configuração).

Depois de publicar uma mudança, limpe as cópias que mudaram.

Pelo painel, em Page Shield › Cache de página, “Invalidar”: “Invalidar tudo”, ou digite um caminho e aperte “Invalidar este caminho”. O caminho vale como prefixo: /blog/post limpa também /blog/post?utm_source=… e /blog/post-2, e / limpa tudo.

Pelo seu servidor ou pelo script de deploy, chame o conector no seu próprio domínio com o segredo do conector:

Janela do terminal
curl -X POST https://example.com/__qlyne/purge \
-H "Authorization: Bearer your_connector_secret" \
-H "Content-Type: application/json" \
-d '{"paths": ["/blog/new-post"]}'

O corpo aceita {"all": true}, {"paths": [...]} (por prefixo) ou {"tags": [...]}. Tags e caminhos combinam numa chamada só. A resposta é 200 com {"purged": 12}, o número de cópias limpas. Sem o segredo certo, o endereço responde 404. Deixe essa chamada no servidor: o segredo nunca pode chegar a um navegador.

Para invalidar por tag, faça a sua origem mandar X-Qlyne-Cache-Tags: product-123, home nas respostas. O conector guarda as tags e tira o cabeçalho antes de a página chegar ao visitante. Ao salvar o produto 123, você invalida {"tags": ["product-123"]}, e toda página em cache que mostrava esse produto sai de uma vez.

  • Cabeçalhos de segurança: nada na página. O navegador aplica. Com HSTS ligado, depois de uma visita em HTTPS o navegador usa só HTTPS por um ano.
  • CSP: em “Só relatar”, nada muda. Em “Aplicar”, o que a política não permite fica fora da página, como um script ou uma imagem de outro endereço.
  • Banner de consentimento: uma barra, uma caixa no canto ou uma janela no centro, em inglês ou português conforme a língua do navegador. O texto padrão é “Usamos cookies para melhorar sua experiência. Você escolhe o que aceitar.”, com “Aceitar tudo”, “Recusar” e “Preferências”. “Preferências” lista “Necessários (sempre ativos)” e as categorias que você oferece. A escolha fica no navegador do visitante, no cookie qlyne_consent, por 180 dias; nada dela chega ao Qlyne. Um botão na página abre o banner outra vez.
  • Cache de página: a mesma página, vinda da memória do conector. A resposta leva x-qlyne-cache: HIT com Age, STALE para uma cópia vencida, ou MISS quando veio da sua origem. Um visitante logado recebe sempre a página da origem, sem o cabeçalho.
  • O cache de página e a invalidação existem só no proxy do Qlyne e no hospedado. Na Cloudflare, use as regras de cache da própria Cloudflare.
  • Cada proxy do Qlyne tem o seu cache. Com vários proxies, a invalidação limpa só o que recebeu a chamada, então mande para cada um.
  • Invalidar por tag é só pela API; o painel invalida tudo ou um caminho.
  • O Worker relata violações da CSP só por report-uri, sem report-to nem Reporting-Endpoints.
  • Uma CSP em “Aplicar” pode quebrar scripts que a sua política esquece. Comece em “Só relatar” e aplique quando a lista mostrar só o que você espera.
  • O banner segura rastreadores carregados dos endereços acima. Código escrito inline na página roda mesmo assim; marque os seus scripts.
  • O banner aparece para todo visitante, de onde ele estiver. O Qlyne não guarda registro de quem aceitou o quê.
  • A nota guarda só a última página de cada host, sem histórico, e aparece só em Page Shield › Configuração.

Os cabeçalhos entram só onde o app não manda nenhum, e a CSP começa em “Só relatar”, onde nada é barrado. Três campos mudam o que o navegador faz, então confira antes:

  • O HSTS faz o navegador recusar HTTP sem criptografia no seu site por um ano. “Ligado, inclusive subdomínios” vale para todo subdomínio, então ligue só quando todos servem HTTPS.
  • “Ninguém” em “Moldura” impede qualquer site de mostrar as suas páginas num iframe, o seu inclusive. “Só o meu próprio site” libera o seu.
  • Uma CSP em “Aplicar” barra o que a política não lista. Leia “Barrado nos últimos 7 dias” por alguns dias em “Só relatar” antes.

O cache de página só mexe nas rotas que você adiciona.

Na União Europeia, cookies de análise costumam precisar de consentimento, porque não são necessários para o site funcionar. Na LGPD, o consentimento é uma das bases legais. Se análise é tudo o que você tem, ofereça só “Análises” no banner. O banner é uma ferramenta e não atesta conformidade; confira com quem cuida da sua política de privacidade.

Ponha a chamada de invalidação no seu deploy, depois que a versão nova estiver no ar: {"all": true} para uma versão inteira, {"paths": [...]} para as páginas que mudaram. Numa loja ou num blog, marque as respostas com tags e invalide a tag do que você salvou. À mão, use “Invalidar tudo” ou “Invalidar este caminho” em Page Shield › Cache de página.

Um pedido com cabeçalho Authorization ou cookie de login vai sempre para a sua origem, e nada dele entra no cache. Preencha “Cookies de login” com todo cookie que muda a página, carrinho e sessão inclusive, não só o de login. Com a lista vazia, qualquer cookie tira o pedido do cache, então visitantes com um cookie de análise também ficam de fora. A sua origem também pode deixar uma resposta fora mandando Set-Cookie ou Cache-Control: private.

Em parte. No Free: os cabeçalhos de segurança e a nota, e o banner colando o trecho. O Pro acrescenta a CSP com a lista de violações, o banner injetado na borda e o cache de página com invalidação. Toda conta nova começa com 7 dias de Pro, sem cartão. Veja Planos.

Abra “Barrado nos últimos 7 dias”: cada linha mostra o endereço barrado e a diretiva. Ponha esse endereço na diretiva da sua política, como script-src 'self' https://www.googletagmanager.com. Para um script inline, ponha o hash dele ou passe o script para um arquivo. Com o banner injetado, a política precisa liberar https://app.qlyne.com em script-src. Volte para “Só relatar” enquanto corrige; a mudança chega ao conector em até um minuto.

Confira, nesta ordem:

  • o site está no Pro e “Ligar a injeção na borda” está ligado. No Free a chave fica desligada; cole o trecho;
  • o site passa pelo proxy do Qlyne, pelo hospedado ou pelo Worker. O middleware do Next.js não injeta o banner, então cole o trecho ali;
  • você ainda não respondeu: a escolha fica 180 dias. Abra o site numa janela anônima;
  • uma CSP em “Aplicar” não está barrando https://app.qlyne.com.

Peça a página duas vezes e olhe o x-qlyne-cache na resposta.

  • Sem o cabeçalho: o pedido não se qualificou. O caminho não está em “Rotas cacheadas”, o site não está no Pro, o pedido não é GET, ou leva Authorization ou um cookie que tira do cache. Com “Cookies de login” vazio, qualquer cookie tira, o seu cookie de análise inclusive.
  • MISS toda vez: a resposta não pode ser guardada. Procure um Set-Cookie que o seu framework manda em toda página, Cache-Control: private, um status diferente de 200, um tipo que não é HTML nem JSON, um Vary além de Accept-Encoding, ou uma página acima de 2 MB.
  • No Worker da Cloudflare não há cache de página.