.ENV Password Security from backdoor

A few things would be important here:

1. Granted, I shouldn't be able to get your production database password, but even if I did, I shouldn't be able to access it because it should be accessible only internally on the network to other servers. Firewalls should prevent me from being able to access it directly. Beyond that, at least in MySQL, I can allow access to specific usernames from specific IPs or localhost, so that would prevent me from logging in even if I had the full and correct credentials.

2. If you're talking about the broader, non-database use case: if your company is large enough that have concerns about developer access to production code and you have systems and protections and permissions in place to prevent access to production from developers, that means you're big enough to have and use code reviews. Code reviews catch and prevent these kinds of problems, intentional or accidental, from seeping into your codebase.

3. You might consider doing some kind of basic static analysis of your code in your build system; it can be a sophisticated library, or it can even be as simple as grepping for instances of "dd(" or "die(" or "exit" or any of a number of other things. I wouldn't necesarrily recommend the grep approach, but nevertheless it might be something where you currently have nothing.

Don't know if any or all of these answered your questions or concerns, but hopefully it gets you on the right track.

You can prevent direct access to the production server and the database, but as long as the application is connected to said database, any regular piece of code like a database query will still be able to reveal or modify production data (like it's supposed to). Preventing something like dd(env('DB_PASSWORD')) isn't going to help much against someone who is able to modify your code.

If you want to prevent the developer from accessing the database, you'll need to actually analyze the added code like @Defrag said.

You can change the privileges of the database user and prevent the application (and the developer) from executing certain types of queries, e.g. prevent SELECT, INSERT, UPDATE or DELETE on a specific table where you know it shouldn't be allowed.

@Defrag your first point really does answer my question and can be applied. Thank you very much.

@Nash Maybe changing the privileges isn't the case if they get the production user and password, right?

From my knowledge, lots of small companies have devs, and person who can deploy. so devs could only access the code but not db.

But in this scenario, devs can get the production user and password from .env if the company doesn't analyze the added code, so privileges can't help, since they may not have their own db account in the first place.

And if devs use more simple function like echo(), it might be even harder to detect.

So, I think, the first point of Defrag's answer may be one of my solution in this case.

Thank you again.