0

I'm building an application with NextJS and importing .env from dotenv has been causing an fs error while using require.

I resolved this by creating a env-config.js, storing the private variables accordingly, and then specifying env.config.js in my .gitignore file.

Is this secure? What's the lower level difference between .env and .js storage? I assume the variables are stored differently hence the purpose of the .env file?

I am a noob so apologies in advance!

EDIT

Here is how the FS error is generated:

import {useAddress, useContract} from "@thirdweb-dev/react";
import {useEffect, useState} from "react";
// import envConfig from "../env-config"; // my work around!

require("dotenv").config()

export default function Home() {
  const address = useAddress();
  const editionDrop = useContract(process.env.EDITION_DROP_ADDRESS, "edition-drop").contract;
  ...
}

Produced:

Failed to compile
./node_modules/dotenv/lib/main.js:1:0
Module not found: Can't resolve 'fs'

Import trace for requested module:
./pages/index.js

https://nextjs.org/docs/messages/module-not-found

Removing the require("dotenv").config() caused the error to go away hence the .js solution to get the hidden variables

alpo
  • 19
  • 4
  • From my knowledge, this seems as secure as .env (as it is a plaintext file being read by NodeJS, except it's being executed), [not that .env was too secure in production anyway.](https://www.trendmicro.com/en_us/research/22/h/analyzing-hidden-danger-of-environment-variables-for-keeping-secrets.html) – LeoDog896 Oct 25 '22 at 16:00
  • Presumable dotenv creates environment variables - I guess if you see no difference it is because you are reading them into javascript variables in your application. But of course that is two different types of variables, isn't it? – topsail Oct 25 '22 at 16:03
  • interesting - do you know how "big tech" companies securely store their variables assuming .env is not being utilized? – alpo Oct 25 '22 at 16:03
  • I've only worked with one team that uses a centralized environment service (doppler), but I found a related StackOverflow answer: https://stackoverflow.com/a/65330139/15324033 – LeoDog896 Oct 25 '22 at 16:06
  • 2
    dotenv is primarily a development tool. It's not really designed for use in prod. Why don't you use actual environment variables on your server/instance in prod? dotenv is only designed to mimic environment variables so you don't have to keep setting them when developing – Liam Oct 25 '22 at 16:12
  • 2
    You mentioned you're compiling using NextJS; ostensibly you're building a client-facing React application. As such, `fs` (a dependency of `dotenv`) won't be available because it's pretty useless in a browser context, where you can't arbitrarily traverse the filesystems of your users. If your **client** application that you're building with NextJS requires the use of secrets, you need to re-think your architecture as you're (inadvertently, it seems) bundling these secrets into your client code where **literally anyone** could read them. They are called **secrets** for a very good reason. – esqew Oct 25 '22 at 16:13
  • 2
    Yes this ^ client side "secrets" is an oxymoron – Liam Oct 25 '22 at 16:14
  • @Liam interesting - I will research this. Thank you! – alpo Oct 25 '22 at 16:15
  • That said what exactly is secret about these things? They just look like server addresses – Liam Oct 25 '22 at 16:15
  • _"Is this secure?"_ Assuming, you mean whether the users can read the variables, no, nothing in the frontend is secure. – jabaa Oct 25 '22 at 16:24

0 Answers0