<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Secrets on Blog do Riverfount</title>
    <link>https://riverfount.dev.br/tags/secrets/</link>
    <description>Recent content in Secrets on Blog do Riverfount</description>
    <generator>Hugo -- 0.148.2</generator>
    <language>pt-BR</language>
    <lastBuildDate>Mon, 06 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://riverfount.dev.br/tags/secrets/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>O .env que você não deveria ter commitado</title>
      <link>https://riverfount.dev.br/posts/env_vars_secrets/</link>
      <pubDate>Mon, 06 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://riverfount.dev.br/posts/env_vars_secrets/</guid>
      <description>&lt;p&gt;Existe uma busca no GitHub que retorna milhares de resultados úteis para um atacante:
&lt;code&gt;filename:.env DB_PASSWORD&lt;/code&gt;. Repositórios públicos com arquivos &lt;code&gt;.env&lt;/code&gt; commitados por
acidente, contendo senhas de banco, chaves de API, segredos JWT — tudo em texto claro,
indexado, pesquisável.&lt;/p&gt;
&lt;p&gt;Não é incompetência. É o resultado natural de uma prática que parece razoável: colocar
credenciais num arquivo, adicionar esse arquivo ao &lt;code&gt;.gitignore&lt;/code&gt;, e confiar que o
&lt;code&gt;.gitignore&lt;/code&gt; vai proteger. Funciona até o dia que não funciona — um &lt;code&gt;git add .&lt;/code&gt; no
momento errado, um novo membro do time que clona o repo e cria o &lt;code&gt;.env&lt;/code&gt; a partir do
&lt;code&gt;.env.example&lt;/code&gt; sem perceber que o exemplo já tem valores reais, ou um editor que cria
arquivos temporários fora do padrão ignorado.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
