Secrets and Credentials

If we are using this in a team setting, sometimes people will initially code using database credentials directly in code before moving them to a dotenv file.

With that said,

  1. Are these credentials then stored anywhere at all? If I ask for a code refactoring, etc that involves the file, etc.

  2. If they aren’t in file but in a dotenv file, are dotenv files safe?

In the above scenarios, are there ways to be protected fully?

1 Like

Env files are usually already included in the .gitignore file, so Cursor will not index them. When they’re not in the index, they also won’t be used in your messages when you use codebase context. If you don’t have your env file in your .gitignore file, you should ignore your env file by going to the AI sidebar => More => Ignore Files (under Codebase Indexing).

If your private credentials are directly in your code, they will probably be indexed and stored for the codebase context feature. However, putting private credentials directly in your code is generally something you should never do.

Your env file could still be used as context in your prompt if you have it focused and send a chat message. But as long as you have “Privacy mode” enabled, your prompt won’t be stored.

So in short: You should always place your env file in a .gitignore (or explicitly ignore it in the codebase indexing settings), avoid putting private credentials directly in your code, and enable privacy mode (which is enabled by default).

1 Like

I agree and know this. I’m on a team that has committed plain text AWS credentials. I’d hate to just pull in a repo that I’m unaware of a file containing secrets and having that go anywhere we don’t own.

Most of our resources are VPN-gated.

I would say that I’ve developed with hard coded strings before, but never commit it. Just need to know how to ensure nothing gets saved.

Hi Jakob. Thanks for this information. I am pretty concerned about the security of credentials in .env files and that they never get indexed or used for queries or any other form. If I understand you correctly, putting the .env files into .gitignore (what we consider mandatory for our codebases) and using the privacy mode, will make sure, that the .env files are safe from being processed in any way and will never leave our machines? What if the .env file would be active in the editor and we use search or chat functions? Would this lead to indexing or uploading of the .env content? Many thanks for an eventual answer.

I have already put .env files into .cursorignore
but when I asked Can you look at my .env file and see what is inside? to both chat and composer

While Chat refused to read the file, Composer still read my credential and showed me…

Is it bug or something?

1 Like

I followed this issue for a while here on the Cursor forum. It still is unclear to me how they want to fix it. Afaik Cursor still can’t guarantee that .env and other sensitive files are not touched by the AI. Please someone correct me, it this is now changed. I work on Windows using System Environment Variables and the Python OS Python Dot Env module. So I need no .env files anymore. It is not optimal but at least more secure. I think this topic is very important for secure development environments. I hope they address this asap.