Hardening config.inc.php for Maximum Protection
Detailed technical guide to hardening the OJS master configuration file. Covers cryptographic salt generation, session timeouts, database security, and Linux permissions.
Real Problem
Many journals deploy OJS with default security salts, debug mode left enabled, and file permissions set to 777, exposing confidential journal records to any user on the server.
Practical Solution
Harden config.inc.php by generating cryptographically secure salts, locking down file permissions to 640, disabling debug flags, and enforcing strict session and password policies.
The Central Role of config.inc.php in OJS Security
The config.inc.php file is the primary configuration blueprint for Open Journal Systems. It governs every security parameter: database credentials, encryption salts, session cookies, external command paths (like tar and pdftohtml), and API authorization keys.
Securing this file is the baseline requirement for any production scholarly publishing platform.
Step 1: Restricting Linux File Ownership and Permissions
Under no circumstances should config.inc.php have 777 or 666 permissions. It should be readable only by the web server user (www-data) and owned by root:
chown root:www-data /var/www/ojs/config.inc.php
chmod 640 /var/www/ojs/config.inc.php
This configuration ensures that standard system users cannot view database credentials, while PHP-FPM can read the directives needed to run the journal.
Step 2: Cryptographic Salt Generation
The salt parameter in the [security] section is used as a cryptographic pepper for internal system hashing and CSRF token generation. Never leave it as default or blank.
Generate a secure 64-character random salt:
openssl rand -hex 32
Update config.inc.php:
[security]
salt = "8f3b2c1e7a9d0f4e6b8a2c1d3e5f7a9b0c2d4e6f8a1b3c5d7e9f0a2b4c6d8e0"
Step 3: Disabling Information Disclosure Leaks
When an error occurs on a live website, displaying technical details to the public aids attackers in reconnaissance. Ensure all debug parameters are disabled:
[debug]
show_stacktrace = Off
display_errors = Off
deprecation_warnings = Off
debug = Off
Step 4: Hardening Web Server Directives
Add an explicit blocking rule to your Nginx server block to ensure config.inc.php is never served via HTTP:
location ~* /config\.inc\.php$ {
deny all;
return 404;
}
Step 5: Restricting External Command Binaries
In the [cli] section, specify the exact absolute paths to system binaries. If external converters are not required by your workflow, leave them disabled to prevent command-injection attack surfaces.
Step-by-Step Action Plan
Lock Down File Permissions
Set chmod 640 on config.inc.php with chown root:www-data to prevent unauthorized users from reading credentials.
Generate Strong Cryptographic Salts
Replace default salt strings with high-entropy 64-character random cryptographic keys.
Disable Debugging & Stack Traces
Set display_errors = Off, show_stacktrace = Off, and debug = Off to prevent leaking server paths.
Enforce Session Security Directives
Configure session_cookie_name, session_samesite = "Lax", and session_lifetime for robust cookie security.
Block HTTP Access in Web Server
Add strict Nginx/Apache configuration blocks preventing direct web requests to config.inc.php.
Questions People Usually Ask
Can visitors view config.inc.php in their web browser?
Because config.inc.php has a .php extension, web servers will execute it (returning a blank page) rather than serving raw text. However, if PHP crashes or misconfigures, the plain text credentials could be exposed. Always block direct web requests to it in Nginx/Apache.
What happens if I change the salt parameter in an existing OJS site?
In OJS 3.2 and earlier, changing the salt invalidated existing hashed passwords, locking out users. In OJS 3.3+, passwords use modern bcrypt/Argon2 hashing which incorporates individual password salts, but session cookies will still be invalidated, logging out active sessions.
What is the recommended encryption algorithm for OJS passwords?
Set encryption = sha1 (legacy) to modern algorithms. OJS 3.3+ automatically utilizes PHP’s native password_hash() using Bcrypt or Argon2id regardless of the legacy encryption setting.
Audit Your Journal’s Security Configuration
AcademiaTech conducts thorough penetration tests and configuration audits to protect scholarly journals against unauthorized intrusion.