{"componentChunkName":"component---src-templates-blog-post-index-js","path":"/o-que-e-e-como-resolver-o-content-security-policy/","result":{"data":{"markdownRemark":{"fields":{"slug":"/o-que-e-e-como-resolver-o-content-security-policy/"},"frontmatter":{"category":"DevOps","date":"10/06/2020","description":"Você conhece a sigla CSP? Veja o que você precisa fazer para deixar sua nota melhor nessas regras de segurança","featuredImage":{"childImageSharp":{"fluid":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAANABQDASIAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAAAAIDAQX/xAAUAQEAAAAAAAAAAAAAAAAAAAAC/9oADAMBAAIQAxAAAAHrLRULGhX/xAAaEAACAgMAAAAAAAAAAAAAAAAAAQISAxEi/9oACAEBAAEFAskWyDkhGrFOj//EABYRAQEBAAAAAAAAAAAAAAAAABEQIf/aAAgBAwEBPwE1n//EABYRAAMAAAAAAAAAAAAAAAAAABARQf/aAAgBAgEBPwFwf//EABoQAAICAwAAAAAAAAAAAAAAAAEhABARIoH/2gAIAQEABj8CyJsVTKgPK//EABoQAAMBAQEBAAAAAAAAAAAAAAERMQAhQXH/2gAIAQEAAT8hJNnmkH1dFbxeWdTEe5ocLh03/9oADAMBAAIAAwAAABB0H//EABYRAAMAAAAAAAAAAAAAAAAAAAEQMf/aAAgBAwEBPxAyL//EABcRAAMBAAAAAAAAAAAAAAAAAAEQESH/2gAIAQIBAT8QGKX/xAAcEAEBAAICAwAAAAAAAAAAAAABEQAhMWFBcZH/2gAIAQEAAT8QGto8onZlB3kj09uGWTVHnH0QgOvuVCSJ6HJrrAAAAHAZ/9k=","aspectRatio":1.5384615384615385,"src":"/static/1f0fa646762bd060fb2de079a2039422/86e90/csp-traffic.jpg","srcSet":"/static/1f0fa646762bd060fb2de079a2039422/17b1e/csp-traffic.jpg 240w,\n/static/1f0fa646762bd060fb2de079a2039422/2d331/csp-traffic.jpg 480w,\n/static/1f0fa646762bd060fb2de079a2039422/86e90/csp-traffic.jpg 960w","srcWebp":"/static/1f0fa646762bd060fb2de079a2039422/c30ee/csp-traffic.webp","srcSetWebp":"/static/1f0fa646762bd060fb2de079a2039422/e8667/csp-traffic.webp 240w,\n/static/1f0fa646762bd060fb2de079a2039422/87b7f/csp-traffic.webp 480w,\n/static/1f0fa646762bd060fb2de079a2039422/c30ee/csp-traffic.webp 960w","sizes":"(max-width: 960px) 100vw, 960px"}}},"photographer":"","title":"O que é e como resolver o Content Security Policy"},"timeToRead":23,"html":"

E ae, meus nobres adoradores de cerveja, código e café. Mais um artigo por aqui no Blog. O primeiro de um assunto que eu tenho tratado na Wooza e tenho curtido bastante, DevSecOps. Em si eu nem criei uma categoria somente para ela, aí acabei colocando na categoria DevOps. Falarei aqui sobre o Content Security Policy, um cara bem importante e que vejo poucas discussões atualmente.

\n

Mas o que seria esse Content Security Policy?

\n

Um fodasse sagaz para melhorar a segurança do conteúdo dos sites. Ele evita ataques de Cross Site Scripting (XSS), injeção de dados, bloqueia outros sites de embedarem seus assets, seus arquivos de media, dentre outras diversas coisas.

\n

Ele ainda não está 100% full power modafoca (nossa, séculos que eu não usava esse termo). Alguns atributos ainda não funcionam corretamente nos browsers.

\n

Esse cara é Cross-browser?

\n

Em si, não, mas a vantagem é que ele dá merda em browsers antigos, as regras são simplesmente ignoradas.

\n

E como implementar essas diretivas?

\n

\n \n \n

\n

É aparentemente simples, mas confesso que não é tanto assim, fora que pode ter algum stress que vou explicar pelo artigo.

\n

Você precisará de até duas etapas de configuração. A parte do CSP você pode fazer tanto com meta-tags, quanto diretamente no servidor com Headers. Vou mostrar as duas formas. E tem também outras configurações que você precisa setar e que só dá pra fazer com Headers.

\n

Mas claro, serviços como o Lambda, da AWS, e o Netlify fazem essa configuração ficar ridiculamente fácil de fazer.

\n

Mas primeiro vamos ver as notas...

\n

Talvez você se pergunte: \"Mas que caralha de nota é essa?\". Relaxa, são notas que seu site recebe dependendo do nível de segurança que ele esteja. Vai de F até A+.

\n

\n \n \n

\n

E podemos verificar em dois sites:

\n\n

Eu só conhecia o Observatory, mas recentemente eu vi esse Security Headers e gostei bastante. O que me deixa um pouco encucado é que um mesmo site pode ter notas diferentes nos sites. Viram ali em cima que minha nota estava tenebrosa antes de au aplicar as policies, né?

\n

Lista dos Scores

\n

Existe uma pequena lista de coisas que os dois sites verificam, vamos ver abaixo:

\n\n

Cada um deles possui um peso diferente e reflete de forma diferente na nota. E podemos resolver todos eles em até duas etapas. Vamos fazer esse fodasse?

\n

Botando a mão na massa, quer dizer, no código...

\n

Primeiro vou mostrar somente a parte dos headers, não mexerei ainda na parte de Content Security Policy. Abaixo temos um código em Node usado no Lambda da AWS. Siga os passos abaixo:

\n
    \n
  1. Entre no Console da AWS e ir no Lambda.
    2. \n
  2. Depois clique no botão Create function
    3. \n
  3. Selecione a opção Author from scratch
    4. \n
  4. Dê um nome qualquer para sua função
    5. \n
  5. Selecione Node.js 12.x em Runtime
    6. \n
  6. Cole o código abaixo:
    7. \n
\n
'use strict';\nexports.handler = (event, context, callback) => {\n  // Get contents of response\n  const response = event.Records[0].cf.response;\n  const headers = response.headers;\n\n  // Set new headers\n  headers['strict-transport-security'] = [\n    {\n      key: 'Strict-Transport-Security',\n      value: 'max-age=63072000; includeSubdomains; preload',\n    },\n  ];\n\n  headers['x-content-type-options'] = [\n    {\n      key: 'X-Content-Type-Options',\n      value: 'nosniff',\n    },\n  ];\n  headers['x-frame-options'] = [\n    {\n      key: 'X-Frame-Options',\n      value: 'DENY',\n    },\n  ];\n  headers['x-xss-protection'] = [\n    {\n      key: 'X-XSS-Protection',\n      value: '1; mode=block',\n    },\n  ];\n  headers['referrer-policy'] = [\n    {\n      key: 'Referrer-Policy',\n      value: 'same-origin',\n    },\n  ];\n  headers['set-cookie'] = [\n    {\n      key: 'Set-Cookie',\n      value: 'HttpOnly; Secure; SameSite=Strict',\n    },\n  ];\n\n  //Return modified response\n  callback(null, response);\n};
\n

\n \n \n

\n

Somente com esses caras aí já conseguimos pular da nota D pra B no Observatory. Uma bela evolução.

\n

E no Netlify, #comofas?

\n

Veja abaixo como fazer no Netlify:

\n
    \n
  1. Crie um arquivo _headers na raiz do seu site. Se for com o Gatsby, coloque na pasta static
    2. \n
  2. Adicione as seguintes linhas nele:
    3. \n
\n
/*\n  Strict-Transport-Security: max-age=63072000; includeSubdomains; preload\n  X-Content-Type-Options: nosniff\n  X-Frame-Options: DENY\n  X-XSS-Protection: 1; mode=block\n  Referrer-Policy: same-origin\n  Set-Cookie: HttpOnly; Secure; SameSite=Strict
\n

Agora vamos voltar para o Content Security Policy realmente

\n

Nesses caras anteriores nós mexemos somente em alguns headers, mas não mexemos no CSP em si. A vantagem é que podemos colocar o CSP via meta-tags. Se você achar dessa forma a mais simples ou não tenha acesso ao Netlify ou Lambda, manda brasa com ele mesmo.

\n

A tag tem a seguinte estrutura:

\n
<meta\n  http-equiv="Content-Security-Policy"\n  content="SUAS POLICIES VEEM AQUI"\n/>
\n

É uma meta-tag simples, mas só porque está sem o conteúdo ainda. Abaixo vou listar todas as policies que você pode setar:

\n\n

Existem ainda alguns outras policies, mas como não mostrarei exemplos delas, e nem de algumas que eu listei acima, vou deixar pra lá

\n

E como eu coloco esses valores?

\n

Simples, coloca tudo separado por ponto e vírgula ;, mesmo se tiver uma ou mais diretivas. Farei um exemplo abaixo:

\n
<meta http-equiv=\"Content-Security-Policy\" content=\"default-src 'self'; style-src 'self';\" />
\n

Confesso que não achei lá muito amigável, mas vou tentar explicar a sequência correta de atribuição de valores:

\n
    \n
  1. policy que você quer adicionar, por exemplo, default-src, mas sem estar entre aspas
    2. \n
  2. depois você coloca o(s) valor(es). Esses valores podem ou não estar entre aspas simples
    3. \n
\n

Mas caralha, como assim podem ou não?

\n

Simples, existem valores padrões, comuns que podem ser usadas nas policies, esses caras podem ter OU NÃO (sim, realmente confuso) precisar de aspas simples. Explicarei abaixo, relaxa o fodasse ae.

\n

Valores comuns para as propriedades no Content Security Policy

\n

Abaixo eu vou listar os valores comuns, ou seja, que podem ser usados em todas (ou quase) as policies.

\n\n

Múltiplos valores

\n

E claro que você pode usar múltiplos valores, senão estaríamos fudidos. E fazer isso é bem simples, segue abaixo:

\n
<meta\n      http-equiv=\"Content-Security-Policy\"\n      content=\"default-src 'none';\n               style-src 'self' data: outrosite.com;\n               script-src 'self' blob: data: outrosite.com;\"\n/>
\n

Quebrei a linha para ficar melhor visualmente, mas pode manter numa linha só também. Percebam que no style-src e script-src têm mais de um valor nessas policies, separados por espaços e somente o 'self' que possui aspas.

\n

Vejam também que nesse caso aí eu liberei que estilos e scripts viessem de outro site chamado outrosite.com.

\n

E o que acontece se eu não passar os valores corretos?

\n

Isso depende. Várias coisas podem acontecer, como por exemplo, um vídeo não abrir, um Google Analytics parar de gravar dados ou até mesmo o site todo parar de funcionar.

\n

Mas por que diabos então eu tenho que usar essa bosta?

\n

Já ouviram falar da LGPD? E da ISO 27001? Muitas empresas terão que entrar nesse esquema, seus clientes e afins. Já tem um tempo que os clientes da Wooza estão correndo atrás para ter todas essas proteções, cobranças já estão sendo feitas, etc.

\n

Mas óbvio que nem tudo é tão simples assim. Não é só colocar o CSP e os Headers que está tudo ok, claro que não. Você precisa avaliar quais estilos, scripts e afins que serão permitidos, abertos.

\n

Mas o pior disso é o famoso GTM, o Google Tag Manager, que a maioria das pessoas, empresas têm usado.

\n

Qual o problema do GTM?

\n

\n \n

Olha o quanto que essa relação pode dar merda, pois se a comunicação não estiver ok, quando essa agência subir um fodasse novo lá, não irá funcionar, porque você, desenvolvedor, não adicionou esse cara na whitelist do CSP.

\n

Vejamos um exemplo...

\n

Pense no seguinte cenário. Você está com uma Landing Page rolando de boa, com seu Content Security Policy na paz, funcionando certinho.

\n

Agora imagine que seu cliente fará uma campanha fodástica no Jornal Nacional, com isso, essa agência acaba colocando uma nova feature, seja imagem, pixel, vídeo, dentre outros via GTM. E aí essas novas URL's não estão na whitelist dessa Landing Page. O que você acha que acontecerá?

\n

A campanha não vai funcionar corretamente. E quem que o cliente vai reclamar? Com a agência? Óbvio que não, com a empresa onde você trabalha, claro. E quem vai se fuder nessa? Sim, você mesmo, desenvolvedor ordinário que está lendo esse post neste momento.

\n

Para a agência tudo estará ok, pois a campanha foi adicionada corretamente via Sales Force, ou afins, pra depois ser adicionada via GTM. Porém, como a sua empresa não foi avisada, essas novas URL's não estarão na whitelist, como já falei trocentas vezes nesse artigo.

\n

Faço exemplo fugindo do código porque eu tenho certeza que eles acontecerão com a Wooza, empresa onde eu trabalho, e com a empresa de vocês e várias outras.

\n

E para resolver isso é relativamente simples, mas mexe com comunicação, algo que nunca é simples. Portanto, prepare-se, dará merda.

\n

VOLTEMOS AO CÓDIGO, DULCETTI...

\n

\n \n \n

\n

Photo by Philipp Katzenberger

\n

Calma, caralha, não precisa gritar. Vamos ver aqui um lista de possibilidades de valores para as diretivas

\n\n

Isso é bem simples de entender, certo? Talvez o último que pareça meio que \"Caralha, mas se eu já defini todos os subdomínios, por que preciso dessa URL completa também?\". Concordo, e acho até que poderia ter alguma atualização pra aceitar.

\n

A explicação é que como o https://disqus.com não está num subdomínio, www por exemplo, ele então não é enxergado pela regra *.disqus.com, portanto, você precisa desse cara também em alguns casos.

\n

Boas práticas de Content Security Policy

\n

Agora farei uma lista de boas práticas e exemplos de tipos de arquivos que você quiser utilizar. A primeira boa prática é usar valor 'none' para o default-src.

\n

Eu uso? Não, que se foda. Mas claro, por enquanto. O valor 'none' te deixa meio estressado, principalmente para a diretiva prefetch-src.

\n

Como assim, estressa?

\n

Pensa no seguinte cenário, você tem o seu site/blog no Gatsby, Next JS, ou qualquer outro. Por boa prática esses caras vão colocar os arquivos estáticos nos prefetchs. O problema é que com o none esses caras não serão enxergados pelos prefetchs, dando erros no console. Explicarei melhor sobre isso mais abaixo.

\n

frame-src e frame-ancestors

\n

Esse cara pode ser meio chato de entender às vezes, principalmmente pelo segundo. O primeiro serve para você liberar iframes no seu site que vêm de outros domínios, por exemplo, embedar vídeos do Youtube.

\n

O segundo é o inverso, caso o seu produto precise ser \"acessado\", embedado via iframe, então você precisa adicionar esse segundo cara. Para um cara como o YouTube, por exemplo, provavelmente precisaria adicionar o *, pois seus ancestrais, nossos blogs por exemplo, poderão usar o embed.

\n

Esse cara raramente será utilizado e uma boa prática é deixa-lo como 'none'. Mas preste atenção se o seu produto será usado em outros locais. Por exemplo, na Wooza nós temos várias modais que são abertas pelos sites dos clientes, portanto, para cada modal as URL's desses clientes e parceiros precisam ser adicionadas no frame-ancestors.

\n

Como eu uso o YouTube e o Disqus, precisei colocar esses caras. E certamente usarei o CodePen, talvez o Vimeo e Facebook também. Com isso, eu utilizo da seguinte maneira:

\n
frame-ancestors 'self';\nframe-src 'none' https://disqus.com *.youtube.com* .vimeo.com *.codepen.io* .facebook.com;
\n

Cada vez que você for usando outras ferramentas, precisará atualizar esse cara, beleza? Assim como o frame-ancestors. Meu Blog não serve para ser embedado em lugar nenhum, então eu deixo 'none' mesmo.

\n

base-uri, form-action, manifest-src, media-src e object-src

\n

Resolvi falar desses juntos porque são caras que uso valores defaults, e também porque não uso mais de um valor. Abaixo segue como eu utilizo:

\n
base-uri 'self';\nform-action 'self';\nmanifest-src 'self';\nmedia-src 'self';\nobject-src 'none';
\n

O base-uri e o manifest-src eu nem preciso explicar, certo? O object-src eu acredito que também não, só deixei bloqueado o carregamento de arquivos falsh e afins.

\n

O form-action que talvez você precise trocar, pois está limitado para somente aceitar actions do mesmo domínio. Caso você use algum serviço externo de formulários, precisará adicionar esse domínio aqui.

\n

E o media-src você pode ter que adicionar outras URL's também, caso use vídeos ou áudios de outros lugares que não sejam por iframes.

\n

font-src, img-src, script-src e style-src

\n

Esses fodasses são os mais \"simples complicados\". Simples de entender, mas a parte complicada são os múltiplos valores que você precisa colocar e atualizar, dependendo dos casos.

\n

Abaixo segue como eu coloco no meu blog:

\n
font-src 'self' data: *.cloudfront.net;\nimg-src 'self' data: blob: *.google-analytics.com *.viglink.com *.disqus.com *.disquscdn.com ce.lijit.com *.cloudfront.net *.githubusercontent.com;\nscript-src 'self' 'unsafe-inline' 'unsafe-eval' blob: *.google-analytics.com *.disqus.com *.disquscdn.com *.cloudfront.net;\nstyle-src 'self' 'unsafe-inline' blob: *.disquscdn.com;
\n

Vejam que o 'self' está em todos, o que é o básico. Você precisa abrir esses arquivos estáticos a partir do seu domínio, ambiente, etc.

\n

No font-src eu tive que colocar o data: e a URL do cloudfront, abirndo para todos os subdomínios. Não sou tão fã de usar o *., mas em casos como esses é necessário, pois você nunca sabe qual URL que será aberta. Na verdade nem precisaria desse cara, mas para eu conseguir enxergar nos Deploys Previews do Netlify, tive que colocar esse cara.

\n

No img-src temos algo parecido com o de fontes, mas ainda tem o blob: e vários domínios. Preciso desses caras porque imagens são adicionadas dinamicamente via Analytics, Disqus, Github e afins. Esse cara certamente precisará ser atualizado algumas vezes, cada vez que você adicionar uma nova integração.

\n

Deixei o script-src e style-src por último porque eles possuem dois caras que são os mais chatos. O 'unsafe-inline' e o 'unsafe-eval' são necessários na maioria dos casos. O 'unsafe-eval' eu só usei por causa do Netlify CMS, ele usa no admin deles. Em alguns casos você precisará deixar esse cara, pois alguns scripts, bibliotecas antigas, usam o eval.

\n

O 'unsafe-inline' eu tive que adicionar nos dois porque eu uso o Analytics/GTM, e eles usam código inline. Em si tem forma de você deixar esses códigos num arquivo externo, usando da forma como eles nunca mostram. Mas como o Gatsby usa códigos CSS inline, então eu não vi motivo para remover esses caras.

\n

Mas por que não usar esses caras, Dulcetti?

\n

A partir do momento que você os utiliza, sua nota cai bastante no Observatory. No Security Headers também fica um warning, mas a nota não fica tão ferrada assim não.

\n

Caso no seu trabalho você precise estar com nota A no Observatory e você usar o GTM ou Analytics, então estará fudido, pois será impossível. Isso porque ao usar em UMA ÚNICA diretiva, sua nota já cai.

\n

Bom, mas como eu preciso usar, que se foda, caguei pra nota máxima. E como o Gatsby usa CSS inline, não adianta colocar o Analytics num arquivo externo, pois o 'unsafe-inline' do style-src, por causa do Gatsby, deixará minha nota baixa do mesmo jeito, então caguei.

\n

Em si você precisa explicar todos esses fodasses para sua empresa, clientes e afins, já elvis?

\n

prefetch-src e o connect-src

\n
prefetch-src 'self' *.netlify.app https://disqus.com *.disqus.com *.disquscdn.com;\nconnect-src 'self' 'unsafe-inline' data: gap: ws:* ssl.gstatic.com *.cloudfront.net *.disqus.com *.disquscdn.com *.google-analytics.com api.github.com *.algolia.net *.algolianet.com;
\n

Deixei esses dois por último porque são chatinhos de explicar e entender algumas vezes. O prefetch-src é mais ou menos parecido como o script-src e o style-src, serve para os arquivos que você quer pré-carregar. Geralmente usamos os do mesmo domínio, com isso, somente o 'self' já estaria bom, porém, com os builds de Gatsby e afins, você precisará colocar outros caras, como Disqus, etc. Esse cara tem um ponto chato também que falarei depois.

\n

Em si o prefetch-src tem alguns bugs de funcionalidade no Chrome, então nem me preocupo tanto assim com ele.

\n

O connect-src é importante, pois será para suas conexões com API's, dentre outros. Você tem que tomar bastante cuidado, pois certamente utilizará API's de serviços externos, tendo que colocar as URL's nesse cara. Veja que coloquei cloudfront, disqus, serviços do google e também o Algolia, que uso como busca.

\n

Veja também que tem a parte de WebSockets, serve muitas vezes para quando você está testando localmente com Gatsby ou outro framework. Fora o ap, data, etc.

\n

Policies que não são permitidas via meta-tag

\n

Sim, existem algumas diretivas com essa limitação, portanto, você precisa setar via Header mesmo. Segue abaixo a lista desses caras:

\n\n

Mas como usar o Content Security Policy então? Via Header ou via Meta-tag?

\n

Geralmente é recomendado fazer tudo via Header. Mas você pode usar o CSP via meta-tags e os outros como Headers mesmo. Felizmente o Netlify facilita bastante isso. O Lambda em si nem é tão fácil pra fazer isso, mas facilita um pouco de configurar.

\n

Bom, e como ficaram os seus Headers CSP, Dulça?

\n

Vou mostrar aqui abaixo, tanto no Netlify, quanto no Lambda. E mostrarei também com as meta-tags. Partiu?

\n

Adicionando headers de Content Security Policy no Netlify

\n
/*\n  Strict-Transport-Security: max-age=63072000; includeSubdomains; preload\n  Content-Security-Policy: default-src 'self' *.disqus.com https://disqus.com *.disquscdn.com *.cloudfront.net; connect-src 'self' 'unsafe-inline' data: gap: ws:* ssl.gstatic.com *.cloudfront.net *.disqus.com *.disquscdn.com *.google-analytics.com api.github.com *.algolia.net *.algolianet.com; font-src 'self' data: *.cloudfront.net; frame-src 'self' https://disqus.com *.youtube.com *.vimeo.com *.codepen.io *.facebook.com; img-src 'self' data: blob: *.google-analytics.com *.viglink.com *.disqus.com *.disquscdn.com ce.lijit.com *.cloudfront.net *.githubusercontent.com; object-src 'none'; prefetch-src 'self' *.netlify.app https://disqus.com *.disqus.com *.disquscdn.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: *.google-analytics.com *.disqus.com *.disquscdn.com *.cloudfront.net; style-src 'self' 'unsafe-inline' blob: *.disquscdn.com;\n  Feature-Policy: accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';\n  X-Content-Type-Options: nosniff\n  X-Frame-Options: DENY\n  X-XSS-Protection: 1; mode=block\n  Referrer-Policy: same-origin\n  Set-Cookie: HttpOnly; Secure; SameSite=Strict\n
\n

Agora vamos ver os Headers no Lambda:

\n
'use strict';\nexports.handler = (event, context, callback) => {\n  // Pega o conteudo do response\n  const response = event.Records[0].cf.response;\n  const headers = response.headers;\n\n  // Seta os novos headers\n  headers['strict-transport-security'] = [{\n    key: 'Strict-Transport-Security',\n    value: 'max-age=63072000; includeSubdomains; preload'\n  }];\n\n  headers['content-security-policy'] = [{\n    key: 'Content-Security-Policy',\n    value: \"default-src 'self' *.disqus.com https://disqus.com *.disquscdn.com *.cloudfront.net; connect-src 'self' 'unsafe-inline' data: gap: ws:* ssl.gstatic.com *.cloudfront.net *.disqus.com *.disquscdn.com *.google-analytics.com api.github.com *.algolia.net *.algolianet.com; font-src 'self' data: *.cloudfront.net; frame-src 'self' https://disqus.com *.youtube.com *.vimeo.com *.codepen.io *.facebook.com; img-src 'self' data: blob: *.google-analytics.com *.viglink.com *.disqus.com *.disquscdn.com ce.lijit.com *.cloudfront.net *.githubusercontent.com; object-src 'none'; prefetch-src 'self' *.netlify.app https://disqus.com *.disqus.com *.disquscdn.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: *.google-analytics.com *.disqus.com *.disquscdn.com *.cloudfront.net; style-src 'self' 'unsafe-inline' blob: *.disquscdn.com;\"\n  }];\n\n  headers['feature-policy'] = [{\n    key: 'Feature-Policy',\n    value: \"accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none'\";\n  }];\n\n  headers['x-content-type-options'] = [{\n    key: 'X-Content-Type-Options',\n    value: 'nosniff'\n  }];\n\n  headers['x-frame-options'] = [{\n    key: 'X-Frame-Options',\n    value: 'DENY'\n  }];\n\n  headers['x-xss-protection'] = [{\n    key: 'X-XSS-Protection',\n    value: '1; mode=block'\n  }];\n\n  headers['referrer-policy'] = [{\n    key: 'Referrer-Policy',\n    value: 'same-origin'\n  }];\n\n  headers['set-cookie'] = [{\n    key: 'Set-Cookie',\n    value: 'HttpOnly; Secure; SameSite=Strict'\n  }];\n\n  // Retorna o response modificado\n  callback(null, response);\n};
\n

Não esqueçam que além de criar o Lambda, vocês precisam adicionar esse cara no Beahaviors do domínio lá no CloudFront. Adicionem o valor index.html como valor no Path Pattern e está tudo certo. Se tiver alguma dúvida é só perguntar nos comentários.

\n

Perceba também que eu adicionei um cara Feature-Policy, ele bloqueia qualquer feature HTML5. Em si ele nem afeta no Observatory, mas afeta no Security Headers. Como eu não uso nada da API do HTML5, coloquei esse cara. Verifique o que você necessita e faça ajustes no seu projeto se precisar.

\n

Agora mostra o seu Content Security Policy com meta-tags, Dulcetti

\n

Agora mesmo, bora ver aqui abaixo com HTML normal:

\n
<meta\n  http-equiv=\"Content-Security-Policy\"\n  content=\"default-src 'self' *.disqus.com https://disqus.com *.disquscdn.com *.cloudfront.net;\n    connect-src 'self' 'unsafe-inline' data: gap: ws:* ssl.gstatic.com *.cloudfront.net *.disqus.com *.disquscdn.com *.google-analytics.com api.github.com *.algolia.net *.algolianet.com;\n    font-src 'self' data: *.cloudfront.net;\n    frame-src 'self' https://disqus.com *.youtube.com *.vimeo.com *.codepen.io *.facebook.com;\n    img-src 'self' data: blob: *.google-analytics.com *.viglink.com *.disqus.com *.disquscdn.com ce.lijit.com *.cloudfront.net *.githubusercontent.com;\n    object-src 'none';\n    prefetch-src 'self' *.netlify.app https://disqus.com *.disqus.com *.disquscdn.com;\n    script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: *.google-analytics.com *.disqus.com *.disquscdn.com *.cloudfront.net;\n    style-src 'self' 'unsafe-inline' blob: *.disquscdn.com;\"\n/>
\n

E agora com JSX

\n
<meta\n  httpEquiv=\"Content-Security-Policy\"\n  content={`default-src 'self' *.disqus.com https://disqus.com *.disquscdn.com *.cloudfront.net;\n    connect-src 'self' 'unsafe-inline' data: gap: ws:* ssl.gstatic.com *.cloudfront.net *.disqus.com *.disquscdn.com *.google-analytics.com api.github.com *.algolia.net *.algolianet.com;\n    font-src 'self' data: *.cloudfront.net;\n    frame-src 'self' https://disqus.com *.youtube.com *.vimeo.com *.codepen.io *.facebook.com;\n    img-src 'self' data: blob: *.google-analytics.com *.viglink.com *.disqus.com *.disquscdn.com ce.lijit.com *.cloudfront.net *.githubusercontent.com;\n    object-src 'none';\n    prefetch-src 'self' *.netlify.app https://disqus.com *.disqus.com *.disquscdn.com;\n    script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: *.google-analytics.com *.disqus.com *.disquscdn.com *.cloudfront.net;\n    style-src 'self' 'unsafe-inline' blob: *.disquscdn.com;\n  `}\n/>
\n

Agora a cerveja no bolo: Subresource Integrity

\n

Esse cara você já deve ter visto em alguns casos, por exemplo na parte de downloads do Bootstrap. Veja que na tag ele tem dois atributos:

\n\n

Mal e porcamente falando, seria uma integridade do código junto à URL, pra só funcionar mesmo se estiver realmente vindo da origem correta. E o crossorigin é pra liberar que sites terceiros usem o caboclo, pra não dar merda de CORS.

\n

Para resolver esse cara no Gatsby é só instalar esse plugin aqui de SRI. É bem simples de configurar, basta adicionar o código abaixo no arquivo gatsby-config.js

\n
{\n  resolve: 'gatsby-plugin-sri',\n  options: {\n    hash: 'sha512',\n    crossorigin: true,\n  },\n},
\n

Só fique ligado caso esteja usando o Netlify com o recurso Assets optimization ligado, pois ele chamará os arquivos vindo da CDN do CloudFront, portanto, outro domínio. Aí acaba quebrando, não funcionando.

\n

Esse cara ajuda a te dar mais cinco pontos na nota do Observatory e conseguir um B+ na nota.

\n

Finalizando

\n

\n \n \n

\n

Bom, tentei resumir aqui pra vocês, mas percebi que não consegui porque o artigo ficou grande pra meireles. Antes eu estava com uma nota D, agora ficou B+.

\n

\n \n \n

\n

Mas no Security Headers eu consegui o A, então de boa, já estou deveras satisfeito.

\n

Vimos que é praticamente impossível chegar no A+ quando você utiliza um Gatsby junto com o um Analytics ou GTM. E eu recomendo mesmo olhar sempre os dois caras:

\n\n

E claro, dando prioridade pro primeiro. Monte sempre um plano de atuação pra esse cara, principalmente se você possuir muitos produtos. Vá em cada Squad e monte um plano para cada URL que precise atuar.

\n

Sente sempre com os PO's para explicar tudo. Se quiser pode chamar os caras de DevOps, DevSecOps ou Infraestrutura para participar e poder tirar qualquer dúvida.

\n

Não fique neurótico com o A+. Você precisará colocar o default-src 'none', por exemplo, o que pode te ferrar no prefetch, mas aí é só escolher certinho e ir atuando aos poucos.

\n

JÁ CHEGA, DULÇA

\n

Beleza, foi mal. Bom, espero que tenha ficado bem explicado. Tá um pouco cansativo, mas acho que foi importante escrever bastante sobre, tentar o máximo explicado possível.

\n

Só para vocês terem ideia, eu fiz mais de 10 Pull Requests, deploys só pra esse cara chegar no cenário atual. E olha que ainda não é o ideal, 100%, por isso que eu falei da neurose.

\n

O Netlify até me avisou que eu tinah chegado nos 75% de consumo de tempo de build. Terei que ficar ligado nos meus PR's :P

\n

Bom, é isso. O que acharam? Aceito sugestões, críticas e afins ;)

\n

Beijo na alcatra.

\n

Links úteis:

\n"}},"pageContext":{"nextPost":{"fields":{"slug":"/como-criar-variaveis-de-ambiente-no-nextjs/"},"frontmatter":{"title":"Como criar variáveis de ambiente no Nextjs"}},"previousPost":{"fields":{"slug":"/como-colocar-um-feed-no-seu-blog-com-o-gatsby/"},"frontmatter":{"title":"Como colocar um feed no seu Blog com o Gatsby"}},"slug":"/o-que-e-e-como-resolver-o-content-security-policy/"}},"staticQueryHashes":["1271460761","2963127411","3623170217","764694655"]}