Store configuration outside the publicly accessible web root.

How is PHP configuration stored so that the web server doesn't accidentally deliver it?

Application configuration is loaded via a fixed absolute path above the web root or a suitable secret store. File ownership and read permissions restrict access to the application process; sensitive values ​​are missing from the repository, resulting in error output, backups with incorrect sharing permissions, and public diagnostics.

Use case: "Source code delivery"

A small application maintains database access in config.php alongside index.php. The file is moved to a directory readable only by the PHP process above the document root; the application loads it via a fixed path and aborts without outputting any details if values ​​are missing.

Minimal file permissions

1. Inventory the document root and all files currently accessible through it, and explicitly restrict public resources.

2. Move the configuration to a protected path or secret storage and set minimal ownership and permissions.

3. Test the absolute load path, missing values, web server misconfiguration, and secret leaks in logs and artifacts.

Source code delivery

• Source code delivery A faulty server configuration delivers PHP or environment files as text and reveals access credentials from the web root.

• Repository Secrecy – Production tokens end up in version history, build artifacts, or shared developer backups despite being stored securely.

• Excessive Readability – Global file permissions allow other applications or compromised system accounts to access all secrets.

Physical Separation

• Physical Separation – No URL can directly resolve the configuration file, even if PHP processing or web server rules are faulty.

• Minimal file permissions – Only necessary deployment and application roles can read or modify the content; other system users are excluded.

• Controlled Load Path – The application uses a fixed, audited source and falls back safely to default secrets if configuration is missing.

Controlled Load Path

• Number of sensitive files within the web root or publicly resolvable build and backup paths.

• Proportion of production secrets with managed storage, minimal access, rotation, and audited exclusion from artifacts.

Related questions and next steps

Separates from "PHP configuration outside the web root" Securely Reading JSON Files and Responding to Erroneous Data an important follow-up question: How does PHP unambiguously react to a missing, unreadable, or invalid JSON file?

For those who wish to delve deeper into "PHP configuration outside the web root" from the perspective of the "Hosting, Server, CDN & Caching" cluster, see [link to relevant documentation]. Maintaining Correct File Permissions and Ownership on Web Servers .

If you want to practically implement "PHP configuration outside the web root," you can refer to Robust Website Systems This document focuses on "Code, path, and dependency boundaries" and "Physical separation."

Conclusion: PHP configuration outside the web root

The safest web server rule for secrets is not to place them in the deliverable tree at all. Access rights and controlled load errors close the remaining system paths.

Sources and Further Information

These primary sources are authoritative for platform behavior, terminology, and check boundaries in "PHP configuration outside the web root."

• json_decode – PHP ManualThe PHP manual documents return types, errors, depth limits, and JSON_THROW_ON_ERROR for controlled JSON processing.

• Filesystem Security – PHP ManualThe official PHP documentation describes file permissions, ownership, web server access, and the risks of dynamic filenames.

• The composer.json schema – ComposerThe official Composer documentation defines package metadata, version requirements, autoloading, and configuration fields.