4 ms·
Your environment is not secure. The solution for this type of problem (keeping secrets out of source control) is to create a deployment-specific configuration f
by iguana 13y ago
Your environment is not secure. The solution for this type of problem (keeping secrets out of source control) is to create a deployment-specific configuration file that is not kept in source control. It can be created out of a generic version that is kept in source control. Then, OS-level permissions are applied so the file is only readable by the processes that need access.
- duaneb 13y agoHow is the environment any less secure than memory? If someone can read or mutate your environment, you should assume your app is already compromised and OS-level permissions aren't going to do anything.
- justincormack 13y agoMost people probably set the environment for all processes not just on a need to know basis perhaps.
- ctz 13y agoCertain weird-shit UNIX operating systems do not provide privacy for a process's environment. (eg. another user on the same box can see them with 'ps e'). More relevantly, POSIX does not require it. The same is not true of process memory.
- danielfone 13y agoIt's worth noting that with 'dotenv' the configuration is stored in a file on the production server before it's loaded into the environment. The security of the method is not based on storing the token in the environment. The primary advantage I intended was that the secret is confined to one part of the infrastructure (e.g. production server) instead of many (e.g. developer workstations, github, etc).