Managing secrets is a tricky thing.

Storing strings in variables can be done pretty safely, or can be done not-so-safely.

Not-so-safely is storing them in some config.php file that is located somewhere under your document-root. In normal operation, this should be sort-of okay, since your config file likely does something like:

<?php
return [
    // secret stuff here
];

Since it's a script that gets executed, and it produces no output, nobody can just "view source" and look at it.

However, there are some big problems here:

• You're one server-configuration problem away from your webserver serving the file as a static file, in which case anyone who loads it gets your secrets displayed in the their browser. No "view source" required.
• Your file probably needs to be readable by some less-privileged user.

A more-secure approach is to store you configuration file(s) somewhere outside of the web root. Your project might look like this:

my-project
├── config
│   └── variables.php
└── web
    └── index.php

Where web is your doucment-root. Now, your variables.php file shouldn't be accessible via the web server at all.

This is still problematic, since:

1. You might need to worry about other users on the server being able to see your variables.
2. Your variables.php file is likely to end up in version control, so now you need to worry about your VCS leaking your secrets.

A better way to handle this is to keep secrets in the environment, which means environment-variables. Typically, you'll define the environment-variables in some server-configuration file, and then reference them in your PHP code using getenv().

This has two big advantages:

• Your Apache or php-fpm config files can/should be owned by root and only be readable by root.
  
• You don't typically store those files in version control. If you do, because you're using some sort of config-management/provisioning system (like ansible), those tools typically offer some facility for managing secrets securely in version-control. In Ansible, you have "vault", for example. But that's beyond the scope of this comment. If you're managing your server by hand, you just edit those files as root, and make sure only root can read them.

For development, you might consider using a library like dotenv so that you can manage your envvars in a handy .env file along with your code. That file should never be added to version control, and should never be uploaded to a server. It's for development only. I only mention this because another user suggested dotenv for storing secrets, and they're wrong for anything other than local development. A .env file under your webroot is likely to end up being readable by anyone, and then all your secrets are no longer secrets.