{
  "id": 2381364,
  "title": "Your .env file is not the problem",
  "url": "https://urgent.news/2026/08/21/your-env-file-is-not-the-problem",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-21T13:24:36.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/veristria/your-env-file-is-not-the-problem-45fp"
  },
  "original_language": "en",
  "account": "Your .env file is not the issue with unauthorized access to sensitive data in your web application. Many developers believe that simply adding their sensitive information to a .env file and adding it to their .gitignore will keep their data secure. However, this is not the case. The real problem lies within the client-side JavaScript code that contains the sensitive data in plain text. Frontend build tools do not have runtime access to environment variables, so when you write code like this const client = createClient (process.env.NEXT_PUBLIC_SUPABASE_URL, process.env.NEXT_PUBLIC_SUPABASE_KEY); the bundler does not pass the variable through but instead performs a textual substitution at build time, writing the literal string value into the output JavaScript file and serving it from the CDN to anyone who requests it. The prefix NEXT_PUBLIC_ is merely an opt-in to inline the value into the client bundle. The real problem is that the wrong key is being used in the client code, bypassing row-level security and allowing unauthorized access to sensitive data. This can happen when developers use a service-role key instead of an anon key, which bypasses RLS entirely. Unfortunately, most secret-scanning tools do not detect this issue because they only scan your git history or working tree, which are not the correct places to look for this type of vulnerability. The secret is only present in the generated build output, which is not scanned by these tools. To fix this issue, you must rotate the compromised key at the provider immediately and move the sensitive call to a server route, edge function, or RPC. Give the client only the publishable key and let RLS handle the security. This way, you can ensure that sensitive data is not exposed to unauthorized users, and you do not need to rely on secret-scanning tools to detect this type of vulnerability.",
  "summary": "Your .env file is not the problem Originally published on keydrift.dev . Syndicated here with a canonical link back to the original. There is a reassuring ritual in every new project. You put your keys in .env , you check that .env is in .gitignore , and you move on. The repository stays clean. Every secret scanner in CI passes. And then the key ships to every visitor who loads your site. What…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}